小编jl6*_*jl6的帖子

我有一个应用程序，它在 SQL Server 2008 数据库（非集群）中创建了数百万个表。我想升级到 SQL Server 2014（集群），但在负载下时遇到错误消息：

“数据库中已经有一个名为'PK__tablenameprefix__179E2ED8F259C33B'的对象”

这是系统生成的约束名称。它看起来像一个随机生成的 64 位数字。由于大量表，我是否可能看到冲突？假设我有 1 亿张表，我计算出在添加下一张表时发生碰撞的可能性不到 1 万亿分之一，但这是假设均匀分布的。SQL Server 是否有可能在 2008 和 2014 版本之间更改其名称生成算法以增加冲突的几率？

另一个显着差异是我 2014 年的实例是一个集群对，但我正在努力形成一个假设，为什么会产生上述错误。

PS 是的，我知道创建数百万个表是疯狂的。这是我无法控制的黑盒 3rd 方代码。尽管疯狂，但它在 2008 版中有效，现在在 2014 版中无效。

编辑：仔细检查，生成的后缀似乎总是以 179E2ED8 开头 - 这意味着随机部分实际上只是一个 32 位数字，每次添加新表时，冲突的几率仅为 50 分之一，这与我看到的错误率更接近！

假设我有一个名为 Software 的实体和两个子类型 FreeSoftware 和 NonFreeSoftware。NonFreeSoftware 实体具有购买日期、供应商等属性。 FreeSoftware 实体具有许可证、源代码 url 等属性。

因此，如果我想为另一个实体（OperatingSystem）建模，我应该怎么做？与软件存在“是一种”关系，但与自由软件和非自由软件存在“非此即彼”的关系。

我想我在分析这个层次结构的方式中遗漏了一些东西。

如果我使用下表设计来捕获历史...：

CREATE TABLE MyTable (
    insertion_timestamp TIMESTAMP,
    deleted_flag BOOLEAN,
    natural_key INT,
    attribute VARCHAR
);

...那么主键应该是什么？

（历史记录机制是INSERT-only：更新的行插入不同的insertion_timestamp，删除的行插入不同的时间戳并deleted_flag设置为true。）

我在想PRIMARY KEY (insertion_timestamp, deleted_flag, natural_key)，但包含的唯一原因deleted_flag是考虑到插入行然后（软）立即删除的可能性，比TIMESTAMP数据类型粒度的下一个刻度要早。这感觉太偏执了......

我还没有找到与about PostgreSQL页面相当的内容，特别是涵盖了大对象设施的限制，但从字里行间看，我认为以下内容是正确的：

1. 不能存储超过 32TB 的大对象（原因：它们都存储在一个名为 的表中pg_largeobject，每个表的大小限制为 32TB（假设默认页面大小））。
2. 不能存储超过 2^32 个大对象（原因：主键pg_largeobject是 an oid，是一个 32 位的数量）。
3. pg_largeobject 不能分区（原因：因为是系统目录？）

这一切都正确吗？

如果我有一个视图（等）的视图，有没有办法显示这个扩展/展平的完整查询？

我知道循环不能用标准 SQL 表示。它不能执行哪些其他形式的处理？

我所说的元数据是指诸如：

• 实体的所有者
• 与实体关联的权限
• 数据输入的日期和时间
• 输入数据的保证
• 文本属性的格式
• 属性的描述性名称

据我所知，这只是数据。我可以通过给一个实体表一个用户表的外键来实现实体所有权；我可能会将所有文本字段存储为两个字段：内容和格式。等等...

就实际的数据库设计而言，数据和元数据之间有什么区别吗？为什么我可能想将元数据存储在数据库以外的地方？