Question

我有一个数据库，它将成为高流量网络应用程序的一部分。

我想知道我是否应该对表进行规范化，以便（例如）'question_type'之类的内容也应该在一个单独的表中，所有关于问题的基本信息，例如'title'和'question_body'？

我只是问，因为我需要这个数据库尽可能地扩展，并且我被告知当你需要可扩展性时，规范化并不总是那样。

由于

Answer 1

使规范化成为缩放问题的一点是，它往往需要将多个表连接在一起。连接在小型表上很棒，但表越大，服务器需要工作的越多。

要注意的主要是避免加入。如果您可以通过向其中一个表添加字段来进行没有连接的查询，则只需加快该查询的性能。

Answer 2

如果您的表格有question_body和question_type，那么我不会看到如何将其移动到另一个表格来实现规范化。 e.g：

table question (
    question_body      text,
    question_user      text,
    question_user_rank integer,
    question_type      text
);

将单个值拆分为单个列表将无法实现除无用连接之外的任何其他操作。那就是：

select * from question q join question_type qt on (q.qt_id = qt.id)
  where qt.name = 'sql questions';

是一种等效但浪费的

形式

select * from question
  where question_type = 'sql questions';

另一方面，（使用上面的例子），将问题用户信息拆分到自己的表中是很有意义的：

table question (
   question_body     text,
   question_type     text,
   question_user_id  integer references question_user(id) on delete cascade
);
table question_user (
   id                integer,
   name              text,
   rank              integer
);

因此，如果用户的排名发生了变化（ala SO），您只需要在一个地方而不是在他被问到问题的每一行中进行更改。您已经提高处理扩展的能力，因为您已将数百个更新更改为单个更新。

Answer 3

现在这是一个加载的问题。规范化并不像指导原则那么严格。设计数据库由一系列关于规范化水平的决策组成，这些决策在您需要代码效率，性能和完整性等方面是有意义的。这大大超出了它的范围，但设计决策的范围涵盖了大量精心编写的书籍。

您能告诉我一些关于您的应用程序和预期平台的信息吗？如果我能更好地了解你的情况，我或许可以引导你走向一些非常有用的参考资料。

Answer 4

添加盐会使我的食物味道更好吗？

同样的问题。没人能回答。

主要的问题是它取决于你的USAGE模式，并且能够证明你作为程序员的能力，在应用程序中使用查找缓存而不是数据库连接。相当多的程序员从来都没有超过炒鸡蛋，烧掉了＃34; SQL的级别，以保持烹饪类比。

对于可扩展性应用程序设计和数据库技术还有很多话要说。难以击败Oracle RAC安装。取决于您在Exadata平台上的需求。对于最小的单位，我认为成本约为50万美元。仍然确定你需要尽可能扩展＆＃34;？这里不是开玩笑 - 我现在在一个6000 GB的数据仓库上工作，我们只是订购了3个怪物，而不是最小的怪物。

那么，你的意思是什么＆＃34;尽可能地扩展＆＃34;？这就像＆＃34;我的汽车需要像汽车一样快速行驶，而且更多＆＃34;然后你最终得到一辆装有喷气发动机的特制汽车;）

一般规则： *将交易分开并报告到两个数据库中。第二个是数据仓库。 *规范化事务数据库 *在数据仓库中使用星型模式。

大概率的机会是：你不知道你说的是什么，从来没有可扩展性，所以有80％的机会你的＆＃34;高可扩展性＆＃34;要求是一个体面的数据库服务器的笑话。现在，这并不意味着侮辱，但我已经看到很多人说'＃34;我在桌子上有大量的数据＆＃34;这使你最多变成10.000行。这不是一个吨 - 这是一个笑话。我们每天在我们的数据仓库主表中加载1亿（并且必须保留它们多年）。大多数人都没有真正获得一个像样的数据库服务器所能提供的速度。这意味着很多光盘。

规范化我的数据库是否会破坏可伸缩性？

4 个答案: