1

我的站点将提供许多产品，但它们将被分类到完全不同的站点（域）中。

我的问题是，我最好将所有产品集中到一个数据库中并使用 ID 来区分站点，还是应该为每个站点设置一个表和/或数据库？

这是我的想法

独立的数据库

  • 更容易从后端读取
  • 分类更好
  • 使备份更加困难
  • 如果我需要对架构进行更改，则需要将其推送到所有数据库

相同的数据库

  • 都在一个地方
  • 可能会变得笨拙
  • 一个数据库将具有巨大的文件大小，查找可能会受到影响

有人可以就哪种方式最好以及为什么给我一些建议吗？

4

4 回答 4

1

如果需要在所有站点之间共享数据，则建议共享同一个数据库，因为消除了数据传输。数据也更加集中。

如果不需要在所有站点之间共享数据，最好为每个站点拆分一个数据库。谈到更新表结构的困难，您可以简单地记录下您为一个数据库所做的更改（将 ALTER、UPDATE、DELETE 查询保存在 SQL 文件中），并使用相同的 SQL 文件更新其他数据库。

存储在不同的数据库中也可能有助于提高安全性。您可以为每个站点设置不同的用户权限。如果一个站点受到威胁，您可以保护其他站点。

此外，当数据库明确拆​​分时，您可以轻松维护和跟踪数据库。

于 2009-09-15T06:49:09.770 回答
1

您没有提供太多细节（这使得很难提供一个好的答案），尽管您在问题中选择使用的词语让我相信这是一个具有不同“皮肤”的单一应用程序。

我的站点将提供许多产品，但它们将被分类到完全不同的站点（域）中。

我的假设是您将拥有一个具有多个不同店面的网络商店：cool-widgets.com、awesome-sprockets.com、neato-things.com 等。这些都是相同的，除了可能有一个 CSS 皮肤或类似的简单的东西。商店管理的东西都将在某个中央系统中完成，域名将简单地充当类别名称。

因此，使用任意标准（category_name=='cool-widges.com'）将相同的数据分成两个不同的容器是数据分区，这是一种反模式。就像您不会有两个基于用户名的不同用户表（[Users$A-to-M] 和 [Users$N-to-Z]），拥有两个不同的表（或数据库）几乎没有意义) 用于类别名称。

在这些类别中有很多通用代码：用户管理、管理员、订单处理、数据导入等。在通用代码中聚合多个数据存储要比分离商店显示代码中的类别。不仅如此，隔离错误会更加明显：价格比较页面显示来自所有三个商店的商品。聚合错误会少得多：四个商店中只有三个被更新。这就是为什么它是一种反模式。

旁注：是的，在您说数据分割有其用途（确实如此）之前，这些用途是在性能问题发生之后才出现的。许多严肃的数据库平台允许幕后分区，以免创建愚蠢的数据模型。

于 2009-09-17T01:13:52.937 回答
0

正如您已经说过的，这两种选择都有其优点和缺点。既然您说的是两家商店，那可能并不重要。

但是，您可能想问自己几个问题：

  • 它真的会是两家商店，或者可能更多吗？如果更多，一个数据库可能更智能。
  • 产品真的一样吗？如果您必须将产品压缩到一个通用数据库中，因为它们属于不同类型（例如汽车与食物；您要存储的详细信息的数量和性质完全不同），那么不要；改用两个数据库/表。

核心问题是：未来最有可能变得更加精致的是：商店还是产品？

于 2009-09-15T06:45:23.787 回答
0

我认为单独的数据库会更容易。您可以拥有一个快速启动模板数据库，您可以从中构建一个新的商店数据库。您甚至可以创建一个通用数据库并包含通用表和商店列表及其数据库。毕竟，您可以使用限定名称访问同一服务器中的任何数据库，请注意：

SELECT value FROM CommonDB.currencies WHERE type='euro';
SELECT price FROM OldTownDB.Products WHERE id=newtownprodid;
于 2009-09-15T06:57:05.820 回答