问题标签 [database-design]

The situation: we have a large database with a number of denormalized tables. We frequently have to resummarize the data to keep the summary tables in synch. We've talked on and off about using computed columns to keep the data fresh. We've also talked about triggers, but that's a separate discussion.

In our summary tables, we denormalized the table such that the Standard ID as well as the Standard Description is stored in the table. This inherently assumes that the table will be resummarized often enough so that if they change the standard description, it will also change it in the summary table. A bad assumption.

Question: What if we made the Standard Description in the summary table a derived/computed column which selects the standard description from the standard table? Is there a tremendous performance hit by dropping a computed column on a table with 100,000-500,000 rows?

我最近继承了维护数据库的工作，该数据库设计得不是很好，而且设计人员无法提出任何问题。在不久的将来，我还有更多的机会。

在没有任何视觉帮助或数据库图表的情况下试图找出表之间的关系是很困难的。

我想知道为此推荐什么工具。我知道 Visio，但我希望那里有一些好的开源/免费软件应用程序。我根本不需要它来更改数据库。只需阅读它并创建某种视觉辅助工具来帮助我了解事物的布局方式，并尝试弄清楚设计师在考虑数据应该如何关联。

附加答案数据： SchemaSpy 是我一直在寻找的那种东西，但多年来没有对命令行做过很多事情，我选择使用SchemaSpyGUI。还有一些配置需要习惯，因为我不经常使用 Java，但最终结果是我正在寻找的（关于 Visio 的 ER 图的开源替换）。

这是我多年来在多个地方看到的场景。我想知道是否有人遇到过比我更好的解决方案...

我的公司销售的产品数量相对较少，但我们销售的产品是高度专业化的（即，为了选择给定的产品，必须提供大量的详细信息）。问题在于，虽然选择给定产品所需的细节数量相对恒定，但所需的细节种类在产品之间却有很大差异。例如：

产品 X 可能具有识别特征，例如（假设地）

• '颜色'，
• '材料'
• “平均失败时间”

但产品 Y 可能具有特征

• '厚度'，
• '直径'
• '能量源'

创建一个同时使用产品 X 和产品 Y 的订单系统的问题（其中之一）是订单行必须在某些时候引用它“销售”的内容。由于产品 X 和产品 Y 是在两个不同的表中定义的 - 并且使用宽表方案对产品进行非规范化不是一种选择（产品定义非常深） - 很难找到一种明确的方法来定义订单行订单输入、编辑和报告的实用性。

我过去尝试过的事情

• 创建一个名为“产品”的父表，其中包含产品 X 和产品 Y 共有的列，然后使用“产品”作为 OrderLine 表的引用，并在产品 X 的表之间创建一个以“产品”作为主要侧的 FK 关系和产品 Y。这基本上将“产品”表作为 OrderLine 和所有不同产品表（例如产品 X 和 Y）的父级。它适用于订单输入，但会导致订单报告或编辑出现问题，因为“产品”记录必须跟踪它是什么类型的产品，以确定如何将“产品”加入其更详细的子产品、产品 X 或产品Y.优点：保留了关键关系。 缺点：在订单行/产品级别进行报告、编辑。
• 在订单行级别创建“产品类型”和“产品密钥”列，然后使用一些 CASE 逻辑或视图来确定该行所指的定制产品。这类似于第 (1) 项，但没有通用的“产品”表。我认为它是一个更“快速和肮脏”的解决方案，因为它完全消除了订单行及其产品定义之间的外键。优点：快速解决。 缺点：同第（1）项，加上丢失RI。
• 通过创建一个通用标题表并使用自定义属性的键/值对（OrderLine [n] <- [1] Product [1] <- [n] ProductAttribute）来同质化产品定义。 优点：保留关键关系；产品定义没有歧义。 缺点：报告（例如，检索带有属性的产品列表）、属性值的数据类型、性能（获取产品属性、插入或更新产品属性等）

如果其他人尝试了不同的策略并取得了更大的成功，我肯定想听听。

谢谢你。

我知道 SQL Server 全文索引不能索引多个表。但是，我想在表中实现全文索引的关系。

拿下面的3张桌子...

Attributes 和 AttributeTypes 表包含的值可以在整个正在构建的应用程序的下拉列表中使用。例如，属性类型为“车辆颜色”，属性为“黑色”、“蓝色”、“红色”等...

好的，所以当用户尝试搜索“Blue Ford Mustang”时问题就来了。那么考虑到像 Vehicle 这样的表会变得相当大，最好的解决方案是什么？

我是否在“车辆”表中创建另一个字段，即“车辆颜色”，除了“FK Atr VehicleColor”之外，它还保存下拉列表中选择的文本值？

或者，我是否完全放弃“FK Atr VehicleColor”并添加“Veh Color”？当下拉列表填充到更新表单中时，我可以使用“Veh Color”的文本值来匹配“Atr Name”。使用这种方法，如果从数据库中删除属性，我将不得不处理。

- 注意：不能在代码视图之外使用下划线，因为两个下划线之间的所有内容都是斜体。

(Not related to versioning the database schema)

Applications that interfaces with databases often have domain objects that are composed with data from many tables. Suppose the application were to support versioning, in the sense of CVS, for these domain objects.

For some arbitry domain object, how would you design a database schema to handle this requirement? Any experience to share?

我想知道是否有一种干净的方式来表示 is-a 关系，如下例所示：

该数据库存储三种类型节目的录制时间：电影、游戏节目、戏剧。在面向对象的意义上，这些中的每一个都是一个程序。这些子类中的每一个都有不同的属性。以下是表格（fk 前缀表示外键）：

电影
ID
名称
fkDirector

gameShow
id
name
fkHost
fkContestant

剧 名
_

在 OO 术语中，记录表看起来像这样：

record
id
fkProgram
startTime
endTime

在不违反常规形式的情况下，我能想到的唯一方法是拥有三个记录表，即 recordMovie、recordGameShow和recordDrama。

有没有办法在不违反数据库规范化原则的情况下将这些表合并为一个？

以下是一些无效的示例来说明这个想法：

程序
id
fkMovie
fkGameShow
fkDrama

该表违反了第一范式，因为它将包含空值。对于每一行，3 个条目中只有一个不为空。

program
id
fkSpecific ← fkMovie OR fkGameShow OR fkDrama
fkType ← 将指示要查看的表

在这里，我将无法强制执行参照完整性，因为 fkSpecific 可能指向三个表之一。

我只是想节省在这里有 3 个表而不是一个的开销。也许这根本不适用于 RDB。

你们能推荐一些支持 SQL Server、PostgreSQL 和 MySQL 的经济实惠的 SQL 建模工具吗？我正在研究每个许可证范围最高 300 美元。请每个答案一个工具！

谢谢！

在我参与的几个 Web 应用程序项目中，客户要求能够创建自己的表单。问题出现在如何存储他们的表单定义，然后如何将用户输入的值存储到这些自定义表单中。

我已经看到它做了两种方式：

1. 假设客户端只定义了多少个字段，以及与这些字段相关联的标签；我们可以得出一个涉及四个表的解决方案。 FormDefinition, FormFieldDefinition, FormInstances, FormFieldValues. FormDefinition客户端对and进行更改FormFieldDefinition，Web 应用程序使用该信息呈现 HTML Web 表单，网站访问者（最终用户）将在该表单上提交表单，其中FormInstances创建新行并将值保存在FormFieldValues桌子。

   行中的FormDefinition定义形式，即form definition ID = 2, form title = 'Car Registration Form'。中的行FormFieldDefinition定义表单中的字段FormDefinition，即field definition ID = 7, field label = 'Car Model', field type = 'varchar(50)'。Rows inFormInstance是用户填写的每个表单的一个实例，即definition id = 2, date_entered = '2008-09-24'. 中的行FormFieldValues是用户的条目，即field definition = 7, value = 'Tiburon'.

   不幸的是，这意味着其中的值列FormFieldValues必须是您的客户可能在 Web 表单中指定的最大可能大小的 char 类型......并且当表单定义更改时，管理旧数据变得不确定。但是用户条目是可查询的（我写了一个快速查询，列出了给定表单 id 的用户条目，这类似于另一个 pivot question）。

2. 使用四个表的替代方法是将表单定义和用户的表单条目序列化为 XML（或 YAML 或类似的东西）并将其存储为文本。好处是表格在数据库中是人类可读的。缺点是解析 XML 会产生更多的应用程序开销，并且从 SQL 的角度来看，数据库的可查询性会大大降低。

我真正的问题是，这个数据库模型叫什么？（所以我可以用谷歌搜索这个问题。）但我会选择一个答案：哪个是更好的实现，或者那里有更好的（或同样好的）实现？

我正在尝试设计一些表来存储一些数据，这些数据稍后必须转换为不同的语言。任何人都可以为此提供一些“最佳实践”或指导方针吗？

谢谢

我的产品责任范围内的一张表被批评为具有多个正交索引。

什么是正交索引？
为什么不好？
如何避免这种情况？

--Update--
后端数据库引擎在这里不一定相关，因为我们的应用程序与数据库无关。但如果它有帮助，甲骨文是一种可能性。

有问题的表格不用于财务分析。