Considering scenario of an Inventory Management System. Inventory has many types of items, each with own table and columns. One, two or Twelve tables are not sufficient to describe the plethora of the TYPES of items as they are extremely varying. e.g. some attributes of a family of items like BIKES do not have the same attributes of CARS. It is tedious for developer to take into account the thousands of the TYPES of items and incorporate them into each model manually.
Is there a way for users to generate models themselves? thereby generating own SQL tables etc... Is there another approach to this problem? (Maybe using Semantic Web Technologies)
Coming from Spring Framework, I am fairly new to RoR development.
Thanks in Advance.
I'm not an expert, but you could do it with regular, pre-defined models.
Item_Type
Item_Attribute
Item
Item_Type would have a name variable (not unique), and perhaps any other common attributes you'd want. It would then have a has_many Item_Attributes relationship, whereas Item_Attribute belongs_to Item_Type.
So I'd make a view that allows the user to add new Item_Types and then define Item_Attributes for those item types.
Then you could have the actual Item model, each instance of which is the existence of an Item_Type in the inventory. Item belongs to Item_Type, and Item_Type has_many Items, and Item cannot have a null Item_Type.
So a user creates a new Item_Type with the name "BIKE", then adds several Item_Attributes to it, such as "Mountain" and "Red". Then the user can create a new Item that has a relationship to the "BIKE" Item_Type.
If they wanted to add a blue mountain bike instead of a red one, they would need to go through the process again, adding another Item_Type of "BIKE" except adding "Blue" as an attribute for the new instance of Item_Type's Item_Attributes.
Related
I'm working on an e-commerce platform build using Django and Postgresql. In my platform I have an entity called "Category" and an entity called "Attribute". A category can have multiple attributes, but an attribute can only belong to one category.
For example, the "digital camera" category can have lens, image quality, etc. as its attributes.
I have come to realize that some attributes can belong to all categories. For example: packaging, shipping, customer service, etc.
In addition to these general attributes, in the future I may end up having attributes that belong to multiple categories. For example battery can belong to all categories in the Electronics department (categories belong to a department). But I'm not sure if this is a good idea as it may make things unnecessarily complex.
What's the best way to approach this? Please note that I need to be able to query the general attributes often. I have thought of the following solutions:
Make a default category and assign those attributes to that category. In the code write a special logic that will always look at these categories.
Allow a nullable foreign key in the attributes table. So an attribute can belong to no specific category indicating that it belongs to all categories.
Make another table for general attributes.
Store the category-attribute relationship in a third table. But then my question is how can I query for attributes that don't belong to any specific category?
I appreciate your help in advance.
UPDATE:
Not sure if this is the best solution, but I took the easy route and ended up making nullable m2m relationship between attribute and the other models. Thank you all for your help.
I'm currently designing my data base using postgresql with Django and I was wondering: What is best practice - having several instances of the same model with the same value or a many to many relation ship?
Let me elaborate. Let's say I'm designing a store. The store sells items. Items can have one or many statuses (e.g. ordered, shipped, delivered, paid, pre-ordered etc.).
What would be a better practice:
Relating the items to their status via a many-to-many relationship, which will lead to one status having hundreds of thousand and later millions of relations? Will so many relations become problematic?
Or is it better for each item to have a foreignkey to their statuses? So that each status only has one item. And if I would like to query all the items that have the same status (e.g. shipped), I would have to iterate over all statuses with a common name.
What would be better, especially for the long term?
I would recommend going with a many-to-many relationship.
Hundreds of thousands or even millions of relations should not be a problem. The many-to-many relationship is stored as a table with id, item_id, status_id. SQL will be performant at querying the table either by status_id or item_id even if the table gets big. This is exactly the kind of thing it was built to handle.
Let me elaborate. Let's say I'm designing a store. The store sells
items. Items can have one or many statuses (e.g. ordered, shipped,
delivered, paid, pre-ordered etc.).
If many people will have this many itens you should use manytomany relations, better let django handle with this "third table", since this table just hold ids you can interate over them using reverse lookup, i do prefer using many to many instad of simple foreignkeys.
In your case, who you will handle when your User will hold many itens? like what if my User buy one potato and 2 bananas? you will duplicate the tuple in your User Table to tell "here he have the potato and in this second one he have the banana"? so you will be slave of Disctinct attribute while you still dirtying your main table User
...
class Item(models.Model):
...
class User(models.Model):
items = models.ManyToMany(Item)
So when i query my Item and my User will only bring attributes related to them... while if you use item inside of User Model you will have multiple instances of same user.
So instead of use User.items.all() you will use User.objects.filter(id=id)and them items = [user.item for user in User.objects.filter(id=id)]
Look how complex this get and makeing your database so dirty
In Dynamics CRM online, I can add a list of entities to another entity, for example a list of products to an opportunity.
Is there any way I can have a list that is not picked from pre-populated items, e.g. just a simple list of {number, date, text} that you type in each time you want to add to the list, not picking items from a pre-defined list.
I am just using the web interface to customise at the moment, but I am open to any suggestions.
EDIT:
So far i have;
Created two entities, proposal and proposal version
Added a 1:N relationship between proposal and proposal version
Added a sub-grid to the proposal form, tried to make it editable but it refuses to work
This lets me add new rows by opening up the proposal version form and adding a new one or picking from already created ones for other proposals but that is rather clunky for a simple list.
I don't want it to offer to search for previous entries, just let me add to the list by typing stuff in, surely this should be fairly simple?
If you want a pre-defined list of items that are simple (number, date, text..) then you can create an option set field in CRM. These lists are fixed and can only be extended by customising the system. An example option set field might be Organisation Type:
Prospect
Site
Head Office
...
If you want a pre-defined list that can be extended, you need to create a new entity. Following from the previous example, you would create a custom entity called Organisation Type and then create a record for each type you wanted, populating only the name field with the type: Prospect, Site etc.
Then you would add a lookup field pointing to the Organisation Type entity on any other entity that used the field, such as Organisation (Account).
You see how the custom entity still appears as simple data because you're only populating the name field, which can be text, a number etc. You can also apply security roles to this entity, limiting which users can create and delete options from your list.
Edit: to only allow the creation of new records in a subgrid, make sure the lookup attribute to the parent entity on the child entity is business required.
I like to develop a shopping cart website with multiple products.
(ex.: mobile phone, furniture etc.,)
here mobile phone specification will cover
size of display
memory
operating system
camera etc.,
but for furniture - its specification is entirely different from above electronic product.
type of wood
color
weight
shape
glass or mat finish etc.,
My question is: how to handle a common database-table for product specification ?
each & every category of product & its spec will be differ - so how to have a common
table ProductSpecificationTable ?
I searched many site including google.. but cant able to get the perfect soultion.
Please help me to move to next step.
Ask yourself the question: How can I accomplish this kind of database? First of all you need products.. Every product has to be in some kind of category and every category has to have his own properties. So, you've to create a product table with unique id and every product needs a category id. At this moment it is time to link from your property table to your category table(by id) and to set the values you need a 'property_value' table.
**table:** **id**
product --> category id
property --> category_id
property_value --> property_id
I hope you will understand my explanation otherwise just ask :)
You can add 1 more table to accomplish that. Table that contains cat_id, product_id and the property. That is a many to many relationship. I believe this way you can accomplish thst.
You can achieve this with a single table within a database but that will complicate the CRUD operations over the table. So I will recommend you to create one database like ‘Inventory’ which can have multiple tables (one table for each of the Product Type).
First Table could be list of Product Types you have (mobile phones, accessories, furniture):
You can use this table to populate your list of items available. Here the column _table_name will contain the actual name of the Tables.
Then for each of the product you can have different tables with different number of columns:
Table for Product Type Mobile Phones:
Table for Product Type Furniture:
I hope this will help.
The request
I want to add Members to their department in our Company, but our company has more offices and each office its own departments, so we need to organize that first and then try to assign each Member to its department so that they only have permissions to access their own department.
Departments overview as Umbraco Content:
Root Node
-Office 1
-- Department1.1
-- Department1.2
-Office 2
-- Department 2.1
-Office 3
-- Department 3.1
-- Department 3.2
-- Department 3.3
Now, if I add a User, I want one property to select the office and another to select the department.
Possible solutions
Checking here and there, I've seen I can make the Office property using the UltimatePicker type in Umbraco creating a custom data-type linked to a parent node and then a property inside my MemberType. That will display the offices under "Root Node" and link the member to one of them.
Now, to make the department property I've seen there could be some way using a custom manually-coded property, adding a usercontrol and using it to display the office children dynamically (I've not tried it yet, I'm theorizing).
But I am worried that the second property will be dependent on the first one, and when I've tried to create my custom property implementing umbraco.editorControls.userControlGrapper.IUsercontrolDataEditor in my usercontrol it only allows me to save one value, not two of them. Which has sense as this is supposed to be A property, and not a bunch of them.
My question
Now, what's the best way to have those 2 custom properties and also make sure that in case I change the office the department will be also refreshed?
Best crazy idea at the moment
Up to this moment, I can only imagine creating 2 usercontrols, one for each property, and manually clean the department each time the office is updated, though I don't know if this is possible (Can I really get departments dynamically? Can I clean the dep. property FROM office property usercontrol?) and I would prefer to have them together as to simplify the codes.
If the relationship is key and you need to prevent a user from accidentally choosing a department that doesn't belong to an office, then you could create a single usercontrol that contains two drop-down menus. The first menu displays the offices and the second is only populated (preferably by an ajax call) once an office selection has been made.
The code for retrieving the offices and departments would be relatively straightforward using the umbraco api.
The usercontrol could then save the id's of each to xml or a comma delimited list.
Alternatively, you could just allow the user to select a department and the office is implied by the choice of department. You could use the uComponent's multi-nodepicker and filter the node selection to only the Department doc type. The overhead then is in the UI code where you have to work out the Office from the Department.
To get around this, you could have a label property that simply stores the ID of the Department's Office. The Office ID could then be saved using an OnSave event handler.