将数据拆分到多个数据库的优良作法? [英] Good practise to split data over multiple databases?

问题描述

我正在设计一个用于信息系统的数据库.它将包含有关客户，员工和物品的数据.不用说，仅客户"部分就有大约十二张桌子.

I am designing a database for use in an information system. It will have data on customers, employees and items. Needless to say, the customers section alone has about a dozen tables.

我想知道将数据拆分到多个数据库中然后在它们之间进行引用是一种不好的做法，还是将它们全部保存在同一数据库中会更好.

I would like to know if it's bad practise to split this data over multiple DBs and then just refer amongst them, or if keeping them all in the same DB would be better.

因此，宁愿有一个带有两个表(例如 CUS_DETAILS ， EMP_DETAILS 等)的单个数据库(例如 Company_DB )，最好有两个数据库( Company_Cus，Company_Emp )，其中一个具有 CUS_DETAILS ，另一个具有 EMP_DETAILS ?

So, rather having a single DB (e.g. Company_DB) with two dozen tables (e.g CUS_DETAILS, EMP_DETAILS, etc), would it be better to have two DBs (Company_Cus, Company_Emp) with the CUS_DETAILS in one and EMP_DETAILS in the other?

致谢.

推荐答案

良好实践"是使我们的偏见听起来比实际中更重要的短语之一.

"Good practice" is one of those phrases that allows us to make our prejudices sound more important than they really are...

通常，您希望将属于一起的事物存储在一起.如果您拥有一个单一的信息系统，该信息系统可以为一家企业运行所有内容，并且您管理的实体之间是相互关联的-客户拥有订单，订单拥有销售人员和产品-您可能会说它们属于同一个人.另一方面，如果您发现您的表岛"没有真正链接到任何其他表，则它们可能不属于一起.

In general, you want to store things together that belong together. If you have a single information system, that runs everything for a business, and the entities you manage are related to each other - customers have orders, orders have sales people and products - you could argue they belong together. If, on the other hand, you notice that you have "islands" of tables that don't really link to any other tables, perhaps they don't belong together.

从可维护性的角度来看，管理更多的数据库意味着更多的备份，更多的维护例程和更多要管理的安全配置文件.

From a maintainability point of view, managing more databases means more back-ups, more maintenance routines, and more security profiles to manage.

从可读性的角度来看，在不同的数据库中搜寻以查找您感兴趣的表可能是一件坏事-例如，在客户"和员工"之间存在多对多联接表-例如销售团队-那张桌子住哪儿?在客户"数据库中还是员工"中?

From a readability point of view, hunting around different databases to find the table you're interested in is probably a bad thing - for instance, where there is a many-to-many join table between "customers" and "employees" - e.g. sales team - where does that table live? In the "customer" database, or "employee"?

从可靠性的角度来看，我不确定您是否可以在数据库之间强制使用外键约束.

From a reliability point of view, I'm not sure if you can enforce foreign key constraints across databases.

我真的想不出这样做的好处-所以我会说这是一个坏主意.

I can't really think of any benefits of doing this - so I would say it's a bad idea.

这篇关于将数据拆分到多个数据库的优良作法?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！