标签: database-design

定义表时，按目的对逻辑组中的列和组本身进行排序会很有帮助。表中列的逻辑顺序向开发人员传达了意义，是良好风格的元素。

这是清楚的。

然而，不清楚的是，表中列的逻辑顺序是否对其在存储层的物理顺序有任何影响，或者是否有任何其他人可能关心的影响。

除了对样式的影响之外，列顺序是否重要？

Stack Overflow 上有一个关于这个的问题，但它缺乏权威的答案。

在外键字段上的两个表之间进行循环引用是否可以接受？

如果没有，如何避免这些情况？

如果是这样，如何插入数据？

以下是（在我看来）可以接受循环引用的示例：

CREATE TABLE Account
(
    ID INT PRIMARY KEY IDENTITY,
    Name VARCHAR(50)
)

CREATE TABLE Contact
(
    ID INT PRIMARY KEY IDENTITY,
    Name VARCHAR(50),
    AccountID INT FOREIGN KEY REFERENCES Account(ID)
)

ALTER TABLE Account ADD PrimaryContactID INT FOREIGN KEY REFERENCES Contact(ID)

我正在为索引、主键和外键苦苦挣扎……并且需要拥有所有这些。

如果我有两个表，它们都有一个整数作为主键。
第一个表通过 FK 引用第二个表的主键。

• 在两个表上，我在 ID 列上都有一个主键索引
• 我在table1.ref_field引用第二个表 ( table2.id)的 PK上创建了 FK 约束
• 我在上面添加了一个索引 table1.ref_field

这是组织这些索引、主键和外键的最佳方式吗？

从技术上讲，NULL = NULL 是 False，根据该逻辑，没有 NULL 等于任何 NULL，并且所有 NULL 都是不同的。这不应该意味着所有 NULL 都是唯一的并且唯一索引应该允许任意数量的 NULL 吗？

我的许多数据库都有定义为 varchars 的字段。自从我在美国生活和工作以来，这并不是什么大问题（那里唯一存在的语言是“美国”。咳咳）

在使用数据库大约 5 年后，我发现我最终遇到了 varchar 字段的有限性质的问题，我必须修改我的字段以将数据存储为 nvarchars。在不得不对表进行另一次更新，将 varchar 字段转换为 nvarchar 之后，我有了一个想法——为什么我们仍然这样做？我早就决定将所有新的文本字段定义为 nvarchar，而不是 varchar，这是我 10 年前在学校时从教科书中学到的。

现在是 2011 年，去年发布了新版本的 SQL Server。当我们可以/应该使用 nvarchar 时，为什么我们继续支持 varchar 数据类型？

我知道经常有人争论 nvarchars 是 varchars 的“两倍大”，因此存储空间的使用可能是维护 varcars 的一个争论点。

但是，今天的用户如果想节省存储空间，可以定义他们的 nvarchars 以将数据存储为 UTF-8 而不是默认的 UTF-16。如果主要需要，这将允许 8 位编码，同时保证插入到他们的数据库中的稀有 2-8 字节字符不会破坏任何东西。

我错过了什么吗？在过去的 15 到 20 年里，这是否有充分的理由没有改变？

我了解代理/人工密钥的一个好处 - 它们不会改变，而且非常方便。无论它们是单场还是多场，都是如此——只要它们是“人造的”。

但是，有时将自动递增的整数字段作为每个表的主键似乎是一个策略问题。拥有这样一个单字段键是否总是最好的主意，为什么（或为什么不）？

需要明确的是，这个问题不是关于人工 vs 自然的——而是关于是否所有人工键都应该是单字段的

关于 SQL（计算/数据库）：

当我们在一个表中有两个或多个字段共同唯一地标识其记录时，调用它们的正确方法是什么？复合键还是复合键？

我在网上看到两种用法，所以我不太确定。

标题没有太大意义，但我想不出更好的标题来解决这个问题。

我有以下表格

项目

• ID
• 姓名

顾客

• ID
• id_project
• 姓名

付款

• ID
• id_customer
• 日期
• 和

当用户进入系统时，他将有权访问某个项目。现在，我想列出该项目的所有付款，这应该很容易：

SELECT FROM payments where id_customer in (SELECT id from customers where id_project = 5)

我的问题是：如果以这种方式向支付表添加一列 id_project 不是更好，那么查询会更容易和更快。

根据我对 PostgreSQL 9.2 中的空闲连接问题的评论，一些未提交的事务（可能与其中一些空闲连接有关）可能会导致一些性能问题。

确定是否存在未提交的事务的好方法是什么（如果有办法知道它们所在的连接是否空闲，则加分）？

非常感谢！

对于我们的一个系统，我们拥有敏感的客户数据并将每个客户的数据存储在单独的数据库中。我们有大约 10-15 个客户用于该系统。

但是，我们正在开发一个新系统，该系统将拥有 50-100 个客户，也许更多。我认为在这种情况下每个客户端拥有一个数据库可能是不可行的（用于存储敏感记录和审计历史）。但是我不知道这是否完全正常，或者是否有另一种维护安全的方法。

对此有何想法？