标签: database-design

我有一个包含五个布尔列的表。在 90% 以上的行中，所有列都为空。（False相当于null我。）

我可以有一个包含枚举自定义数据类型数组的单个数组列，而不是具有布尔列，从而仅存储非空的列。

我觉得使用数组很奇怪，但我的同事向我指出，并没有真正强烈的理由反对使用它们，而且我们实际上可能会看到使用它们的节省，因为我们没有存储一堆空列。

使用数组有什么缺点吗？具体来说：它们会占用更多空间，占用更多时间进行查询，还是阻止使用 Postgres 功能（例如 gin 索引）？

我的数据结构如下：

date: <timestamp>
filter_a: <integer> -> range [0, 1000]
filter_b: <integer> -> range [0, 1000]
filter_c: <integer> -> range [0, 86400]
filter_d: <integer> -> range [0, 6]
group: <string>
second_group: <integer>
variable_a: <float>
variable_b: <float>
variable_c: <float>
a couple more no very important

我需要执行以下查询：

第一的：

• 通过筛选数据date，filter_a，filter_b，filter_c和其他人

其次，使用过滤后的数据：

• 计算所有记录
• 得到平均的variable_a，variable_b并variable_c
• 得到标准差的variable_a，variable_b并variable_c
• 拿到四分位数 的variable_a，variable_b而variable_c …

我有两个表：

1. Employee 表，包含employee_id（主键）和employee_name 列。
2. 包含 company_id（主键）和 company_name 列的公司表。

这些公司允许其员工为其他公司工作。所以一个员工可以在很多公司工作，一个公司可以有很多员工（多对多关系）。

假设我有 3 名员工和他们工作的公司，分别具有一天的开始和结束时间。

employee_name | company_name | hours they work |
Akash            A               09:00 - 11:00                            
                 B               12:00 - 02:00                       
                 C               04:00 - 07:00  

Sunny            D               09:00 - 11:00
                 C               12:00-  04:00
                 D               05:00 - 07:00 

Vishal           B               09:00 - 12:00 
                 A               12:00 - 05:00

• 我应该如何设计数据库？
• 我如何找到给定公司工作时间最长的员工？

晚上的伙计们和女孩们，我希望你们中的一些传奇人物可以在这里帮助我:)

我上次使用 SQL Server 是在黑暗时代的第 7 版（我们将两根棍子摩擦在一起以使其运行）。现在我身处 21 世纪，想再次回到 DBA 工作。

我想设置一个“便宜”的虚拟机和实例来使用，然后努力获得最新的认证（我看到最新的认证将于 2017 年 4 月开始，我认为这对我来说是个好时机）。我对事物的 BI 方面特别感兴趣。

谁能推荐一个好的虚拟机托管服务提供商？我是简单地获得一个 Windows Server 并从那里开始还是我可以在某个地方获得一个包？我假设 Azure 或其他地方？我怀疑有很多选择，希望你能分享一些好的:)

加上任何其他有用的提示是最受欢迎的，干杯！

我正在与一位同事合作，他建议将我们的 1 个实例数据库拆分为大约 7 个数据库（按数据域划分）用于开发和 7 个相同的数据库用于生产。我得到了测试生产二元性逻辑，但是在什么情况下或将我们的 1 个相对简单的数据库拆分为 7 个数据库有什么优势？我们的数据仓库仅由一个商业智能应用程序消耗/使用，期间。

我很关心这个方向，所以希望你能讨论提出这个拆分的一般原因，我可以给你一个数据库当前属性的概要。

1 个数据库数据仓库：总共 352 GB，203 个表，170 个视图

建议拆分：

A: 280 GB
B: 43 GB
C: 28 GB
D: 1 GB
E,F,G: < 1 GB combined

正如您所看到的，就提议的好处而言，这已经是一个令人头疼的问题，因为存储甚至不会远程平均分配，80% 还留在 1 个数据库上。显然，按架构对我们的数据库进行分区是不可能的（从硬件角度来看），因为我们没有企业级 SQL Server。

给出的拆分原因：

1. 当前的数据库优化不佳，文档很少，数据类型次优，索引次优。

我的菜鸟想法：这些问题不是和数据库拆分无关吗？它们只是需要以任何方式自行解决的问题。

2. 当前数据库中有 372 个对象，这使它变慢。

我的想法：在我看来，这似乎并不大。

3. 一个数据库比 7 个数据库更难记录和绘制模式图（我们将拥有跨越多个数据库的视图）。

我的想法： .... 这对我来说似乎完全荒谬，但也许我错了。我们已经按照 13 个“源系统”模式组织了我们的数据仓库。

4. 一个数据库会导致更多的数据库死锁。

-- 这个问题不是也和多数据库完全无关吗？我的理解是死锁发生在表级别（实际上通常甚至只是行级别，但是呃）。即便如此，我们所有的数据插入都发生在午夜，我们所有下游到 BI 的选择发生在凌晨 2 点。让两个进程更新同一个表与多个数据库无关，是不是（死锁会发生）？另外，我个人没有看到在正常操作期间发生表死锁的证据。

5. 数据库技术所有权/所有权。

只有我们两个人在数据库上工作。他有可能真的想隔离我们的“封地”。真的，这不是问题，但无论如何不能在架构级别确定用户权限吗？

将数据仓库拆分为多个数据库的正当理由是什么？

很想在这里进一步了解一般的数据库。是的，我碰巧在我的知识空白处做了很多工作，但这份工作就是它，我一直在努力。到目前为止，东西一直很好用（敲木头）。

“SQL 最终子树成本”和“查询时间性能”之间的一般关系是什么？

示例：当优化查询并且它从子树成本 0.2 到 0.1 时，这是否意味着查询时间将快两倍？我在查询中没有看到这种情况。

我们有一个服务器，即使使用“设置统计时间”和“DBCC DROPCLEANBUFFERS”也无法真正衡量查询性能。服务器、事务、程序、后台项目中有不同的进程在进行。

谢谢，

我们有大量的文本文件，我们想要自由文本/全文搜索，结合有关文本文件的关系结构化元数据。因此，搜索可以是“给我属于 X 组（或 X 的子组）、作者（Ari 和 Bari 和 Mari）、属于组织 Y 并包含文本“合成”的所有文件。后半部分一个是全文搜索，另一个已经作为关系数据存储在我们现有的数据库中。

在我们的数据库（相当复杂）中，存储了一种标识文件的方法，以及大量关于文件的各种元数据，分布在数十个表中，从简单的 1-1 关系到 1-多组 pr文件，甚至树结构关系（比如“这个文件是类型 X，类型 X 是类型 Y 的子组，等等）。而且这个元数据可能会随着时间的推移而改变，在整个应用程序中（这是巨大的）。

现在，我作为数据库管理员，认为这可以通过使用 SQL Server 搜索数据库中已有的结构化元数据来解决，将搜索限制为候选文件，然后将候选文件 id 传递给弹性搜索以获取完整-文本搜索。（在我们的代码中添加或提交文件时在弹性上重新索引文件是微不足道的）

然而，我们项目中的elastic-guys自然有不同的想法：从文件中提取所有元数据以及全文内容，进行elastic-search，并在elastic中专门运行搜索。

这使他们可以轻松地运行完整的 lucene 查询，并且从数据库中删除了负载，这很好。然而，这对我来说也带来了一个噩梦，以保持结构化元数据同步，并且由于数据的规模，不可能定期盲目地重新索引/同步所有内容。

我可以看到这两种选择的优点/顾虑。这种事情有最佳实践吗？

在 jsonb 列和相同结构的复合类型列之间进行选择需要考虑哪些因素？

例如，考虑 Postgres 文档中使用的类似列：

CREATE TYPE inventory_item AS (
name            text,
supplier_id     integer,
price           numeric
);

这种方法与镜像这种结构的 jsonb 列之间的权衡是什么？

例如，我怀疑复合类型不需要存储每条记录的键名，而 jsonb 类型需要这样做。

在一次讲座中，我的讲师向我们展示了一张没有主键的表格。经询问，他说在 3NF 中，当您删除传递依赖项时，可以使用没有主键的表。

然而，没有主键意味着没有函数依赖——但是 3NF 是去除传递依赖，我被教导每个表都需要有一个主键来规范化，因为它完全是关于函数依赖的。

我知道完全有可能创建一个没有主键的表，但是如果该表存在，该数据库是否被认为是规范化的？

我应该补充一点，该表没有任何“唯一键”，没有主键，没有复合键，没有外键。

显示的表具有三个属性，其中没有一个被标记为主要或唯一的。我问是不是搞错了，他说没有也没关系。我对这句话提出了质疑，因为表格中的所有信息都无法唯一标识，他声称可以这样。这与我学到的关于规范化的内容背道而驰。

描述：

RocksDB 是一个键值存储，因此我们可以简单地序列化对象列表并存储与键对应的值。如果列表中的数据足够小，这将是可以的。

但是如果列表很大并且大小不断增加，那么我们需要对数据进行分页。因此，在这种情况下，存储与单个键对应的整个序列化列表数据不是一个好主意；因为会存在性能问题，因为每次将新数据插入列表时，这个非常大的值也需要在读取期间读取和更新，当向用户显示列表时，将检索整个值，而只有一部分是用户需要。

例如：假设我们想将用户下的订单存储在 RocksDB 中。然后我们可以在 RockDB “u:1:li:o” 中以下列方式存储这个订单数据：Serialised([O1{}, O2{},....On{}])。但是如果用户下的订单数以千计，我们想以页面的形式检索订单（一次 10 或 20 条记录）。因此，在同一个键中存储数千个订单并从该键中检索整个数据然后提供所需的 10-20 条记录并不是一个好主意。此外，用户向同一键添加新订单将影响上述性能。

所以我正在努力设计模式以在 RocksDB 中有效地存储和检索如此大的列表。

如果您能就架构设计提出您的建议，那将会很棒且非常有帮助。