跨应用程序共享表的最佳实践

我们在我们的小型办公室中运行一个MySQL实例。我们有3个不同的应用程序，都使用db作为其后备存储。单个模式具有所有三个应用程序的所有表。所有的应用程序都使用一些常用表（例如tbl_users，tbl_facilities等）。我一直在使用的应用程序前缀模式对象从视觉上的其他应用程序将它们分开的对象，例如：跨应用程序共享表的最佳实践

foo_tbl_settings
foo_tbl_orders
foo_vw_recent_orders
doof_tbl_settings
doff_vw_parts

我从来没有对此感到满意，它总觉得我应该使用单独的sc赫马;一个用于每个逻辑应用程序，然后是共享对象的共享架构（用户表等）

共享公用表非常重要，我不想放弃它。

我已经为这个主题做了一些Google搜索，但没有发现任何真正解释这是否是一种好的做法。我希望你们中的一些人能够就我这种情况的最佳实践向我提供建议。

来源

2011-09-08 Steve K

'foo_tbl_settings'很自然地转化为'foo.tbl_settings' ... –

我同意，但你在暗示什么？我确实使用单独的模式？ –

这些前缀的使用表明存在一个干净的分隔，但我没有发布答案，因为我不想详细说明细节:) –

说实话，除非有一个令人信服的理由来共享一个数据库，否则每个应用程序不能只有一个数据库吗？

你已经说过他们'共享'表，但是你已经描述了不同名称的表名，这表明虽然他们共享相同的结构，但他们实际上并不共享数据。除非我误解了我建议每个应用程序有一个数据库的事情。这也将允许您将数据库和应用程序移动到新的位置，而无需将其从服务器上的其他应用程序中分离出来。

来源

2011-09-08 07:15:55 dougajmcdonald

我可能不清楚：应用程序共享与某些共享表中相同的数据。所以这就是我们有类似的表格，这是因为我们有实际具有共享数据的表格（例如，用户帐户数据） –

实际上，共享表并不是一个很好的行为。

但是，如果您真的需要这样做，您可以为每个应用程序创建不同的架构，并创建一个通用架构shared_schema。

通用模式可以有共享表。

然后在每个应用程序模式中，您可以为要从共享模式连接的每个表创建mysql views。您可以使用此架构中所需的名称命名每个视图。现在您可以使用不同名称描述表格了。

来源

2011-09-08 08:07:59

感谢您的信息 - “共享表格不是一个很好的行为” - 您能否详细说明这一点？我并不是不同意，但想知道它是一个坏主意的主要原因是什么。 –

这可能会导致状态不一致，例如：如果您是一位Web开发人员，则可能会在您的服务器上执行一些回调后删除记录以清除某些数据或创建一些业务逻辑。如果记录从另一个应用程序中删除，则其他应用程序将不会收到通知，因为这是从您的ruby代码处理的。\ –

我了解您的示例，但它不适用于我们将共享的表格。实际上，我们实际上想分享很少的表格，实际上我目前唯一能想到的是_user，_user_roles和_roles表格。客户端应用程序不会删除这些表中的记录，也不会触发设置或导致级联更改的任何事情。是否有任何其他原因（性能，易管理性等）使跨架构共享表是个坏主意？ –

跨应用程序共享表的最佳实践

回答

相关问题