“多家公司”设计模式

Question

数据库是否存在“多公司”设计模式？前几天我们被教授告知，这是一个相对简单的功能，可以增加设计时间，我们应该将它应用于当时可能由多家公司使用的任何软件，例如公司（例如公司） D）由A，B，C公司制造。

他的建议总的来说就是这个。

• 所有目录都应包含公司的ID。
• 所有报告都应在其输入参数中包含公司 报告的运行情况或是否适用于所有公司

例如......

这是一种可接受的方式来建立数据库，这些数据库可以容纳多个公司的注册表，而不会混合它们吗？

有更好的效率吗？

我问，因为这不是我们第一次被告知过时的东西，我希望能够深入了解当前的设计趋势（或在哪里找到它们）

干杯。

Answer 1

这里有一些不同的考虑因素：

技术注意事项

从纯粹的技术角度来看，Multi Company数据库的建模没有任何理由与Multi Anything数据库的建模方式不同。这样，任何分类都会导致特定的类别ID作为外键在整个数据库中传播，以维持类别分离。

因此，从数据库技术的角度来看，这非常简单且非常可能。

体系结构注意事项

您的数据库支持的应用程序类型也将适用于合适的设计。例如，如果您计划托管一个交易量很大的软件即服务应用程序，您可能希望为多个公司运行多个实例，以满足性能，利用率，许可等等。这是百万个例子中的一个。超出数据库技术限制的架构考虑。

因此，从Architectural的角度来看，您有很多选择，包括单个实例中的所有公司，每个公司的多个实例，或两者的混合（基于每个公司的事务繁重表和共享区域/数据库中的共享表） ）。

法律/许可注意事项

在同一数据库中存储跨公司数据可能存在问题，甚至可能存在于同一台机器（虚拟或其他）上。这也可能是您需要重新考虑架构的原因，这反过来又需要重新考虑数据库设计。

<强>摘要

正如您所看到的那样，有很多（并且比我列出的要多得多）可能导致架构更改的原因导致您以这种或那种方式引导数据库设计。但从技术角度来说，从一般意义上说，在相关表中传播“公司ID”并使您的应用程序或数据库级安全性运行以确保每个公司只获得他们自己的数据浮出水面没有任何问题。

在实际情况下，您会有更多考虑因素会影响您的决策（我知道很多公司曾经为法律或法规要求将特定数据集分开）。