I am creating a database using MySQL 5 for an eCommerce web site. I want the database to be as flexible as possible so that the owners of the web site can add custom attributes for various types of products. For instance, they can have a product which has 4 shirt sizes and 3 colors for each size available, or a product that has 6 shirt sizes, 4 colors for each size and possibly a 3rd attribute.
The problem I am running into is that they should be able to control the quantity for a product based on its various attributes, not for the product itself. The company may have a product that has 25 in stock of one style and color but have 13 in stock of a different size and color combination.
Is there a good solution on how to structure this in a MySQL database? Currently I have a table that will store the product id, quantity and the attributes will be concatenated in 1 field using a "key:value" syntax that is comma-delimited.
This is my first time trying to create a system like this. Any information/help would be greatly appreciated. If you need more information, I can provide that as well.
I really appreciate the recommendation. But to do this "Derived Item" method, would I need to create a different database table for each type of product since the products could have variable attributes associated with them?
The simplest solution is obviously to make every shirt-color combo a totally separate item, and abandon the attribute concept. I believe this is how most real stores operate. It makes sense when you consider how often the "base" items change anyway.
If that isn't acceptable, you could have a DerivedItem table, where each row was a separate derived item, which had a reference to the base item in a BaseItem table. That would eliminate some redundancy at the cost of a more complex design.
I'd go with the products and derived products, or whatever you might want to call it.
You can still put attributes on these if you wish.
You can then put common attributes on the product table (description etc) and those that vary on the derived product (colour, size, price etc).
The attributes would be best implemented as a separate table, with a foreign key on the derived attribute for things like colour. That eliminates the chance of users entering things like "Dark Blue" and "Blue (Dark)" and expecting your system to magically know that they are the same colour ...!
Related
I am a beginner and this is my first real project.
The below image shows what I have been trying to reach. But it got way complicated so fast and confusing. So I'm asking if there are different ways to design the tables easier with few keys in mind:
attributes won't duplicate.
colors,sizes,materials tables have different structures e.g.(colors
have name_ar,name_en,and path for the image of the color).
I wasn't using SKUs in the beginning, But now I think I may need
them to separate.
Different colors may have different sizes and so on
This is what I have reached so far
#Edit-1:
I tried to think about another way to design it but it grew more than the previous on with one table more
.
But after that I couldn't think of another way to reach the result that I wanted.
Thanks for all the answers in advance
It looks like you're trying to do EAV architecture here, but don't really understand the point \ problems with it.
The point of EAV architecture is to build the database vertically vs horizontally. It looks like you're just creating a bunch of pivoted attributes, vs actually EAV design. What this means in practice is that instead of:
Table: Shirts
Columns: ID, Label, Size, Color, Weave, Fabric, Made in, Class, Discount blah blah blah
You Want:
Entity:
ID:1, [Label:'Cool Shirt', Price: 19.00, Other required properties]
Then your attributes tables
attribute:
entity: 1
attribute:type
value: shirt
attribute:
entity: 1
attribute:color
value: red
attribute:
entity: 1
attribute:size
value: large
The point of this style of architecture is that not all entities need all attributes, and you don't wanna make a super long table with every potential property an entity could possess.
You can go further down the pivot tables which is what it looks like you were trying to do here with the pivoted ID \ naming:
attribute_values:
entity: 1
attribute:3
value: 5
Table attribute_map:
id: 3
value:"color"
Table property_map:
id:5
attribute:3
value:"red"
Regardless few major things.
Parent should be a property of the subtables themself that's the 'entity' part. No need for another table mapping relationships. Also makes it a lot easier to run down recursive calls to get what you want as the final answer)
Things like price don't (usually) fit into this model well and should also be assigned as a column on the top tier entity as well. Keep that in mind when you're deciding how to structure your top tier entities.
Make sure to add composite indexes to all of your pivots.
Edit for what you wanted what you're trying to do:
So keep in mind every entity is just a collection of properties.
Enitity 3: Shirt, White, XL
Enitity 4: Shirt, White, X
Shirt-White-X is the "SKU" as far as your database is concerned in EAV.
You just recursively progress down all of the tree until all properties \ sub-properties are fully expressed.
Keep in mind an "entity" is just an amalgamation of properties which in this case you also want to operate as a unique key (basically a SKU). Bonus you can use unique indexes to enforce it.
From (exactly) what you said you're just trying to work out inventory, which can be done a few ways. Generally you'd just make another tier (guessing as I don't know what you're actually trying to do).
Table: Inventory
Id (store): 1
Attribute (product_id): 4
Value (inventory): 7
You can create a higher tier entity like a store and actually create product objects assigned to the store. Really depends on how your system is modeled and how far down the rabbit hole you wanna go.
This is getting a bit more into abstraction \ what you're actually doing \ how your overall architecture works.
It's rarely useful to be an EAV purist. Properties like price that will be attached to every product entity are usually easier just to add directly to the top tier entity. You're not trying to re-build magento here and there's some major downsides to pure EAV architecture as it gets more convoluted. It can be very flexible. It can also create insanely inefficient systems depending on how it's built (hello medical industry).
I need some assistance linking 2 tables.
I have a products table and an additives table. Some products have 1-3 different additives in them.
I have them linked by their codes but they aren't showing as linked like my other tables. Is it because I have several different Additive Codes under 1 product?
Can someone point me in the right direction here! :D
It may help, as well as make your app more flexible, to have a intermediate table which has only the Product Code of the parent item and a field for the Additive Code. Then you link your tblProducts to the Product Code in this intermediate table, and you link the Additive Codes in the intermediate table to the tblAdditives.Product Code field. This should provide the links you are seeking, as well as allowing an unlimited Additives.
You have two options here. Table designing is a very critical stage so please carefully use the best approach as per your requirement.
Use an associative table as suggested by #Dale, this would be the best approach.
You can create a multivalued field which will allow storing more than one Additive codes in the same field. In case your additive code list is limited then you can go in this way and the advantage you have is easily displaying all values in reports.
Guide to multivalued fields
I have been looking to design a multiple product type database table. Assume for a moment I wish to add two different type products, a book and a computer software compact disc. These two product have a few distinct/unique attributes which relates to one but will absolutely make no sense to other.
Attribute for a book = ISBN, Pages, Author.
Software = preferred operating system, device it works on, no. of license.
Initially, I asked a similar question, here, and was suggested that to scale I need to have a simple table with product_id and attribute_id
Working on the suggestion, and looking around for a bit of help, this is what I came up with.
Here we have a product table with a few common attributes that mostly may apply to all but a few column will take null, For the more product specific attributes, the user will need to create them on their own.
Can you please suggest if this is right?
Being new to relational database design, I am trying to clarify one piece of information to properly design this database. Although I am using Filemaker as the platform, I believe this is a universal question.
Using the logic of ideally having all one to many relationships, and using separate tables or join tables to solve these.
I have a database with multiple products, made by multiple brands, in multiple product categories. I also want this to be as scale-able as possible when it comes to reporting, being able to slice and dice the data in as many ways as possible since the needs of the users are constantly changing.
So when I ask the question "Does each Brand have multiple products" I get a yes, and "Does each product have multiple brands" the answer is no. So this is a one to many relationship, but it also seems that a self-join table might give me everything that I need.
This methodology also seems to go down a rabbit hole for other "product related" information such as product category, each product is tied to one product category, but only one product category is related to a product.
So I see 2 possibilities, make three tables and join them with primary and foreign keys, one for Brand, one for Product Category, and one for Products.
Or the second possibility is to create one table that has the brand and product category and product info all in one table (since they are all product related) and simply do self-joins and other query based tables to give me the future reporting requirements that will be changing over time.
I am looking for input from experiences that might point me in the right direction.
Thanks in advance!
Could you ever want to store additional information about a brand (company URL, phone number, etc.) or about a product category (description, etc.)?
If the answer is yes, you definitely want to use three tables. If you don't, you'll be repeating all that information for every single item that belongs to the same brand or same category.
If the answer is no, there is still an advantage to using three tables - it will prevent typos or other spelling inconsistencies from getting into your database. For example, it would prevent you from writing a brand as "Coca Cola" for some items and as "Coca-Cola" for other items. These inconsistencies get harder and harder to find and correct as your database grows. By having each brand only listed once in it's own table, it will always be written the same way.
The disadvantage of multiple tables is the SQL for your queries is more complicated. There's definitely a tradeoff, but when in doubt, normalize into multiple tables. You'll learn when it's better to de-normalize with more experience.
I am not sure where do you see a room for a self-join here. It seems to me you are saying: I have a table of products; each product has one brand and one (?) category. If that's the case then you need either three tables:
Brands -< Products >- Categories
or - in Filemaker only - you can replace either or both the Brands and the Categories tables with a value list (assuming you won't be renaming brands/categories and at the expense of some reporting capabilities). So really it depends on what type of information you want to get out in the end.
If you truly want your solution to be scalable you need to parse and partition your data now. Otherwise you will be faced with the re-structuring of the solution down the road when the solution grows in size. You will also be faced with parsing and relocating the data to new tables. Since you've also included the SQL and MySQL tags if you plan on connecting Filemaker to an external data source then you will definitely need to up your game structurally.
Building everything in one table is essentially using Filemaker to do Excel work and it won't cut it if you are connecting to SQL, MySQL, etc.
Self join tables are a great tool. However, they should really only be used for calculating small data points and should not be used as pivot points or foundations for your reporting features. It can grow out of control as time goes on and you need to keep your backend clean.
Use summary and sub-summary reporting features to slice product based data.
For retail and general product management solutions, whether it's Filemaker/SQL/or whatever the "Brand" or "Vendor" is it's own table. Then you would have a "Products" table (the match key being the "Brand ID").
The "Product Category" field should be a field in the "Products" table. You can manage the category values by building a standard value list or building a value list based on a "Product Category" table. The second scenario is better for long term administration.
This question already has answers here:
Is storing a delimited list in a database column really that bad?
(10 answers)
Closed 4 years ago.
I'm building a database for a real estate company.. Those real estate properties are managed by the sales people using a CodeIgniter website.
How should I proceed with the database design for this table. The fields like address/location, price etc. are pretty straightforward but there are some sections like Kitchen Appliences, Property Usage etc... where the sales people can check multiple values for that field.
Furthermore, a property can have multiple people attached to it (from the table people), this can be an intermediaire, owner, seller, property lawyer etc... Should I use one field for this or just I create an extra table and normalize the bindings?
Is the best way to proceed just using one field and using serialized data or is there a better way for this?
In a relational database you should never, EVER, put more than one value in a single field - this violates first normal form.
With the sections like Kitchen Appliances, Property Usage etc... where the sales people can check multiple values for that field, it depends on whether it will always be the same set of multiple options that can be specified:
If there are always the same set of multiple options, you could include a boolean column on the property table for each of the options.
If there are likely to be a variety of different options applicable to different properties, it makes more sense to set up a separate table to hold the available options, and a link table to hold which options apply to which properties.
The first approach is simpler and can be expected to perform faster, while the latter approach is more flexible.
A similar consideration applies to the people associated with each house; however, given that a single property can have (for example) more than one owner, the second approach seems like the only one viable. I therefore suggest separate tables to hold people details (name, phone number, etc) and people roles (such as owner, seller, etc.) and a link table to link roles to properties and people.
You should create extra table for it....
For example...
Consider the scenario that 1 item may have many categories and 1 category may have many items...
Then you can create table like this...
Create three tables for that....
(1) tblItem :
fields:
itemId (PK)
itemName
etc..
(2) tblCategory :
fields:
categoryId (PK)
categoryName
etc..
(3) tblItemCategory :
fields:
itemId (PK/FK)
categoryId (PK/FK)
So according to your data you can create an extra table for it....
I think it would be optimize way....
If you want your data to be in third normal form, then you should think in terms of adding extra tables, rather than encoding multiple values into various fields. However it depends how far your brief goes.