MySQL设计问题 - 更好，长表还是多个数据库？

Question

所以我有一个有趣的问题，这是我小组在工作中进行了很多讨论的成果。

我们有一些生成SQLlite文件的科学软件，这个软件基本上是一个黑盒子。我们不控制它的表格设计，格式等。完全可以想象这个黑盒子的输出可能会改变，我们的设计需要能够处理它。

SQLlite文件是我们的用户希望通过查询的整个数据库。有两种方法（我们看到）实现这一点，一种是在Python中创建单个数据库和后端，将每个数据库中的表附加到主数据库，另外两种，查询不同数据库的表并在Python中统一结果

当黑盒子产生改变其表结构时，两种方法都会遇到麻烦，例如重命名一个列，拆分一个表等等。我们必须考虑到这一点，我们已经讨论了转换查询的转换表列表从一种表格格式到另一种格式。

我们对易于实现，设计如何处理数据库/表格布局的变化以及速度感兴趣。此外，最后一个维度是它与现有Python Web框架的兼容性（Django不支持跨数据库查询，SQLAlchemy也不支持，因此我们知道我们正在进行大量编程。）

Answer 1

如果您发现自己在跨数据库查询，则应该考虑整合。跨数据库查询是邪恶的。

如果您的查询基本上被降级为单个数据库，那么您可能希望坚持使用多个数据库，因为显然它们的分离是必要的。

Answer 2

如果没有以某种方式分类和预测更改，则无法容纳数据库架构中的任意更改。在非常好的情况下进行非平凡的更改，您有时可以简单地忽略新数据或表格，在最坏的情况下，您对数据的解释将完全失效。

我遇到过类似的问题，用户需要从规范化架构中转出数据。架构不会改变。但是，它们所需的输出格式需要固定数量的层级。因此，尽管数据库设计适应了他们想要进行的所有更改，但是他们所选择的数据视图无法在其更改时保持。因此，面对数据更改（甚至模式更改），无法维护输出模式。这并不是说它不是有效的输出或输入模式，而是存在无法使用其所选模式的限制。此时，他们必须修改输出合同，转动程序（可以预期并生成新列）可以将数据放在输出模式中。

我的观点是：新列和新表的语义和解释（或删除现有逻辑可能依赖的列和表）是非常重要的，除非可以某种方式预期新的列或表。但是，在这些情况下，通常有良好的数据库设计，首先消除这些策略：

例如，特定的数据库模式可以包含任意数量的表，所有表都具有相同的结构（尽管没有理论上的原因它们无法合并到单个表中）。一种特殊类型的表可以有一组所有类似命名的列（尽管这个“数组”违反了规范化原则，可以归一化为commonkey / code / value模式）。

即使在数据仓库ETL情况下，也必须确定新列是事实还是维度属性，然后如果它是维度属性，则最好将其分配给哪个维度表。通过检查未映射列的元数据，更改DW表（yikes）然后适当加载，这可以在某种程度上自动化事实（显而易见的候选者将是十进制/数字等标量）。但对于维度，我会非常谨慎地自动化这样的事情。

因此，总而言之，我会说良好的规范化数据库设计中的模式更改最不可能被容纳，因为：1）数据库设计已经预期并适应大量的变化和灵活性2 ）这种数据库设计的模式更改不太可能很容易被预料到。相反，标准化程度较差的数据库设计中的模式更改实际上更容易预测，因为数据库设计中的缺点更加明显。

所以，我的问题是：你工作的数据库设计得有多好？

Answer 3

你说你知道你参加了很多节目......

我不确定。我会寻求快速而肮脏的解决方案，而不是“通用”解决方案，因为像实体属性值模型这样的通用解决方案通常会有糟糕的性能。不要在Python代码中进行客户端连接（统一结果），因为这非常慢。使用SQL进行加入，它是为此目的而设计的。用户还可以使用生成sql语句的各种报告工具制作自己的报告。您不必在应用程序中执行所有操作，只需从解决80％的问题开始，而不是100％。

如果由于黑盒内的某些内容发生变化而导致某些内容发生故障，您可以定义视图以实现向后兼

也许科学软件会添加许多新功能，也许它会因为这些新功能而改变其数据模型。这是可能的，但随后你将不得不改变你的应用程序以从这些新功能中获利。

Answer 4

听起来好像你的问题不是关于MySQL或SQLlite。它是关于数据共享，以及数据供应商和相同数据用户之间需要存在的合同。

如果存在数据库以便可以共享数据，那么该合同对于数据库的一切都是至关重要的。当数据库首次建立，数据库理论首次得到巩固时，在20世纪60年代和70年代，数据共享是构建数据库的核心目的。今天，数据库经常被用于文件服务同样良好的地方。你的情况可能就是一个例子。

在您的情况下，您与数据供应商签订了乞丐合同。他们可以改变数据的格式，甚至可能改变语义，你所能做的就是搞砸它并处理它。这种情况绝非罕见。

我不知道你的具体情况，所以接下来可能会偏离目标。

如果由我决定，我想建立一个尽可能通用，灵活且稳定的数据库，而不会丢失结构化和托管数据的基本功能。也许，像星形图案这样的设计会有意义，但如果我真的在你的鞋子里，我可能采用一种非常不同的设计。

这就产生了从您给出的数据库中提取数据的问题，将数据转换为中央数据库支持的稳定格式，并将其加载到中央数据库中。你是在猜测这涉及到很多编程。这个过程在数据仓库文本中称为“ETL”，并不是最简单的编程挑战。

至少ETL会在一个地方收集所有难题。一旦将数据加载到为您的需求而构建的数据库中，而不是供应商的需求，将数据转换为有价值的信息应该相对容易，至少在编程或SQL级别。甚至有一些OLAP工具可以使数据像视频游戏一样简单。在这个层面上存在挑战，但它们并不是我在这里所讨论的同类挑战。

阅读数据仓库，尤其是数据集市。一开始对您的描述可能令人生畏，但可以按比例缩小以满足您的需求。