问题标签 [database-design]

人们成功地使用了哪些策略来维护相当复杂的数据库中数据的更改历史记录。我经常使用和开发的应用程序之一可以真正受益于更全面的跟踪记录随时间变化的方式。例如，现在记录可以有许多时间戳和修改的用户字段，但我们目前没有记录多个更改的方案，例如，如果操作回滚。在一个完美的世界中，可以在每次保存后重建记录，等等。

关于数据库的一些信息：

• 需要有能力每周增加数千条记录
• 50-60 桌
• 主修订表每个可能有几百万条记录
• 设置合理数量的外键和索引
• 使用 PostgreSQL 8.x

假设我有一个包含三个 10 字段的表单：field1..field10。我将表单数据存储在一个或多个数据库表中，可能使用 10 个数据库列。

现在假设几个月后我想再添加 3 个字段。将来我可能会根据不断变化的要求在此表单中添加/删除字段。如果每个表单字段都有一个数据库列，那么每次更改表单时都必须对数据库进行相应的更改。这似乎是一个令人头疼的维护问题。必须有更复杂的方法。

所以我的问题是，我如何设计一个与我的 UI 松散耦合的数据模型？一个具体的用例是用户可扩展/可定制的 CRM 系统。

我有一个具有多个维度的多维 OLAP 多维数据集。其中一些维度具有层次结构。用户希望通过更改维度中的层次结构对多维数据集中的度量执行“假设”分析。

例如，他们想知道部门之间的员工调动对部门资源预算的影响，或者产品从一个工厂转移到另一个工厂时制造成本的变化。

有没有人在现代 OLAP 引擎中有直接的方法来做到这一点？

我有一个需要创建的新数据库表...
它在逻辑上包含一个ID、 aname和 a "value"。
该值字段本质上可以是数字或字符串。

我不认为我只想将字段设为 a varchar，因为我还希望能够使用诸如此类的过滤器进行查询WHERE value > 0.5。

在 SQL Server 2005 中对该概念建模的最佳方法是什么？

编辑： 我不反对在这里创建多个字段（一个用于数字，一个用于非数字），但由于它们都是同一个概念，我不确定这是一个好主意。
我想我可以创建单独的字段，然后有一个视图将它们合并到一个逻辑列中。

对此有何看法？

我想要实现的非常简单......通常这些数据只会盲目地显示在网格类型的视图中。
我还希望能够过滤该网格中的数值。这张表最终会在几千万条记录中，所以我不想把自己画到查询性能的角落里。
查询性能是我主要关心的问题。

在我们正在进行的项目中，我们需要一个“评级”系统，类似于 SO 中的系统。但是，在我们的系统中，有多个实体需要通过投票来“标记”（仅向上，从不向下，就像增量一样）。有时我们需要按照评分最高的顺序显示所有实体，不管实体类型如何，我猜基本上是混合结果集。您使用什么数据结构/算法来实现这一点，以便灵活且仍可扩展？

哪个数据库表模式更有效，为什么？

或者

鉴于用户和公司具有一对一的关系。

您使用哪些方法来建模和检索数据库中的分层信息？

我们在项目中需要存储数据库中实体的所有修订（更改历史）。目前，我们为此设计了 2 个提案：

例如对于“员工”实体

设计一：

设计二：

有没有其他方法可以做这件事？

“设计 1”的问题在于，每次需要访问数据时，我们都必须解析 XML。这将减慢进程并增加一些限制，例如我们无法在修订数据字段上添加连接。

“设计 2”的问题是我们必须在所有实体上复制每个字段（我们有大约 70-80 个实体需要维护修订）。

我希望使用存储在 Oracle 数据库中的问题树来实现一个数据驱动的向导。在不牺牲太多性能的情况下，使数据库部分灵活（即易于添加新的问题路径）的最佳模式是什么？

系统中有几种类型的对象，每种对象在数据库中都有自己的表。用户应该能够对其中任何一个进行评论。您将如何设计评论表？我能想到几个选择：

1. 一个评论表，每个对象类型（ObjectAID、ObjectBID 等）都有一个 FK 列
2. 多个注释表，每个对象类型一个（ObjectAComments、ObjectBComments 等）
3. 一个通用 FK (ParentObjectID) 与另一列指示类型 ("ObjectA")

你会选择哪个？有没有更好的方法我没有想到？