Database 牙科系统逻辑-用户-数据库

我正在开发一种新的牙科系统，它将在一些特定的国家用于牙医。我的基本要求和设计都差不多完成了，但我真的不知道如何处理安抚。以下是我的两个选择：

在一个表（pacient_表）中添加所有pacient，并在另一个表（link_表）中的pacient Destint之间创建链接，我将在其中存储pacient_id和Destint_id。如果任何其他牙医添加相同的pacient，他们只需添加此人的ID，所有详细信息将自动检索，并与该牙医创建一个新链接

为每个牙医创建一个新数据库。执行此操作时，可能存在同一pacient的多个实例（这应该不是问题）

我想我更喜欢选项1），因为我喜欢在这个选项和牙医之间有一个pacient和多个链接，而不是由每个牙医添加相同的pacient

请让我知道你认为哪个选项是最好的，为什么。 还欢迎新选项：）

---

谢谢

选项一在架构上是“纯粹的”。然而，它受到企业不喜欢与他人共享数据这一现实的影响。根据我的经验，企业不太可能意识到，他们花了大量精力开发的记录可能会被竞争对手直接使用

出于这个原因，我建议从商业角度来看，选项2更为合理

---

还请注意，在许多西方国家，医疗数据的处理方式受到严格限制。在美国，如果没有大量的认证和赔偿保险以及一家大公司的支持，你将无法销售这款产品。

你使用#1肯定是正确的。 在这种情况下，最好的设计可能是使用由三个表组成的单个数据库

第一个表“牙医”将存储办公室中每个牙医的所有属性（列），其中牙医id作为主键。此表表示实体“牙医”。当然，每行代表一位牙医

第二个表patient将存储关于每个患者的所有相关属性（列），patient_id作为主键。此表表示实体“患者”。与上面类似，每行代表一名患者

第三个表（概念上）位于牙医和患者之间，可能将其命名为“治疗”、“就诊”或类似的适当名称（您提到的链接表）。此表的目的是捕获并表示患者拜访牙医的事件。它有自己的主键，牙医id和患者id作为外键。它还可以包括就诊日期等。第三个表是一个复合实体，它统一了牙医和患者之间的关系并给出了结构

对这样一个模式的适当查询将揭示发生时哪个牙医咨询了哪些患者；以及哪些牙医治疗了最多的患者，等等

---

我希望这有帮助。祝你好运

嘿！感谢您花时间回答：）关于选项1，最终用户（牙医）不会知道所有的奶嘴都存储在同一张表中。所有要执行的查询都将在Relationship_表上执行（使用Destinator_id），并在此基础上检索pacient详细信息。我同意上一句话，我知道如果没有一些认证，我将无法在某些特定国家开展业务。多谢各位！精明的企业主会问这样的问题。