我正在开发一种新的牙科系统，将用于某些特定国家的牙医。我几乎完成了基本要求和设计，但我不确定如何处理患者。这是我的两个选择：
在一个表 (pacient_table) 中添加所有 pacientes，并在另一个表 (link_table) 中创建 pacient-dentist 之间的链接，我将在其中存储 pacient_id 和 Dental_id。这样做，如果任何其他牙医添加了相同的患者，他们只需添加该人的 ID，所有详细信息都会自动检索并与该牙医创建一个新链接。
为每位牙医创建一个新数据库。这样做可能存在同一个患者的多个实例（这应该不是问题）。
我认为我更喜欢选项 1)，因为我喜欢在该患者和牙医之间有 1 个患者和多个链接的想法，而不是每个牙医添加的同一个患者。
请告诉我您认为哪个选项最好以及为什么。 也欢迎新的选择:)
谢谢！
【问题讨论】：
标签： database security database-design relational-database business-logic
#1 你肯定走在正确的轨道上。 在这种情况下，最好的设计可能是使用由三个表组成的单个数据库。
第一个表，dental，将存储有关办公室中每个牙医的所有属性（列），其中 dentin_id 作为主键。此表表示实体“牙医”。每行当然代表一个单独的牙医。
第二个表，患者，将存储有关每个患者的所有相关属性（列），其中患者 ID 作为其主键。该表表示实体“患者”。与上面类似，每一行代表一个患者。
第三个表（概念上）放在牙医和患者之间，可能将其命名为“治疗”、“就诊”或类似的适当名称（您提到的链接表）。此表的目的是捕获和表示患者去看牙医的事件。它将拥有自己的主键，以牙医 ID 和患者 ID 作为外键。它还可以包括 date_of_visit 等。第三个表是一个复合实体，它统一并赋予牙医和患者关系结构。
对这种模式的适当查询将揭示哪位牙医在何时咨询了哪些患者；以及哪些牙医治疗的患者最多，等等。
我希望这会有所帮助。祝你好运！
【讨论】：
选项一在架构上是“纯粹的”。然而，它受到企业不喜欢与他人共享数据的现实的影响。根据我的经验，企业不太可能意识到他们花费大量精力开发的记录可能会被竞争对手直接使用。
出于这个原因，我建议从商业角度来看，选项 2 更合理。
另请注意，在许多西方国家，医疗数据的处理方式受到严格限制。在美国，如果没有大量的认证和赔偿保险以及大公司的支持，您将无法出售此产品。
【讨论】：