标签: database-design

我有 4 个这样相关的表（这是一个例子）：

Company:
ID
Name
CNPJ

Department:
ID
Name
Code
ID_Company 

Classification:
ID
Name
Code
ID_Company

Workers:
Id 
Name
Code
ID_Classification
ID_Department

假设我有一个classificationwith id = 20, id_company = 1。并且department有id_company = 2（代表另一家公司）。

这将允许创建来自两个公司的工人，因为分类和部门分别链接到公司。我不希望这种情况发生，所以我认为我的人际关系有问题，我不知道如何解决。

我正在使用 MySQL。这个想法类似于 shopify 具有不同的概念，因此用户将添加具有多种类型的变体和属性的产品。

从我所做的所有研究来看，这对我来说似乎是最有可能的解决方案，我只是想知道以下模式是否有任何问题以及有哪些优点/缺点？

谢谢

Table: products
------------------------------
| ID | ProductName           |
|----------------------------| 
| 1  | Leather Wallet Case   |
| 2  | Jeans                 |
| 3  | Power Bank            |



Table: products_variants
-------------------------------
| ID | ProductId | ParentId | Variant  | VariantName | SKU  | StockTotal | WholeSalePrice | BuyPrice | OnSale | OnSalePrice |
|---------------------------------------------------------------------------------------------------------------------------|
| 1  | 1         | null     | model    | iPhone5     | SKU  | 10         | 3              | 10       | null …

语境

我正在设计一个数据库（在 PostgreSQL 9.6 上），它将存储来自分布式应用程序的数据。由于应用程序的分布式特性，SERIAL由于潜在的竞争条件，我不能使用自动递增整数 ( ) 作为我的主键。

自然的解决方案是使用 UUID，或全局唯一标识符。Postgres 带有一个内置的UUIDtype，非常适合。

我对 UUID 的问题与调试有关：它是一个非人类友好的字符串。标识符ff53e96d-5fd7-4450-bc99-111b91875ec5什么也没告诉我，而ACC-f8kJd9xKCd，虽然不能保证是唯一的，但告诉我我正在处理一个ACC对象。

从编程的角度来看，调试与几个不同对象相关的应用程序查询是很常见的。假设程序员错误地ACC在ORD（订单）表中搜索（帐户）对象。使用人类可读的标识符，程序员可以立即识别问题，而在使用 UUID 时，他会花一些时间找出问题所在。

我不需要 UUID 的“保证”唯一性；我确实需要一些空间来生成没有冲突的密钥，但 UUID 有点矫枉过正。此外，最坏的情况是，如果发生冲突（数据库拒绝它并且应用程序可以恢复），也不会是世界末日。因此，权衡考虑，一个更小但对人友好的标识符将是我的用例的理想解决方案。

识别应用对象

我想出的标识符具有以下格式：{domain}-{string}，其中{domain}替换为对象域（帐户，订单，产品）并且{string}是随机生成的字符串。在某些情况下，{sub-domain}在随机字符串之前插入一个甚至可能是有意义的。让我们忽略的长度{domain}，并{string}为保证唯一性的目的。

如果有助于索引/查询性能，格式可以具有固定大小。

问题

知道：

• 我想要具有类似ACC-f8kJd9xKCd.
• 这些主键将是几个表的一部分。
• 所有这些键都将用于 6NF 数据库上的多个连接/关系。
• 大多数表将具有中到大的大小（平均约 1M 行；最大的表具有约 100M 行）。

关于性能，存储此密钥的最佳方法是什么？

以下是四种可能的解决方案，但由于我对数据库的经验很少，我不确定哪个（如果有）是最好的。

考虑的解决方案

1. 存储为字符串 ( VARCHAR)

（Postgres 在CHAR(n) …

在我正在处理的一个 Web 应用程序中，所有数据库操作都是使用一些在实体框架 ORM 上定义的通用存储库进行抽象的。

但是，为了通用存储库的简单设计，所有涉及的表都必须定义一个唯一的整数（Int32在 C# 中，int在 SQL 中）。直到现在，这一直是桌上的PK，也是IDENTITY.

外键被大量使用，它们引用这些整数列。它们对于一致性和 ORM 生成导航属性都是必需的。

应用层通常会做以下操作：

• 从表(*)加载初始数据-SELECT * FROM table
• 更新-UPDATE table SET Col1 = Val1 WHERE Id = IdVal
• 删除-DELETE FROM table WHERE Id = IdVal
• 插入-INSERT INTO table (cols) VALUES (...)

不太频繁的操作：

• 批量插入-BULK INSERT ... into table后跟 (*) 所有数据加载（以检索生成的标识符）
• 批量删除- 这是一个正常的删除操作，但从 ORM 的角度来看是“庞大的”：DELETE FROM table where OtherThanIdCol = SomeValue …

我正在寻找在 JSON 或 JSONB 数组与常规 SQL postgres 数组之间进行选择时要考虑的要点。如果您知道只会将一种数据类型插入数组中，为什么要使用 SQL 数组而不是 JSON 数组？谢谢

有哪些有效的方法可以对数据库操作执行编程性能测试，尤其是在数据库本身不提供专用工具的环境中？

例如，在 Google App Engine 中，整个页面加载被评估为一项操作，其中可能包括特定的数据库操作。SQLite 和其他集成数据库中也可能存在此问题。由于很难完全抽象需要测试的（等价的）选择和插入，是否有任何推荐的数据库工具来对这些类型的查询执行更彻底的诊断？

应用程序需要尽可能更新数据库中的数据。在这种情况下，除了基于计时器的请求（轮询）数据库之外，还有其他获取数据的方法吗？

我使用 MS SQL Server 2008（和 .NET 应用程序 + 实体框架），但我也想了解其他类型的数据库。

我已经多次浏览了http://en.wikipedia.org/wiki/Database_engine上的定义：

数据库引擎（或“存储引擎”）是数据库管理系统 (DBMS) 用来从数据库创建、读取、更新和删除(CRUD) 数据的底层软件组件。

我不明白的是剩下要做的事情，不是数据库所做的全部 CRUD 吗？

如果数据库引擎执行这些功能，那么数据库的其余部分会做什么？

我有一个关于 SQL Server 2008 表设计的一般问题。我们目前有一个超过 600GB 的表，并且每天增长大约 3GB。此表具有适当的 indecies，但在运行查询时正成为主要问题，并且仅因为它的大小。问题是我应该按年和月将表拆分为多个表（这将适合其他部门拆分其大数据集的方式）还是我们应该利用 SQL Server 中内置的分区。使用分区似乎需要较少的代码更改。根据我在分区时阅读的内容，您仍然只查询一张表，服务器处理如何获取数据。如果我们走多表路线，我们将不得不处理从多个表中提取数据。

我在做一个需要使用 7 个数据库的新项目，认为性能、稳定性、优化更容易实现。

虽然我不同意，但我在收集使用单个数据库（将表拆分为逻辑域）的好参数时遇到了麻烦。

到目前为止，我的一个论点是数据完整性（我不能在数据库之间使用外键）。

使用单个或多个数据库的优点/缺点是什么？

[到目前为止的总结]

针对多个数据库的参数：

• 丢失数据完整性（不能在数据库上使用外键）

• 丢失恢复完整性

• 获得复杂性（数据库用户/角色）

• 小概率服务器/数据库将关闭

解决方案：

• 使用模式来分隔域。

• POC：使用虚拟数据来证明 7/1 db 的执行计划中的要点