2

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

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

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

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

有什么建议么？

4

2 回答 2

3

好的，这非常棘手。我这么说的原因是因为你要求两件事：

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

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

假设您有 User 表：

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

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

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

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

2) 每个属性的表 另一种解决方案是为每个属性（主页等）制作一个特殊的表。该表将包含每个用户的价值（基于 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，因为它更容易）。

于 2009-03-09T20:30:26.727 回答
1

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

于 2014-07-22T22:55:43.843 回答