标签: database-design

我今天才听说罗伯特·马丁，他似乎是软件界的一个显赫人物，所以我的头衔并不是说看起来像是一个点击诱饵或我在他嘴里说的话，但这只是我是如何以我有限的经验和理解来解释我从他那里听到的。

我在看一个视频今天（关于软件架构），Robert C. Martin 的演讲，在视频的后半部分，数据库的主题是主要焦点。

根据我对他所说的话的理解，他似乎是在说 SSD 会降低数据库的实用性（相当大）。

解释我是如何得出这种解释的：

他讨论了如何使用 HDD/旋转磁盘，检索数据很慢。然而，他指出，现在我们使用固态硬盘。他从“RAM 即将到来”开始，然后继续提到 RAM 磁盘，但随后说他不能称之为 RAM 磁盘，因此只说 RAM。所以对于 RAM，我们不需要索引，因为每个字节都需要相同的时间来获取。（这一段是我转述的）

因此，他建议 RAM（如在计算机内存中）作为 DB 的替代品（正如我将他的声明解释为那样）是没有意义的，因为这就像说所有记录在应用程序的生命周期内都在内存中处理（除非您根据需要从磁盘文件中提取）

所以，我用 RAM 来思考，他的意思是 SSD。因此，在这种情况下，他是说 SSD 会降低数据库的实用性。他甚至说：“如果我是甲骨文，我会害怕。我存在的根本原因正在消失。”

根据我对 SSD 的一点了解，与 HDD 不同，HDD 是O(n)寻道时间（我认为），SSD 接近O(1)或几乎是随机的。所以，他的建议对我来说很有趣，因为我从来没有这样想过。几年前我第一次接触数据库时，当一位教授描述与常规文件系统相比的好处时，我得出的结论是数据库的主要作用本质上是一个非常索引的文件系统（以及优化、缓存、并发访问、等），因此，如果 SSD 中不需要索引，这种类型确实会使数据库变得不那么有用。

尽管如此，以我是新手的开头，我发现很难相信它们变得不那么有用了，因为每个人仍然使用 DB 作为其应用程序的主要点，而不是纯粹的文件系统，并且感觉好像他过于简单化了数据库的作用。

注意：我确实一直看到最后，以确保他没有说不同的话。

供参考：42 : 22是整个数据库主题出现的时候， 43:52是他开始说“为什么我们甚至有数据库”的时候

这个答案确实说 SSD 大大加快了数据库的速度。 这个问题询问优化是如何改变的。

对于TL;DR我的问题，SSD 在服务器市场（无论是即将到来还是已经发生）的广泛使用是否会降低数据库的实用性？

似乎演示者试图传达的是，使用 SSD，人们可以将数据存储在磁盘上，而不必担心检索数据会像使用较旧的 HDD 一样慢，与使用 SSD 一样，寻道时间接近O(1)（我认为）。因此，如果这是真的，那么假设它会失去它所拥有的优势之一：索引，因为拥有索引以加快查找时间的优势已经不复存在。

我想知道复合主键是否是不好的做法，如果不是，在哪些情况下使用它们是有益的？

我的问题是基于这篇文章

注意关于复合主键的部分：

不良做法 6：复合主键

这是一个有争议的观点，因为现在许多数据库设计人员都在谈论使用整数 ID 自动生成的字段作为主键，而不是由两个或多个字段的组合定义的复合字段。这目前被定义为“最佳实践”，就我个人而言，我倾向于同意它。

然而，这只是一个约定，当然，DBE 允许定义复合主键，许多设计人员认为这是不可避免的。因此，与冗余一样，复合主键是一种设计决策。

但是请注意，如果您的具有复合主键的表预计有数百万行，则控制复合键的索引可能会增长到 CRUD 操作性能非常下降的程度。在这种情况下，最好使用一个简单的整数 ID 主键，其索引足够紧凑并建立必要的 DBE 约束以保持唯一性。

数据仓库建模的主要拓扑（星形、雪花）在设计时考虑了一对多关系。当面临这些建模方案中的多对多关系时，查询可读性、性能和结构会严重下降。

有哪些方法可以在数据仓库中实现维度之间或事实表与维度之间的多对多关系？它们对必要的粒度和查询性能造成了哪些影响？

在我们当前的项目中，它经常发生，我们需要将列扩展几个字符。从varchar(20)到varchar(30)等等。

在现实中，真正重要的有多少？这优化有多好？只允许 100 或 200 甚至 500 个字符用于正常的“输入”字段有什么影响？一封电子邮件只能有 320 个字符，所以可以 - 有一个很好的限制。但是如果我将它设置为 200，我会得到什么，因为我不希望电子邮件地址比这更长。

通常我们的表不会超过 100.000 行，最多 20 或 30 个这样的列。

我们现在使用 SQL Server 2008，但了解不同的数据库如何处理这个问题会很有趣。

如果影响非常低 - 正如我所期望的那样，这将有助于获得一些好的论据（有链接支持？）来说服我的 DBA，这种长期的偏执并不是真正必要的。

如果是的话，我是来学习的:-)

问这个问题，特别是针对 Postgres，因为它对 R 树/空间索引有很好的支持。

我们有下表，其中包含单词及其频率的树结构（嵌套集模型）：

lexikon
-------
_id   integer  PRIMARY KEY
word  text
frequency integer
lset  integer  UNIQUE KEY
rset  integer  UNIQUE KEY

和查询：

SELECT word
FROM lexikon
WHERE lset BETWEEN @Low AND @High
ORDER BY frequency DESC
LIMIT @N

我认为覆盖索引(lset, frequency, word)会很有用，但我觉得如果范围内的lset值太多，它可能表现不佳(@High, @Low)。

(frequency DESC)有时，当使用该索引的搜索早期产生@N与范围条件匹配的行时，一个简单的索引也可能就足够了。

但似乎性能在很大程度上取决于参数值。

有没有办法让它快速执行，不管范围(@Low, @High)是宽还是窄，也不管高频词是否幸运地在（窄）选择的范围内？

R-tree/空间索引有帮助吗？

添加索引，重写查询，重新设计表，没有限制。

假设我们有用户，每个用户可以有多个电子邮件地址

CREATE TABLE emails (
    user_id integer,
    email_address text,
    is_active boolean
)

一些示例行

user_id | email_address | is_active
1       | foo@bar.com   | t
1       | baz@bar.com   | f
1       | bar@foo.com   | f
2       | ccc@ddd.com   | t

我想强制执行一个约束，即每个用户都只有一个活动地址。我怎样才能在 Postgres 中做到这一点？我可以这样做：

CREATE UNIQUE INDEX "user_email" ON emails(user_id) WHERE is_active=true;

这可以防止用户拥有多个活动地址，但我相信不会防止他们的所有地址都设置为 false。

如果可能的话，我更愿意避免使用触发器或 pl/pgsql 脚本，因为我们目前没有这些脚本，而且设置起来会很困难。但我很感激知道“唯一的方法是使用触发器或 pl/pgsql”，如果是这样的话。

我相信你们中的许多人正在/正在处理一个丑陋的数据库。你知道，那个根本没有规范化的数据库，那个你必须进行大量痛苦的查询才能获得最琐碎的数据的数据库，那个正在生产中的数据库，你不能改变一点......你知道， “那个”。

我的问题是，你是如何处理的？

• 你尝试创建一个新的数据库吗？
• 你放弃并留下它吗？
• 你能给出什么建议？

我必须将所有注册用户的 IP 地址存储在数据库中。我想知道，我应该为这样的列声明多少个字符？

我也应该支持 IPv6 吗？如果是，IP地址的最大长度是多少？

考虑以下：

entity User
{
    autoincrement uid;
    string(20) name;
    int privilegeLevel;
}

entity DirectLoginUser
{
    inherits User;
    string(20) username;
    string(16) passwordHash;
}

entity OpenIdUser
{
    inherits User;
    //Whatever attributes OpenID needs... I don't know; this is hypothetical
}

不同类型的用户（直接登录用户和OpenID用户）表现出IS-A关系；也就是说，这两种类型的用户都是用户。现在，有几种方法可以在 RDBMS 中表示：

方式一

CREATE TABLE Users
(
    uid INTEGER AUTO_INCREMENT NOT NULL,
    name VARCHAR(20) NOT NULL,
    privlegeLevel INTEGER NOT NULL,
    type ENUM("DirectLogin", "OpenID") NOT NULL,
    username VARCHAR(20) NULL,
    passwordHash VARCHAR(20) NULL,
    //OpenID Attributes
    PRIMARY_KEY(uid)
)

方式二

CREATE TABLE Users
(
    uid INTEGER …

在公共服务器中为每个租户的应用程序实例使用单独的数据库处理数量适中的客户（租户）相对简单，并且通常是正确的方法。目前我正在研究一个应用程序的架构，其中每个租户都有自己的数据库实例。

但是，问题是该应用程序将拥有大量租户（5,000-10,000）和大量用户，单个租户可能有 2,000 个用户。我们需要支持每周由几个租户扩展系统。

此外，所有租户及其用户都将看到一个通用的登录过程（即每个租户不能拥有自己的 URL）。为此，我需要一个集中的登录过程和一种将数据库动态添加到系统并注册用户的方法。

• 如何稳健地自动化注册和数据库创建过程？

• 在系统上创建和注册租户数据库的过程是否可能导致性能或锁定问题。如果您认为这可能是一个问题，有人可以建议减轻它的方法吗？

• 如何以用户凭据与特定租户数据库相关联的方式管理中央身份验证，但用户可以通过公共页面登录（即全部通过相同的登录 URL，但他们的主应用程序将位于某些特定租户的数据库上） ）。租户必须能够维护自己的登录名和权限，但中央登录系统必须了解这些。谁能建议一种方法来做到这一点？

• 如果我需要通过添加多个数据库服务器来“向外扩展”，谁能建议我在跨服务器管理用户身份（模拟等）时可能需要处理哪些问题以及缓解这些问题的某种方法？