简体   繁体   English

数据库结构 - 带有 category_id 的单设计表(多行)或多设计类别表(几行)

[英]Database structure - Single design table with category_id (Many rows) or Multiple design category tables (Few rows)

I have a database schema for design of multiple categories, all of which have the same structure.我有一个用于设计多个类别的数据库模式,所有类别都具有相同的结构。 There are two scenarios and I am not sure which one to go depending on the performance.有两种情况,我不确定要根据性能选择哪一种。

  1. Single Table: 1 Master table (Categories), 1 Design Table (category_id), 2 tables related to design (label and colors) and 1 table with label_color relation.单表:1个主表(Categories),1个设计表(category_id),2个与设计相关的表(标签和颜色)和1个与label_color相关的表。 There may be around 20 categories, atleast 100 designs per category, atleast 20 labels and 10 colors per design.可能有大约 20 个类别,每个类别至少有 100 个设计,每个设计至少有 20 个标签和 10 种颜色。 So a total of 4 tables, with the lower bound approximately 400,000 records in label_color relation table.所以一共4张表,label_color关系表下界大约有40万条记录。

  2. Multiple Tables: 1 Master Table (Categories), a designs table (category1_designs, category2_designs ...) for each category along with label and color table related to category1_design and label_color table relating labels to color.多个表:1个主表(类别),每个类别的设计表(category1_designs,category2_designs ...)以及与category1_design相关的标签和颜色表和将标签与颜色相关的label_color表。 Using the same estimate as before, with 20 categories and 4 related tables to each design, there are 80 tables to maintain (plus the master categories table).使用与之前相同的估计,每个设计有 20 个类别和 4 个相关表,需要维护 80 个表(加上主类别表)。 Moreover, for getting designs from a specific category or adding a design in a specific category, the server will have a switch case scenario so that it takes the records from the right category, making it rigid and hardcoded.此外,为了从特定类别中获取设计或在特定类别中添加设计,服务器将有一个切换案例场景,以便它从正确的类别中获取记录,使其刚性和硬编码。 Also adding a new category would mean manually creating 4 new tables for that category.此外,添加新类别意味着为该类别手动创建 4 个新表。 Lower bound for this is only 20000 rows but spread over 20 tables.下限仅为 20000 行,但分布在 20 个表上。

I am using MySQL database with InnoDB engine, so considering the performance and scalability, which approach is better for implementing this concept?我正在使用带有 InnoDB 引擎的 MySQL 数据库,那么考虑到性能和可扩展性,哪种方法更适合实现这个概念? Also note that write operations won't be frequent and the tables will only be used specifically for reading and perhaps overwriting.另请注意,写入操作不会很频繁,并且这些表只会专门用于读取和覆盖。

Go with 1. Single (categories) Table. 1. 单(类别)表。 This is the way I would do it and have seen it done many times.这就是我会这样做的方式,并且已经多次看到它。 De-normalizing using many categories tables will be difficult to maintain and require lots of copy/paste or generated string queries.使用许多类别表进行反规范化将难以维护,并且需要大量复制/粘贴或生成的字符串查询。

With 100 max rows per non-associative table, performance will be of no concern as long as your queries and indexes match up.每个非关联表的最大行数为 100,只要您的查询和索引匹配,性能就无关紧要。

声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM