As a hobby working on my small project which is online shop for RoR. Faced with the problem of the organization of the database. It is necessary that the goods were different options, depending on their category or type (how better?). On stackoverflow.com found 4 solution of the problem, the easiest of which offers the following structure:
the Products table for the data from all positions is the same for each type of goods still on the plate with the pointer to the parent parameters.
I don't like this method, and others worse. The base is bulky, the structure is complicated well and the code, therefore, too. Already going to do so because anything sensible and not come up.
What can the smart people tell? Thank you very much.
Normally designed database is in fourth normal form will help You.
Kept up to hundreds of millions of rows and the sampling was done properly.
PS: why nobody does not read data, but each database uses?
Darryl.Nicolas answered on October 8th 19 at 02:09
I like seeing the structure:
1) the table with the goods
2) table to properties (list of properties, names, types, etc. need data)
3) a table of bundles of goods and properties (ID item, ID properties, the property value)
Any additional tables and quite transparent and not bulky
emmitt_Kohl answered on October 8th 19 at 02:11
The most common method is to store all properties in a separate table (product code, code soitsu, value). But it is slow, a little faster is to store the bundles of properties for different product categories in the tables for those products. But he does not allow without the union s request the products from different categories. The fastest and most effective but "non-standard" way is to use a document-oriented database, the supplying of a collection of objects with different properties, such as MongoDB.
Dixie.Stros answered on October 8th 19 at 02:13
Documents without a clear schema usually stored in NoSQL.
But the search will still have to compile multiple schemas for categories, a La the characteristics of the railway, features of monitors,...
hailee.Rath answered on October 8th 19 at 02:15
Without search these properties for a storage option. So I have additional user fields are kept user_id, var VARCHAR(55), val VARCHAR(255), search for it happens very rarely and only in the admin panel, so it everything works fine.
But if you do the search, then as already said, NoSQL(e.g. mongodb) would be more correct to use. The search will work at least quickly with nested objects, and even arrays.