简体繁体 English

我是否应该为此在数据库中创建一个新表？

[英]Should I create a new table into my database for this?

原文 2011-08-22 14:05:16 3 5 php/ mysql/ sql

On my database I have among other tables, products . 在我的数据库中，除其他表格外，我还有products 。 Products table contains the id, name, description and some other data about the product. 产品表包含ID，名称，说明和有关产品的其他数据。 I want to add also a category. 我还想添加一个类别。

Should I create a new table named category with and id and the name of each category, and have into the products a *category_id* that will refers to the id of category , or should I have the name of the category on each row of products ? 我应该使用，id和每个类别的名称创建一个名为category的新表，并在products一个将指向category的ID的* category_id *，还是应该在products每一行上都有该类别的名称？

On the first case I will have to use JOIN. 在第一种情况下，我将不得不使用JOIN。 Will this have a serious impact on the performance? 这会对性能产生严重影响吗？

5 个解决方案

By defining the categories in their own table you can: 通过在自己的表中定义类别，您可以：

Rename categories 重命名类别
Dynamically generate lists of categories for picking from 动态生成类别列表以供选择
Add descriptions of categories 添加类别描述
Add new categories 新增类别

… and so on, without having to update every bit of category related code each time you modify them. …依此类推，而无需在每次修改它们时都更新与类别相关的代码的每一位。

So yes, add a table. 是的，添加一个表。

Will this have a serious impact on the performance? 这会对性能产生严重影响吗？

Probably not. 可能不是。

Yes you should keep your data normalized. 是的，您应该保持数据规范化。 I think create a new table named category is a good idea. 我认为创建一个名为category的新表是一个好主意。

Will categories tend to change over time? 类别会随着时间变化吗？ In most instances that will be the case, so you're usually better off with a separate Categories table and a foreign key (FK) between the two tables. 在大多数情况下，情况通常是这样，因此通常最好使用单独的类别表和两个表之间的外键（FK）。 You can then add or change categories simply with data changes. 然后，您可以仅通过数据更改来添加或更改类别。 Otherwise, you'll want to put a check constraint on the category name column in your table to make sure that you don't get junk data in there and that becomes much harder to maintain. 否则，您将需要在表的类别名称列上放置一个检查约束，以确保其中没有垃圾数据，并且这将变得很难维护。

With proper indexing, the join should only have a minimal cost. 使用正确的索引，连接应该只具有最小的成本。 Also, keep in mind that you won't always necessarily need to join the tables. 另外，请记住，您不一定总是需要加入表格。 You'll only need to join them when you want the actual category name as part of your result set. 仅当要将实际类别名称作为结果集的一部分时，才需要加入它们。 For example, if you have a look-up box on your front end with the categories and their IDs then your select of the Products only needs to return the category ID values and you don't need to even bother with a join. 例如，如果您在前端有一个带有类别及其ID的查找框，则您选择的“产品”仅需要返回类别ID值，甚至不必费心进行联接。

The stock answer is "it depends". 股票的答案是“取决于”。 It depends on how the data is used, will be used, might be used. 这取决于如何使用数据，将要使用或可能会使用数据。 But once you get through all the discussions and arguments, for something this simple and prominent in your data, nine times out of eight you will be better off properly normalizing the data (ie Category table, CategoryId columns, and foreign key). 但是，一旦您完成了所有讨论和论点，对于您的数据而言，这一简单而突出的事情，八分之九会更好地正确规范化数据（即Category表，CategoryId列和外键）。

Only add a table if you require the extra functionality this level or normalization provides. 仅在需要此级别或规范化提供的其他功能时才添加表。 If you need to rename categories, or list them then yes this is a good candidate. 如果您需要重命名类别或列出类别，那么可以，这是一个不错的选择。 If not then why bother with it, it will make your database slightly harder to read. 如果不是，那为什么还要打扰它，它会使您的数据库稍难读取。

Join will most probably not be a performance impact but if you do not need it now, try not to be a victim of over-design. 加入很可能不会对性能产生影响，但是如果您现在不需要它，请不要成为过度设计的受害者。