0

我有多个表。

它们都包含以下字段：

item_title | item_description | item_thumbnail | item_keywords

我最好拥有一个带有额外 item_type 字段的 items_table，然后加入相应的表，还是将它们全部保存在单独的表中？

4

9 回答 9

3

OK, so the tables share fields. Do they also share constraints1?

  • If yes, then go ahead and merge them together.
  • If not, you may keep them separate, of may merge them together, depending on what kind of tradeoff you are willing to make.

For example, if tables have separate foreign keys, you may keep them separate, or you may merge them into a single table, but keep FKs separate:

item_title
item_description
item_thumbnail
item_keywords
table1_id REFERENCES table1 (table1_id)
table2_id REFERENCES table2 (table2_id)
...
CHECK (
    (table1_id IS NOT NULL AND table2_id IS NULL ...)
    OR (table1_id IS NULL AND table2_id IS NOT NULL ...)
    ...
)

(NOTE: MySQL Doesn't enforce CHECK, so you'll need to do the equivalent enforcement from a trigger or client code, or use a different DBMS if you can.)

I'd need to know more about your database to figure out which is better.

with an extra item_type field and then joining with the respective table,

Never enforce FKs in code, if you can help it. Even if you merge the tables together, don't merge FKs, instead do something like the above. Enforcing FKs in code in the context of the concurrent environment (where multiple clients can try to modify the same data at the same time) is difficult to do correctly and with good performance - it's much better to let the DBMS do it for you.

BTW, what is item_keywords? It it's a comma-separated list of keywords (or similar), you'll need to normalize further and extract the keywords into their own separate table.

1 Domain (data type and CHECK), key (PRIMARY KEY and UNIQUE) and referential (FOREIGN KEY) constraints.

于 2013-10-09T13:41:21.210 回答
3

取决于上下文。如果您的项目几乎没有区别，并且您确定在 6 个月、12 个月、2 年内不会出现需要将项目分开的情况，那么请使用一个通用的“项目”表。如果特定项目类型确实有特定要求，那么您可以创建一个包含此数据的单独表，并LEFT JOIN在查询时创建一个包含额外数据的表。

我还建议查看其他数据库类型。从您的场景来看（许多项目类型在存储的数据中几乎没有差异），我认为您可能会受益于像 MongoDB 这样的基于文档的数据库引擎，而不是像 MySQL 这样的基于关系数据的数据库引擎。

于 2013-10-01T09:21:01.940 回答
1

我相信桌子越少越好。它易于维护。很难想象如果你有 3000 种item_type. 然后，将有 3,000 个不同的表。所以在你的情况下，单张桌子对我来说是个好主意。以后遇到需要分离表的情况时，可以轻松做到。

所以简短的回答是，是的。

于 2013-10-01T08:44:39.850 回答
0

如果我理解得很好，您只需要规范化您的架构：

项目：

item_id
item_name
item_description

items_types

item_id
type_id

类型

type_id
item_file_name

所以这样你就可以拥有任意数量的类型的任意数量的项目

这是你想做的吗？？？

于 2013-10-01T08:53:25.927 回答
0

创建两个单独的表并根据您所需的输出将它们连接起来。

即>

1.1'st TABLE（主表==>item_type）

item_type(item_type_id,item_type_name,状态)

2.2'nd TABLE（子表==>item_details）

item_details(item_id,item_type_id,item_title,item_description,item_thumbnail,item_keywords)

查看更多示例..

于 2013-10-16T07:37:35.253 回答
0

出于以下原因，我建议您使用一张表作为项目，一张表作为类型（假设有 10 种类型）。

  1. 我不确定您使用的是哪种编程语言。作为一名 Java 开发人员，如果我有多个表，我将不得不为每种类型创建每个实体类。所以我宁愿只有一个类并且有一个类型作为属性。
  2. 当您必须在同一页面中显示所有类型时，您将必须从所有 10 个表中针对 10 种类型执行选择查询。
  3. 当您引入新类型时，您必须为 CRUD 和业务特定操作编写代码。开发人员将继续为每种新类型添加代码。

基本上，如果您有一个项目表和一个类型表，您将不必为您引入的每种新类型更改数据库架构和代码。但是如果你确定类型的数量更少并且不会改变，你可以考虑使用多表。

于 2013-10-10T20:13:23.313 回答
0

如果您有很多表需要具有相同的重复列，那么是的，这是为公共字段创建单独表的好方法。如果这些重复的列不是固定的并且可以更改，例如在常见的默认列列表中再添加一列，这会更有效。

那你怎么能这样做呢？

这个想法是创建一个单独的表并将常用的默认列放在那里。该表就像一个虚拟表，即可以根据需要添加/删除列。

例如-

表-DefaultFields

列-item_title | item_description | item_thumbnail | item_keywords

然后，您还可以DefaultFields在循环中动态插入表中的值，例如：

"INSERT INTO DefaultFields (item_table, item_title , item_description,item_thumbnail ,item_keywords) VALUES('"+ field.item_table + "','" + field.item_title + "','" + field.item_description+ "','" + field.item_thumbnail  + "','" + field.item_keywords)");

注意：字段是在表格循环中保存值的对象。

然后，您可以进一步更改表以从DefaultFields表中创建这些默认字段，例如：

  "ALTER TABLE " + item_table+ " ADD COLUMN [" + field.item_title + "] Text"

可以对每个表重复此操作以根据需要对其进行更改。

在这个设计模式中，即使你想：

1）再添加一列或

2）删除预先存在的列或

3) 更改预先存在的列名

然后您可以在虚拟表中执行此操作，其余部分由相应表中的 ALTER table 命令更新。

于 2013-10-16T09:26:33.820 回答
0

我觉得signle table会更合适。它将避免更多的连接，程序（代码）中的复杂性和多个表的比较错误。从管理的角度来看，它甚至会更好，比如数据库集群等。

于 2013-10-16T07:54:28.470 回答
-1

在我看来......我会说不，永远不会。

有两个原因：

  • 您确实希望在数据库中保留逻辑含义。现在，它的组织方式对您来说非常明显。但在两个月（或一年）内，会如此明显吗？如果有人加入这个项目，他是否更容易理解你的应用程序的不同逻辑块是否分开？我的意思是... 人和猫确实是动物。将它们都存储在同一个盒子中仍然合乎逻辑吗？

  • 表现。表格越短，您的请求就越快。数据仍将占用磁盘上的空间。而且我不谈论了解您正在寻找哪种类型的项目的比较。我的意思是，如果您想选择应用程序的所有页面，只需比较两个请求：

多个表：

Select * from pages_tbl;

单表：

Select * from item_tbl where type = 'page';

你将从这个设计中获得什么？没有性能，没有磁盘空间，没有可读性。我真的看不出有什么好的理由。

于 2013-10-02T11:28:26.507 回答