Database design 用于跟踪网站中随机设置以进行营销的数据库架构

我有一个基于Flex的消费者，我想根据随机标准和其他标准更改各种外观和感觉类型设置，然后跟踪这些设置，以获得最大的销售额

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

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

我想在每个设置都有列的单个表和只包含键值对的表之间找到适当的平衡

---

有什么建议吗

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

• 放松了存储库模式，这样您就可以存储各种数据并更改以后动态保存的内容
• 固定的数据库模式，以便您可以有效地查询数据

解决办法将是妥协。你必须明白这一点

假设您有用户表：

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

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

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

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

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

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

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

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

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

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

---

自己选择。我会根据您的工作负载在2和3之间做出选择（最有可能是3，因为这更容易）。

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

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

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