我正在对模式演变进行分析，但实际上并没有真正实现一些演变并存储在版本控制中的真实世界数据库模式。到目前为止， Mediawiki（http://svn.wikimedia.org/svnroot/mediawiki/trunk/phase3/maintenance/tables.sql）似乎是一个非常好的候选者。我考虑过Bugzilla，但它们似乎没有像Mediawiki 那样的主干中的.sql 文件。必须执行构建数据库架构/表的 Perl 脚本 - 因此，我现在基本上必须下载整个 Bugzilla 文件夹以进行不同的修订，以了解架构更改，而不是像在 mediawiki(tables.sql) 中那样只获取一个文件。

问题 1： 我想知道你们中是否有人知道或使用过大型数据库模式，这些模式是开源的，处于修订控制之下，并且更改大到足以进行模式演化分析（最好有 DDL 脚本 - .sql 文件）。

问题 2： 此外，您是否遇到过任何可以对 .sql 文件（DDL 脚本）提供分析（表/列数、修订之间的补丁等）的工具。我发现的所有工具都需要在对它们进行任何分析之前将 .sql 文件加载到数据库中。

对于这两个问题，首选 MySQL 或 Postgres 作为数据库。

我感谢这个社区的其他成员的任何回应。

谢谢，

文卡特什曼陀罗巴

我正在寻找可用于实现关系模型的持久数据结构的材料。

不可变数据结构含义的持久性。

有人知道一些好的资源、书籍、论文等吗？

（我已经有书Purely Functional Data Structures，这是我正在寻找的一个很好的例子。）

在设计表格时，我养成了一个习惯，即拥有一个唯一的列并且我将其作为主键。这可以根据要求通过三种方式实现：

1. 自动递增的标识整数列。
2. 唯一标识符 (GUID)
3. 可用作行标识符列的短字符 (x) 或整数（或其他相对较小的数字类型）列

数字 3 将用于相当小的查找，主要是读取可能具有唯一静态长度字符串代码或数值（例如年份或其他数字）的表。

在大多数情况下，所有其他表都将具有自动递增的整数或唯一标识符主键。

问题:-)

我最近开始使用没有一致行标识符的数据库，并且主键当前聚集在各个列中。一些例子：

• 日期时间/字符
• 日期时间/整数
• 日期时间/varchar
• 字符/nvarchar/nvarchar

这有一个有效的案例吗？我总是会为这些情况定义一个身份或唯一标识符列。

此外，还有很多表根本没有主键。有什么正当理由（如果有的话）？

我试图理解为什么桌子被设计成原来的样子，这对我来说似乎是一团糟，但也许有很好的理由。

第三个问题可以帮助我破译答案：在使用多列组成复合主键的情况下，这种方法与代理/人工键相比是否有特定优势？我主要考虑性能、维护、管理等方面的问题？

这让我怀疑了一段时间，所以我认为将它发布在这里以找到一些见解是个好主意，这是一个关系数据库建模问题/怀疑

我有以下问题：

我有必须处于特定“状态”的“问题”，并且必须审核所有状态更改。

我找到了两种解决方案，但我真的看不出它们之间的区别，如果有的话......你怎么看。

这是两个图表的图像。

编辑：

选项 A：表“questions”不应包含 state_id，并且 Question_State 不应包含“id”字段。对错误感到抱歉。

编辑2：

感谢所有现实世界的例子和洞察力，但这是一个学术问题，与现实世界无关:)。

在一个全新的程序中，空间并不是什么大问题，是删除一行还是禁用一行更好，让我们说一个布尔值“禁用”并让程序忽略它？

例如，如果我想从程序中删除用户。

我有一个前缀特里。在关系数据库中表示这种结构的推荐模式是什么？我需要子字符串匹配以保持效率。

我有一个表，其中每一行都有一些字段，这些字段的 ID 与其他表中的一些其他数据相关。

假设它被称为people，每个人的 ID 为acity和。statecountry

所以会有另外三个表，，cities每个表都有一个 ID 和一个名称。statescountries

当我选择一个人时，在单个查询中获取,和的名称的最简单方法是什么？citystatecountry

注意：我知道这可以通过连接实现，但是由于有更多相关表，嵌套连接使查询难以阅读，我想知道是否有更简洁的方法。该人也应该可以将这些字段留空。

我有一个数据库任务，我必须为两个问题创建一些关系代数。我对它的大部分感觉都很好，但是当我试图从一个连接到另一个表的表中投影属性时我只是感到困惑。

例如，这是正确的吗？

Q1) 列出未拨打电话的事件的详细信息，以便接待员知道哪些事件仍需要呼叫。

我试图解释为关系代数的 SQL 是：

任何意见将不胜感激。

为什么我应该使用像 CouchDB 这样的基于文档的数据库而不是使用关系数据库。是否存在基于文档的数据库比关系数据库更适合的典型应用程序或领域？

您是否知道不使用像 Hibernate 这样的关系 DB / ORM在 Java 中存储和检索对象的“简单”方法？

[请注意，我没有为此考虑按原样进行序列化，因为它不允许检索对象图中间的任意对象。我也不考虑 DB4O，因为它有限制性许可。谢谢。]

“简单”的意思是：不必处理诸如键/值对之类的低级细节来重建对象图（与 BerkeleyDB 或传统缓存一样）。这同样适用于从面向文档或面向列的数据库（CouchDB、HBase、...，甚至 Lucene）重建对象。

也许有一些有趣的项目在上述存储系统和我不知道的对象模型（如 ORM 用于 RDBMS）之间提供了一层集成。

任何人成功地在生产中使用它们，或者尝试使用关系数据库以外的持久性策略？RDF 商店怎么样？

更新：我遇到了一篇非常有趣的文章：分布式键值存储列表