有两个表：Deal和DealCategories。一笔交易可以有多个交易类别。

所以正确的方法应该是制作一个DealCategories具有以下结构的表：

DealCategoryId (PK)
DealId (FK)
DealCategoryId (FK)

但是，我们的外包团队以Deal这种方式将多个类别存储在表中：

DealId (PK)
DealCategory -- In here they store multiple deal ids separated by commas like this: 18,25,32.

我觉得他们这样做是错误的，但我不知道如何清楚地解释为什么这是不对的。

我该如何向他们解释这是错误的？或者也许是我错了，这是可以接受的？

有谁知道谷歌或雅虎如何针对非常非常大量的数据执行关键字搜索？他们为此使用了什么样的数据库或技术？

这需要几毫秒的时间，但它们有超过 10 亿页被索引。

使用数据库时的一个常见需求是按顺序访问记录。例如，如果我有一个博客，我希望能够以任意顺序重新排列我的博客文章。这些条目通常有很多关系，因此关系数据库似乎很有意义。

我见过的常见解决方案是添加一个整数列order：

CREATE TABLE AS your_table (id, title, sort_order)
AS VALUES
  (0, 'Lorem ipsum',   3),
  (1, 'Dolor sit',     2),
  (2, 'Amet, consect', 0),
  (3, 'Elit fusce',    1);

然后，我们可以对行进行排序order以使它们按正确的顺序排列。

然而，这似乎很笨拙：

• 如果我想将记录 0 移到开头，我必须对每条记录重新排序
• 如果我想在中间插入一条新记录，我必须在它之后重新排列每条记录
• 如果我想删除一条记录，我必须在它之后对每条记录重新排序

很容易想象这样的情况：

• 两条记录相同 order
• order记录之间有间隙

由于多种原因，这些可能很容易发生。

这是 Joomla 等应用程序采用的方法：

你可能会争辩说这里的界面很糟糕，他们应该使用箭头或拖放而不是人类直接编辑数字——你可能是对的。但在幕后，同样的事情正在发生。

有些人建议使用小数来存储订单，这样你就可以使用“2.5”在订单 2 和 3 的记录之间插入一条记录。虽然这有点帮助，但可以说它更混乱，因为你最终可能会得到奇怪的小数（你在哪里停？2.75？2.875？2.8125？）

有没有更好的方法将订单存储在表中？

我试图决定数据库设计，在这个阶段尽可能少的假设（关于 web 应用程序的实际发展）。

作为第一步，了解 JOINS 是昂贵的，我正在考虑少量的整体表，而不是大量的规范化较小的表。第二点，我在使用 hstore 与常规表与 JSONB（使用 GiST 索引）之间感到困惑。

AFAIK（请随时纠正）：

1. 通常，在 Postgres 中，已知 hstore 的性能优于其他数据类型。来自 FOSDEM PGDAY 的这个演讲有一些有趣的统计数据（在幻灯片的后半部分）。 https://wiki.postgresql.org/images/b/b4/Pg-as-nosql-pgday-fosdem-2013.pdf

2. hstore 的一个优势是快速索引（GiN 或 GiST）。但是，使用 JSONB，GiN 和 GiST 索引也可以应用于 JSON 数据。

3. 来自第二象限的专业人士的这篇博客说“此时可能值得在所有新应用程序中用 jsonb 替换 hstore 使用”（滚动到最后）：http ://blog.2ndquadrant.com/postgresql-anti-patterns-unnecessary -jsonhstore-dynamic-columns/

所以我想决定以下几点：

1. 对于数据的主要（结构化）部分：它应该放在几个关系表中（相对较大，有很多列），还是应该是使用 hstore 的多个键值存储？
2. 对于临时（用户贡献/非结构化）数据，它应该是 JSON 还是 hstore 中的临时键值存储（键存储在主要关系表之一中）？

我们正在构建一个包含多种服务的网络平台，每个服务都有自己的底层数据。这些服务是按照面向服务的架构原则独立构建的，但它们针对潜在的相关数据进行交易。我们正在考虑这些服务是否应该共享一个大数据库或每个都有自己的数据库。（我们计划在 Windows 2008 群集上使用 SQL Server 2008 Enterprise。）

我们已经考虑过的每种方法的一些优点包括：

单一数据库

• 来自不同服务的相关数据可以通过外键约束绑定在一起
• 分析提取更易于编写且执行速度更快
• 发生灾难时，更容易将平台恢复到一致状态
• 对于被多个服务引用的数据，一个服务缓存的数据很可能很快就会被另一个服务使用
• 预先管理和监控更简单、更便宜

多个数据库

• 维护工作、硬件问题、安全漏洞等不一定会影响整个平台
• 假设每个数据库都在不同的硬件上，扩展多台机器比扩展一台大机器会产生更多的性能优势

从操作的角度来看，这个平台中的每个服务都有自己的数据库，还是都放在同一个数据库中更有利？哪些关键因素决定了这个问题的答案？

我们正在开发一个预付卡平台，该平台主要保存有关卡及其余额、付款等的数据。

到目前为止，我们有一个 Card 实体，它有一个 Account 实体的集合，每个 Account 都有一个 Amount，它在每次存款/取款时更新。

现在团队中有一场辩论；有人告诉我们，这违反了Codd 的 12 条规则，并且在每次付款时更新其价值很麻烦。

这真的有问题吗？

如果是，我们如何解决这个问题？

声明VARCHAR大小对性能有意义吗？是否有任何区别（速度）VARCHAR(50)和VARCHAR(255)？或者定义长度是逻辑/设计约束？

我正在创建会计软件。我需要强制执行复式簿记。我有一个经典的问题，每笔交易一行而不是两行。

让我们举一个例子，看看它是如何在这两种情况下实现的。

考虑 accountCash和 account Rent。当我支付每月租金时，我会从我的Cash帐户中将 100 美元转入我的Rent帐户。

每笔交易一行

在一行系统中，此类事务将存储为：

交易

 tx_id | posting_date
 1     | 23/05/2015

交易记录

 id | tx_id | credit_account | debit_account | amount
 1  | 1     | Cash           | Rent          | 100.00

每个事务两行

在两行系统中，我必须镜像相同的交易记录以创建相反的记录，一旦我将两者相加，我就会得到零余额。

交易

 tx_id | posting_date
 1     | 23/05/2015

交易记录

id  | tx_id | type   | account | amount
1   | 1     | credit | Cash    | 100.00
2   | 1     | debit  | Rent    | 100.00 …

我曾经像这样标记数据库中的列：

user_id
user_name
user_password_hash

为了避免在连接两个表时发生冲突，但后来我学到了更多关于如何为表设置别名的知识，我不再这样做了。

在数据库中标记列的有效方法是什么？为什么？

我很难理解表分区的优缺点。我即将开始一个项目，该项目将有 8 个表，其中一个将是主数据表，将包含 180-260 百万条记录。因为它将是正确索引的表，所以我正在考虑将表记录限制为 2000 万，这样我将不得不创建 9-13 个表。

但我不太确定它将如何提高性能，因为它们将位于同一台机器上（32GB RAM）？

我正在使用 MySQL 并且表将是 MyISAM 并且大表将在 id 字段上有索引，并且没有进一步的复杂性，例如全文搜索等。

还请阐明表分区与数据库分区。