标签: database-design

每两周，系统将为公司生成发票。

公司将在每月 1 日和 16 日收到发票。（它将每 2 周通过 Cron Job 运行一次。它会扫描订单表，然后添加到“发票”表中。还有其他选择吗？）

表中有客户订单列表，orders还标明了它属于哪个公司（orders.company_id）

该invoice表计算orders表中订单的总成本。

我想弄清楚如何设计合理的发票跟踪。有时公司将不得不向我发送费用或有时我向他们发送费用 ( invoice.amount)

我需要使用以下内容跟踪发票：

• 当公司向我发送金额时
• 我什么时候把钱寄给公司的
• 从公司收到了多少金额
• 我给公司寄了多少钱
• 我是否收到了全额（如果没有，我需要在 Db 上更新什么？）
• 发票状态（发票已发送、已取消、已收到金额、已发送金额）

这是我提出的数据库设计：

公司表

mysql> select * from company;
+----+-----------+
| id | name      |
+----+-----------+
|  1 | Company A |
|  2 | Company B |
+----+-----------+

Customers can select a company from my website.

orders table

mysql> select * from orders;
+----+---------+------------+------------+---------------------+-----------+
| id | …

考虑我们有大量的统计数据作为记录；例如 20-30INT列。将整个集合保存在一个表中是否更好，因为它们都属于一个记录或创建另一个以一对一关系连接的表。

前者的优点是避免JOIN并快速访问相应记录的所有统计数据。

后者的优点是保持柱子整洁。第一列是读密集型，第二列是写密集型。当然，我认为它对性能没有显着影响，因为我使用的是行级阻塞的 InnoDB。

一般来说，我想知道为单个记录分离不同的数据集是否实用？

我有一个带有复合主键（由 4 列组成）的表，用于确保没有重复项输入到表中。我现在需要一个新表，它需要将此表中的键作为外键引用。

我的问题是哪种方法对查找速度更有效：

1）我是否创建包含所有 4 列的新表并在外键中引用它们。

或者

2）我是否在主键表中创建一个新的标识列并将其用作新表中的外键。

预计该数据库将保存大量数据，因此我一直构建它，以期最大限度地减少每个表中保存的数据量。考虑到这一点，选项 2 将是最好的方法，因为我将为每一行保存 2 个 int 列和一个 datetime 列，但我想避免在不必要的情况下增加查找时间。

我有大量的天气模型数据被放入 PostgreSQL 数据库。该机器具有 8 个内核和 16 GB 的 RAM。我正在使用 PostGIS 2.1 运行 PostgreSQL 9.3。每个表都有不同种类的天气数据（温度、露点、风等）。每个表将有 6-7 列：纬度、经度、点几何、高程、模型相关的日期时间以及 1-2 个感兴趣的数据值。数据将主要按时间和高程查询边界框。每个表将有大约 145,757,360 行（早于现在不再相关的数据将被删除）。我粗略估计每个表的大小约为 10 GB，没有索引。（这是 52 字节的数据加上每行 23 字节的开销）。随着新模型数据可用，数据将定期更新/插入。笔记：

所以我正在研究这两个计划：

1. 简单地按（日期时间，高程）索引和聚类，并为点几何添加一个额外的索引。运行一个常规的 cron 作业来删除旧行、运行vacuum/analyze 和重新集群。
2. 按日期时间分区，然后按每个表的高程进行聚类和索引，并在几何上有索引。运行常规的 cron 作业以添加新表并删除旧表。

更远，

• 所以，我知道删除表和删除和清空表的效率要高得多。但是，否则我会看到性能提升吗？
• 当所有表将被均匀更新和选择直到删除不相关时，分区是否合适（文档表明分区在只选择其中几个时效果最佳）？

传递数据时，选择会比聚集索引更快吗？如果同时发出多个请求，答案是否会改变？

谢谢你。我希望我提供了所有需要的数据。如果没有让我知道，我会添加它。

我目前正在使用 CouchDB 开发一个 wiki-esque 应用程序，并试图实现一个文档版本控制方案。在我看来，有两种方法可以做到这一点：

1. 将每个版本存储为单独的文档
2. 将旧版本存储为单个文档的附件。

现在，我有一种#1 的工作形式。当用户编辑文档并保存时，后端首先将之前的修订复制到新文档中，然后保存新版本。每个文档都有一个 'history' 数组，其中包含每个版本的数据（旧版本的文档 _id、时间戳、编辑器等）。

由于这个历史数组对于经常更新的文档来说可能会变得很长，我有一个视图可以在正常读取期间获取一个没有历史记录的文档（以及另一个用于获取历史记录的视图）。

我的问题是：我对我目前的方法感到不安，并一直在考虑改用“依恋”方法。但我不确定。我希望有人比我更了解 CouchDB（我只在这工作了几个星期——这是我第一个使用 CouchDB 和 NoSQL 的项目）可以告诉我每个项目的优缺点方法。或者是否还有其他一些我忽略的版本控制方案？

我正在阅读一些现实生活中的数据库问题，一个项目有一个 1 亿行多的表，其中有 5 列作为其主要内容。我认为这很糟糕，但谁能告诉我究竟是为什么？

该表是一种微型汇总/聚合表，因此 5 列类似于（day、market_id、product_id...）。起初我认为一个 5 列的主键并不理想，但我越想，我真的想不出一个很好的理由为什么它很糟糕。

这是与一半的公司工程师进行的深夜讨论。刚刚有人提到这是一个糟糕的设计，一位高级工程师表示同意，但没有人真正了解原因。因此试图为自己研究这件事！

我将创建一个包含两个字段的表 - IDasBIGINT和IPAddressasvarchar(45)或者varbinary(16)。这个想法是存储所有唯一的 IP 地址并使用引用ID而不是IP address其他表中的实际地址。

通常，我将创建一个存储过程，该过程返回ID给定的IP address或（如果未找到地址）插入地址并返回生成的ID.

我期望有很多记录（我无法确切说出有多少），但我需要尽快执行上面的存储过程。所以，我想知道如何以文本或字节格式存储实际的 IP 地址。哪个会更好？

我已经编写了SQL CLR用于将 IP 地址字节转换为字符串和反向转换的函数，因此转换不是问题（同时使用IPv4和IPv6）。

我想我需要创建一个索引来优化搜索，但我不确定我应该将该IP address字段包含在聚集索引中，还是创建一个单独的索引以及使用哪种类型的搜索会更快？

是否有任何时候您对您的语言/数据库/系统变得如此熟悉，以至于无需测试新功能/配置/查询/等。在您的系统中实施之前通过包含/模拟测试（特别是关于修改数据的功能）？还是在测试环境中通过模拟来测试新查询总是必不可少的？