小部件驱动的站点的数据库架构建议

Question

我目前正致力于重建我的网站数据库。由于我现在的模式不是最好的模式之一，我认为听取你的一些建议会很有用。

首先，我的网站实际上包含小部件。对于每个小部件，我需要一个settings的表（其中小部件的每个实例都有其用户定义的设置），common的表（同一小部件​​的实例之间的共享项）和{{1} （用户在小部件实例中保存的数据）。

到目前为止，我有以下架构，由2个数据库组成：

• 第一个数据库，我有所有站点维护表（例如用户，安装了小部件，日志，通知，消息等）。加上一个表，我将每个小部件实例加入到实例化的每个用户，并分配了一个唯一的ID（所以，我有以下列：userdata，user_id和widget_id）。
• 第二个数据库，我保存了所有与小部件相关的数据。这意味着，对于每个小部件（由unique_id唯一），我有三个表：widget_id，[widget_id]_settings和[widget_id]_common。在每个表中，每行保存用户小部件的[widget_id]_userdata。实际上，这里存储了一个小部件中的所有用户数据。

举一个关于我的数据库如何工作的简短例子：

第一个数据库：

• 在unique_id表中，我有users
• 在user_id = 1表中，我有widgets
• 在widget_id = 1表中，我有users_widgets

第二个数据库：

• 在user_id = 1, widget_id = 1, unique_id = 1我有1_settings，其中......代表用户的小部件设置
• 在unique_id = 1, ...我有几行代表同一小部件​​实例之间的共享数据（因此，此处没有用户特定数据）
• 在1_common我有1_userdata，其中......代表用户的小部件数据。这里一个重要的通知是，此表可能包含多个具有相同unique_id = 1, ...的行（例如，对于任务窗口小部件，用户可以为窗口小部件实例执行多个任务）

希望您能在粗略的数据库架构中理解。

现在，我想开发一个“更清洁”的模式，因此没有必要在我的应用程序中拥有2个数据库并且每次都从一个数据库切换到另一个数据库。如果我找到一种不在第二个数据库（1_settings，2_settings，...，n_settings）中动态生成表格的方法，也会很棒。

我将非常感谢任何建议任何更好的方法来实现这一目标。非常感谢你提前！

修改 重构我的数据库时，我是否会想到像MongoDB或CouchDB这样的数据库？我的意思是，对于第二个数据库，如果我没有固定的模式会更好。 另外，传统的SQL和NoSQL如何在同一个网站上相处？

Answer 1

users_widgets表的可能架构可能是：

id | user_id | widget_id

您不需要unique_id表中的users_widgets字段，除非您出于某种原因要隐藏主键。实际上，我会将此表重命名为widget_instances更令人难忘的内容，并在第二个数据库的其余表中使用widget_instance_id。

处理第二组表格的一种方法是使用元数据样式：

<强> widget_instance_settings

id | widget_instance_id | key | value

这将包括userdata，因为user_id与widget_instance_id相关，除非您希望允许用户创建同一小部件​​的多个实例，并且由于某种原因在所有实例中具有相同的数据。

<强> widget_common_settings

id | widget_id | key | value

这种类型的架构可以在像Elgg这样的包中看到。

Answer 2

您知道窗口小部件类和窗口小部件实例可能具有的设置吗？在这种情况下，这些设置可以是widget_class表（用于常见设置）和widget_instance（例如特定设置）的列。 如果您不了解它们，那么您可以拥有一个与widget_class表具有多对一关系的widget_class_settings表，以及与widget_instance表具有多对一关系的widget_instance_settings。在widget_instance和widget_class之间，您可以再次拥有多对一关系。 widget_instance还可以在users表中具有外键，以便您知道哪个用户创建了特定的小部件。