我有一个基于Flex的消费类网站，我希望根据随机和其他条件更改各种外观类型设置，然后跟踪这些设置，以了解带来最多销售的商品。

例如，我可能会完全关闭主页，根据人们来自何处显示不同的内容。我可能会显示或者隐藏某些功能，或者更改某些文本。我可能会更改的事情尚未定义，并且可能会变得非常复杂。

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

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

有什么建议？

解决方案

好的，这很棘手。我之所以这样说是因为我们要提出两件事：

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

解决方案将是一个折衷方案。你必须明白这一点。

假设我们有User表：

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

1)XML Blob方法
我们可以将数据作为博客(大XML)保存到表(实际​​上是属性包)中，但是查询(过滤)将是一场噩梦。

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

优点是我们(业务逻辑)拥有该模式。同时这是该解决方案的缺点。另一个巨大的缺点是查询/过滤非常困难且缓慢！

2)每个属性的表
另一种解决方案是为每个属性(首页等)创建一个特殊的表。该表将包含每个用户的值(对User表的基于FK的分配)。

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

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

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

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

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

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

为自己选择。我会根据工作量在2到3之间进行选择(最可能是3，因为这样比较容易)。