ASP.NET 3.5的半结构化数据库设置

Question

小型“联系人管理”类型网站的最佳数据库设置是什么？它将仅在内部使用（Intranet），我使用的是ASP.NET 3.5和SQL Server。

数据库存储有关我们联系的人，他们工作的公司等的信息。许多人可以在同一家公司工作（n：1），但人们也可能在几家公司工作（n：m）。人们可以拥有多个电子邮件地址和电话号码。公司可以在不同的位置设置多个办事处等。数据库设计必须足够灵活，以便稍后添加新字段。

我知道几种不同的方法，但我不知道哪种方法最好。

• 针对不同主题（人，公司）的非常经典，不同的表格，包含许多字段，例如“email1”，“email2”，以及用于关联主题（人们在哪些公司工作的人）的表格，当有n时：我的关系。可以在以后添加其他字段（“email3”）而不会出现问题。将有许多空字段，因为您必须考虑任何人可能拥有的最大电子邮件地址数。
• 分隔表格，例如电子邮件地址，链接回人员表格。如果（例如）原始设计仅需要一个电话号码，则可能会出现问题，并且稍后决定在单独的表中处理电子邮件地址等电话号码。最终会有很多不同的表格。但是这种设计相对节省空间（很少有空场）。
• 邻接列表模型，其中每个属性在表中都有自己的记录，以及指向主记录的ID指针。例如，姓名，地址，所有电子邮件地址，所有电话号码等都存储为指向同一主要个人记录的单独记录。数据库根本没有空字段，以后可以自由地使用其他结构。
• 所有数据都以XML形式存储在SQL Server数据库中（使用XML数据类型）？
• 或者只是普通的XML文件？

Answer 1

我会建议一个关系数据库。您的项目似乎很简单，只需拥有正确关系的正确表格即可解决。我会远离XML，因为数据将保持一致。对于具有不可预测结构的数据（例如，族树），XML更好。数据库的性能会更好，维护起来也更容易。与XLM格式相比，在RDB中报告数据也更容易。 编写可扩展性代码是一种很好的做法。如果您正在管理联系人，我可以保证他们在某些时候需要多部手机。

当您拥有越来越多的属性但结构很简单时，邻接列表模型会更好。例如，您有许多问题和答案的配置文件，但它们都可以绑定到一个用户。