我正在开发一种新的牙科系统，该系统将在某些特定国家/地区用于牙医。我的基本要求和设计都差不多完成了，但是我不太确定如何处理专家。这是我的2个选项：
将所有pacientes添加到一个表（pacient_table）中，并在另一个表（link_table）中的pacient-dentist之间创建链接，我将在其中存储pacient_id和dentist_id。这样做，如果任何其他牙医添加相同的pacient，他们只需添加该人的ID，所有详细信息将自动检索并与该牙医创建新链接。
为每个牙医创建一个新的数据库。可能存在同一位病人的多个实例（这应该不成问题）。
[我认为我更喜欢选项1），因为我喜欢这样的想法，即在该技术人员和牙医之间具有1个有效和多个链接，而不是每个牙医都添加相同的功能。
[请让我知道您认为哪种选择是最好的，为什么。也欢迎新的选择：）
谢谢！
您肯定在＃1的正确轨道上。在这种情况下，最好的设计也许是使用包含三个表的单个数据库。
第一个表，牙医，将以dentist_id作为主键来存储办公室中每个牙医的所有属性（列）。该表代表实体“牙医”。当然，每一行都代表一个牙医。
第二张表，病人，将存储与每个病人有关的所有相关属性（列），并将Patient_id作为主键。该表代表实体“患者”。与上面类似，每一行代表一个患者。
第三张表（在概念上）放在牙医和患者之间，也许将其命名为“治疗”，“就诊”或其他类似的合适名称（您提到的链接表）。该表的目的是捕获并代表患者去看牙医的事件。它将拥有自己的主键，其中dentist_id和Patient_id为外键。它也可以包括date_of_visit等。这第三张表是一个复合实体，它统一并提供了牙医和患者关系的结构。
对这种模式的适当查询将揭示出当发生时哪个牙医咨询了哪些患者；以及哪些牙医为患者提供了最多的治疗，等等。
我希望这会有所帮助。祝你好运！
选项一在架构上是“纯”的。但是，它遭受这样的现实困扰：企业不喜欢与他人共享数据。以我的经验，企业不太可能会理解他们花费大量精力进行开发的记录可能会被竞争对手直接使用。
因此，从业务的角度来看，我建议选项2更合理。
还请注意，在许多西方国家，如何处理医学数据受到严格限制。在美国，如果没有大量认证和赔偿保险以及一家大公司的支持，您将无法出售此产品。
[我认为选项2最好为每个牙医创建一个新的数据库。这样做可以存在同一位患者的多个实例，我们应该与所有人一起探讨的好主意真的很感激您的职位，因为我是Eastern Oklahoma Dental Care的一名工人我将与我的所有同事和医生一起发布此帖子，并等待您的其他帖子。