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.
Related
I'm currently creating an equipment management database and need to allow equipment to be associated with other equipment.
Thanks to this stackoverflow question I currently have something akin to the following (vastly simplified):
class Equipment(models.Model):
equipment_title = models.CharField()
relates_to = models.ForeignKey('self')
However, to relate a dynamic number of equipment to other equipment I think I need something like a one-to-many field that doesn't exist natively within Django, e.g. a filter housing may be associated with many filter units, and several filter housings may be associated with a machine tool.
How can I get around this? I'm not sure that it's the right place for a many-to-many field...
A ForeignKey is a one-to-many relationship, defined on the "many" side. Since your relationship is pointing to self anyway, it already does what you want.
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.
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.
I have three entities: User, Office and PhoneNumber. The user has many phone numbers, and the office has many phone numbers too.
The problem is how to represent these entities relations in Doctrine 2.
At first I tried to use bi-directional one-to-many associations
(User -> has many -> PhoneNumbers) (Office -> has many ->
PhoneNumbers), the PhoneNumber has two mapping fields, one for User
and anotherone for Office. This solution doesn't work since one of
the mapping foreign keys couldn't be null.
My second approach was to use two entities and one superclass for PhoneNumber. The PhoneNumber superclass has defined all common fields except the mapping field. Entities UserPhoneNumber and
OfficePhoneNumber extended the PhoneNumber entity and specified the
different mapping field and different table. (one table for OfficePhoneNumbers, anotherone for UserPhoneNumbers)
This solution actually works, but it is quite ugly to have 3
classes to represent one simple entity.
My third approach is to use uni-directional one-to-many mapping. This will eliminate the need of mapping field for the PhoneNumber entity. The problem is that when I use cascade remove for the many-to-many field, it violates the integrity constraint when deleting records.
When I omit the cascade remove option, after removing User or Office, the PhoneNumber remains in the Database (but the record in mapping table is removed).
What is the best way to handle this type of association?
Thanks
I finally solve the problem connected with (probably the nicest) solution 1). The problem was in misunderstanding of mappedBy attribute which should specify the entity field, not the database field.
Trust me, I've put a lot of thought into this problem before asking here, and I think I got a solution, but I'd like to see what you guys can come up with before settling for my own :)
SCENARIO:
In the domain we got 3 entities: A treatment, a beautyshop and an employee. A beautyshop can hire 0 to many employees. Now, a beautysalon has a list of possible treatments it can do for its costumers. Each treatment has a description, a duration and a price. Each employee has a similar list, but each employee can specialize each treatment (different price or duration), add new treatments or "remove" treatments derived from the beautyshop.
.. This seems like a rather common problem to me, so I was hoping someone could come up with something clever :)
So far, Im thinking about letting each treatment have a unique id, and then let the employee list insert treatments by itself which will have the same id as the one from the shop. These employee treatments will then override the shop ones with the same id..
Thanks in advance
Are We talking about the objective representation of the problem or about the database representation of the problem? If it's the objective representation, than a specialized treatment should just be a subclass of the generic treatment.
With the relational database representation of the problem, things get a bit harder:
beautyshop ---= employee
beautyshop ---= treatment_type
treatment_type ---= treatment
employee =--= treatment
(---= is one to many, =--= is many to many).
But how do We get a list of treatments available in a beautyshop? We don't. Instead We get a list of treatments available from all beautyshop employees. That said, if a beautyshop has 0 employees, it serves no treatments.
You might use null fields in treatment table to indicate that the particular employee serves this treatment with default properties. If the treatment_type's defaults change for particular beautyshop, then all treatments are updated.
I would suggest adding some kind of inheritance/specialization mechanism to the Treatments by adding a parentTreatment reference to the Treatment class. You would have a set of standard Treatments, and each Employee would be able to select and customize them.
The BeautySalons wouldn't explicitly store any Treatments, a transient and volatile getAvailableTreatments() method would iterate over the associated Employees and aggregate the parent Treatments of the Treatments offered by each Employee.
Why do you want to have different treatments with the same ID?
I'd rather set up a "custom treatment" ID.