用于跟踪营销网站中的随机设置的数据库模式答案

【问题标题】：Database schema to track random settings in website for marketing用于跟踪营销网站中的随机设置的数据库模式
【发布时间】：2010-09-14 09:58:40
【问题描述】：

我有基于 Flex 的消费者 website，我想在其中根据随机和其他标准更改各种外观和感觉类型设置，然后跟踪这些设置以产生最多的销售额。

例如，我可能会完全关闭主页，根据人们来自哪里显示不同的内容。我可能会显示或隐藏某些功能，或更改某些文本。我可能改变的事情还没有定义，可能会变得相当复杂。

我想设计最灵活的数据库架构，但它必须高效且易于搜索。目前我有一个“SiteVisit”表，其中包含有关每个不同访问者的信息。

我想在包含每个设置的列的单个表与仅包含键值对的表之间找到适当的平衡。

有什么建议吗？

【问题讨论】：

标签： database-design schema customization entity-relationship

【解决方案1】：

好的，这很棘手。我之所以这么说是因为您要求两件事：

宽松的存储库架构，以便您可以存储各种数据并更改以后动态保存的内容
固定的数据库架构，以便您可以有效地查询数据

解决方案将是妥协。你必须明白这一点。

假设您有 User 表：

+----------------
| User
+----------------
| UserId (PK)
| ...
+----------------

1) XML blob 方法您可以将数据作为博客（大 XML）保存到表中（实际上是一个属性包），但查询（过滤）将是一场噩梦。

+----------------
| CustomProperty
+----------------
| PropId (PK)
| UserId (FK)
| Data of type memo/binary/...
+----------------

优点是您（业务逻辑）拥有架构。这同时也是该解决方案的缺点。另一个巨大的缺点是查询/过滤将非常困难和缓慢！

2) 每个属性的表另一种解决方案是为每个属性（主页等）制作一个特殊的表。该表将包含每个用户的价值（基于 FK 的对 User 表的关系）。

+----------------
| HomePage
+----------------
| HomePageId (PK)
| UserId (FK)
| Value of type string
+----------------

这种方法的优点是您可以非常快速地查看该属性的所有值。缺点是您将拥有太多表（每个自定义属性一个），并且您会在查询操作期间经常连接表。

3) 自定义属性表在此解决方案中，您有一个包含所有自定义属性的表。

+----------------
| CustomPropertyEnum
+----------------
| PropertyId (PK)
| Name of type string
+----------------

+----------------
| CustomProperty
+----------------
| PropId (PK)
| PropertyId (FK)
| UserId (FK)
| Value of type string
+----------------

在此解决方案中，您将所有自定义属性存储在一个表中。您还有一个特殊的枚举表，可以让您更有效地查询数据。缺点是在查询操作过程中会经常连接表。

自己选择。我会根据您的工作量在 2 和 3 之间做出决定（很可能是 3，因为它更容易）。

【讨论】：

【解决方案2】：

这是使用 NoSQL 数据库的经典案例。它可用于轻松存储各种键值对，无需任何预定义模式。

【讨论】：