小编nvo*_*gel的帖子

什么是Projection,在数据库理论和NHibernate方面使用SetProjection()？

图形数据库(例如Neo4J)和网络数据库(例如IDS,CODASYL)之间有什么区别？原则上他们是一回事吗？

主键提供哪些独特功能？

虽然我用舌头牢牢地把脸埋在脸颊上,我的问题很严肃.在任何火焰开始之前,我不是说在没有约束或参照完整性的情况下构建数据库.但是,据我所知,SQL Server可以取消primary key关键字.

• 独特的索引涵盖了唯一性
• 基于列的非可空性涵盖了PK的非可空性要求
• PK不必聚集,所以不是这样
• 外键可以并且通常使用唯一索引而不是PK来实现
• 甚至MSDN也声明创建了一个唯一索引来强制执行PK的唯一性

我确实同意逻辑上一个主键关于数据模型的一些意图,但它是什么？[讽刺]哦,我们确实得到了SSMS在设计桌子时显示的那个小钥匙图标![/讽刺]

编辑

从评论中可以看出,我没有像我想的那样清楚地问这个问题.我同意主键从逻辑角度来看很重要.

我不问:

• 我应该为我的PK选择一个int或一个varchar
• PK必须集群化,或者我如何识别应该集群的内容
• 我如何唯一地识别行

我的目的是问"PK提供哪些功能无法合理地使用其他功能实现？" 我不是建议在这里发疯 - 比如使用触发器来强制执行唯一性而不是唯一的约束/索引.合理是一个关键词 - 使用唯一索引/约束似乎非常类似于定义PK.

可以在包含NULL的列上创建唯一约束.但是,最多只有一行可能在该列中包含NULL.

我不明白为什么会这样,因为根据定义,NULL不等于另一个NULL(因为NULL实际上是一个未知值,一个未知值不等于另一个未知值).

我的问题:1.为什么会这样？2.这是针对MsSQL的吗？

我有一个预感,因为Unique Constraint可以充当外键的引用字段,并且如果存在多个具有NULL的记录,则FK否则将不知道它引用的引用表中的哪个记录.但是,这只是一种预感.

(是的,我知道UC可以跨多个列,但这不会改变问题;相反,它只会让它复杂化.)

自1995年首次出版Date和Darwen的"第三宣言"以来,已经过去了十多年.

在今天的数据库世界中,关系学派的地方是什么？有没有证据表明Manifesto的想法改变了主流软件开发和数据管理实践？他们是否催化了新数据管理产品的创建？这些产品是否商业化成功？

概述

一个事件数据库，它将有许多列保存查找表中保存的记录的 ID。

我试图解决的问题

我需要提出一个强大的解决方案来管理某些字段保存查找 ID 的历史数据。我已经列出了我提出的解决方案以及替代方案。我想从其他开发人员那里知道他们是否在他们的项目中以类似的方式管理这些场景。也许你有更好的方法？

数据库：Oracle 10g

列：部门名称

场景：部门名称在一年中可以更改 X 次。企业需要报告其所有部门的数据，但希望在其各自部门名称下查看事件，就像事件发生时一样。

建议的解决方案：在部门名称查找表中设置条目时，设置开始和结束日期值。使用视图，根据事件日期创建一个计算字段，以便在任何给定时间点访问正确的部门名称。

优点：通过一些防御性编码，它可以使选定用户的自助服务能够通过 GUI 管理他们的静态数据，而无需任何额外的数据库更改。可以即时更改，例如完全更改名称。不需要 DBA 支持。

缺点：考虑到在大型数据集上进行的查找/计算量，这可能是一项昂贵的操作。

替代解决方案：只需使用并插入部门名称的纯文本值。这里的缺点是临时请求需要 DBA 来更改/更新值，可能针对特定日期范围并错误地丢失一些记录。表空间消耗也会增加。

列：Assigned_Technician_ID

场景：事件将分配一名技术人员，技术人员的 ID 将存储在该位置。查找表将保存所有可用技术人员的“当前”列表。当人们离开公司时，必须更新列表并删除过时的技术人员。这是为了将下拉列表中的值数量保持在最低限度。企业仍希望查看分配给哪些技术人员处理所有事件数据。

解决方案：不要从技术人员查找表中删除条目，而是使用表示“已归档/已删除”的标志来标记该条目。此标志将作为 GUI 下拉菜单上的过滤器，以删除不需要的条目。

优点：查找表仅包含员工表中技术人员的 UID。因此，如果业务需求发生变化，很容易在主视图中呈现技术人员的任何属性，例如全名或员工编号等。

缺点：与前面的示例一样，查找可能是对大型数据集的昂贵操作。GUI 方面需要在业务逻辑和设计方面进行额外的工作。特别是在原始条目已“存档”时如何管理下拉列表。

替代解决方案：与上面的示例一样，只需使用纯文本值。这里的缺点是会消耗更多的表空间，并且随着不断变化的业务需求的灵活性降低。

这个问题来自我对CJ Date的SQL和关系理论的解读:如何编写准确的SQL代码并查找互联网上的连接(包括在NATURAL JOIN上发现多个帖子(以及关于SQL Server缺乏对它的支持) )

所以这是我的问题......

一方面,在关系理论中,自然连接是唯一应该发生的连接(或者至少是非常优选的连接).

另一方面,在SQL中建议不要使用NATURAL JOIN而是使用替代方法(例如带限制的内连接).

这些调和是:

• 自然连接在真正的RDBMS中工作.然而,SQL无法完全复制关系模型,并且没有一个流行的SQL DBMS是真正的RDBMS.

和/或

• 好/更好的表设计应该删除/最小化自然连接创建的问题.

？

Oracle ROWNUM之前已经应用过了ORDER BY.为了ROWNUM根据排序列放置,在所有文档和文本中提出以下子查询.

select *
from (
  select *
  from table
  order by price
)
where rownum <= 7

这让我很烦恼.据我所知,表输入FROM是关系的,因此没有存储顺序,这意味着子查询中的顺序在被看到时不被尊重FROM.

我不记得确切的情况,但这个" ORDER BY在外部查询中没有任何影响"的事实我不止一次阅读过.示例是内联子查询INSERT,ORDER BYPARTITION子句的子查询等.例如

OVER (PARTITION BY name ORDER BY salary)

外部查询中不会遵守工资订单,如果我们希望在外部查询输出中对工资进行排序,则ORDER BY需要在外部查询中添加另一个工资.

每个人都有一些关于为什么关系属性在这里不受尊重和订单的见解存储在子查询中？

我正在努力了解 MySQL 数据库表使用什么数据类型。

假设我们有一家图书出版公司，我们需要在 MySQL 数据库中创建一个包含所有图书和作者的数据库。我们有大约 500000 本书。一本书有一个唯一的 ISBN（例如978-3-16-148410-0）。

因此，我们有两种选择来存储我们的书籍：

1. 创建一个id VARCHAR(24) NOT NULL自然主键列并将我们的 ISBN 存储在那里，或者
2. 创建一个代理项id INT NOT NULL AUTO_INCREMENT，然后创建一个isbn UNIQUE VARCHAR(24)列

据我了解，普遍的共识是不要用VARCHAR(n)作主键，因为进行查找和连接需要更多的存储和性能，通常这对我来说是有意义的。

但是，如果我们所有的操作都是针对 ISBN（SELECT * FROM books WHERE isbn = ?、UPDATE、DELETE等） - 为什么不使用 作为VARCHAR(24)主键？

我很难理解，如果你有一个不可变的自然键（比如一本书的 ISBN），并且 95% 的数据库操作都需要使用该字段，那么使用总是VARCHAR(24)优于代理键设计吗？

我觉得AUTO_INCREMENT INT这里有一个代理键完全没有意义。它不会带来任何好处。

或者在确定主键时我是否遗漏了一些基本的东西。

题

主键是否在功能上决定了表中的所有其他属性？

我的想法

当然必须不是吗？这不是主键的重点吗？

如果有两个表：

table1具有属性a1, a2, a3和table2具有属性b1, b2, b3。和a1是b1它们各自的主键。当对两个表应用自然联接时，新的主键是什么。合并 a1, b1形成复合主键，否则它们将成为两个单独的候选键