4

假设我有 N 个书店的 N 个表。我必须将有关书籍的数据保存在每个书店的单独表中，因为每个表都有不同的方案（列的数量和类型不同），但是所有 Bookstores 表都有相同的列集；

现在我想创建一个只有几列的“MasterTable”。

|   MasterTable   |
|id. | title| isbn|     
| 1  | abc  | 123 |


| MasterToBookstores |
|m_id | tb_id | p_id |
| 1   |   1   |  2   |
| 1   |   2   |  1   |


|       BookStore_Foo          |
|p_id| title| isbn| date | size|     
| 1  | xyz  | 456 | 1998 | 3KB |
| 2  | abc  | 123 | 2003 | 4KB |

|       BookStore_Bar                  |
|p_id| title| isbn| publisher | Format |     
| 1  | abc  | 123 |   H&K     |   PDF  |
| 2  | mnh  | 986 |   Amazon  |   MOBI |

我的问题是，以这种方式保存数据是否正确？关于这个案例和类似案例的最佳实践是什么？我可以给特定的书店表一个带数字的别名，这将帮助我管理整组表吗？

有没有更好的方法来做这样的事情？

4

4 回答 4

5

我认为您混淆了“商店”和“书”的概念。

从您的评论和示例数据来看，问题似乎在于书籍的属性集不同，而不是商店。如果是这样，您将需要一个类似于此的结构：

在此处输入图像描述

符号:在此处输入图像描述表示继承1。BOOK 是“基类”，BOOK1/BOOK2/BOOK3 是各种“子类” 2。当实体共享一组属性或关系时，这是一种常见的策略3。有关此概念的更完整解释，请在ERwin 方法指南中搜索“子类型关系” 。

不幸的是，当前的关系数据库不直接支持继承，因此您需要将此层次结构转换为普通表。这样做通常有 3 种策略，如这些帖子中所述：

注意：上述结构允许在同一书店内混合各种书籍类型。让我知道这是否不可取（即，您在任何给定的书店中都需要一种类型的书籍）...

1阿卡。类别、子类化、子类型化、泛化层次结构等。

2即书籍的类型，取决于它们需要哪些属性。

3在这种情况下，所有类型的书籍都与商店是多对多的关系。

于 2013-03-26T22:03:13.890 回答
4

如果您至少有两列所有其他表都使用它，那么您可以为所有书籍创建基表，并使用基表中的 id 为其余数据添加更多表。

更新：

如果您使用实体框架连接到您的数据库，我建议您试试这个：

创建您的实体模型，如下所示：

实体模型

然后让实体框架为您生成数据库（从模型更新数据库）。请注意，这使用继承（不在数据库中）。

如果您有任何问题，请告诉我。

于 2013-03-20T02:44:49.327 回答
2

建议数据模型：
1. 有一个master 数据库，保存master 数据
2. master 数据库中的维度表，transitional 复制到你的分布式书店数据库
3. 可以选择使用可更新的scriscriber 或者merge replication 也是不错的选择
4.每个分布式书店数据库仍然独立工作，但是主数据要么通过合并复制或可更新订阅者合并回来。
5、如果要保证主数据的完整性，只能只读订阅者，使用跨式复制将主数据分发到分布式数据库中，但是在这种设计中，你需要在主数据库中有存储过程来注册你的维度数据。确保没有双跳问题。

于 2013-03-20T03:39:26.120 回答
2

我建议你有两张桌子：

书店：

id name someMoreColumns

书籍：

id bookStore_id title isbn date publisher format size someMoreColumns

很容易看出这里的关系： abookStore有很多books.

请注意，我将所有表中的所有列都放在BookStore一个表中，即使某个表中的某些行对某些列没有值也是如此。

为什么我更喜欢这种方式：

1）对于BookStore表中的所有数据，只有少数列永远不会在表上具有值books（例如，size如果format您没有电子书版本）。其他列总有一天会被填满（你可以date为你的电子书设置一个，但你的桌子上没有这个列BookStore_Bar，这似乎是指电子书）。这样，如果有一天您想更新它，您可以从所有书籍中获得更详细的信息。

2）如果你有一堆表BookStore，比如说 12 个，你将无法轻松处理你的数据。我要说的是，如果您想对所有书籍（这意味着对所有表）运行一些查询，您将至少有三种方法：

  • 首先：手动运行对 12 个表中的每一个的查询，从而合并数据；

  • 第二：编写一个有 12 个连接的查询或在您的FROM子句上设置 12 个表来查询您的所有数据；

  • 第三：依赖一些脚本、存储过程或软件为你做我刚才说的第一种或第二种方式；

我希望能够尽可能轻松地处理我的数据，并且不依赖其他脚本或软件，除非我真的需要它。

3）从 MySQL 开始（因为我对 MySQL 了解更多），您可以partitions在表上使用books。它是一种高级数据管理，您可以将表中的数据分配到磁盘上的多个文件中，而不是像通常分配一个表那样只分配一个文件。在处理同一张表中的大量数据时非常有用，它可以根据您的数据分布计划加快查询速度。让我们看一个例子：

假设您已经有 12 个不同的书店，但在我的数据库模型下。对于表中的每一行，您books都将关联到 12 个书店之一。如果您对数据进行分区bookStore_id，它将几乎与您有 12 个表相同，因为您可以为每个表创建一个分区bookStore_id，因此每个分区将仅处理相关数据（与 匹配的数据bookStore_id）。

假设您要查询表books到bookStore_idin (1, 4, 9)。如果您的查询确实只需要这三个分区来为您提供所需的输出，那么将不会查询其他分区，并且它将与您查询每个单独的表一样快。

您可以删除一个分区，另一个不会受到影响。您可以添加新分区来处理新书店。您可以对分区进行子分区。您可以合并两个分区。简而言之，您可以将您的单张桌子变成books一个易于处理的多存储桌子。

副作用：

1）我不知道所有的表分区，所以最好参考文档来了解创建和管理它的所有要点。

2）通过定期备份（转储）来处理数据，因为您可能有一个非常填充的表books。

我希望它对你有帮助！

于 2013-03-27T02:38:36.153 回答