问题标签 [data-modeling]

建模以下内容的最佳方法是什么...

假设我有两个对象：Agency和Publisher，并且两者都与Employee. 这是一个真正的 1 对 n 关系，因为每个Employee只能为一个Agency或一个工作Publisher。让我们进一步假设我不能引入具有Employer1 对 n 关系的超类型（例如 ）。

我首选的解决方案是有一个外键，Employee它可以链接到Agency或的主键Publisher（我的所有主键都是 64 位 ID，在数据库中是唯一的）。但是，现在我将无法映射双向关联，而无需指明Employee这是否是一种Agency或Publisher关系。

我的另一个选择是使用两个表AgencyEmployee和PublisherEmployee，然后可以将它们链接为传统的 1 对 n 双向关联。

在这种情况下，您认为最佳做法是什么？

更新：感谢您在如此短的时间内做出如此出色的回应！您如何看待以下解决方案： and 的外键，Employee例如and ？ AgencyPublisheragency_idpublisher_id

我正在寻找免费提供的示例数据来进行一些 ORM 验证和性能测试。我的主要要求是：

• 区分类型：需要包含某种继承，例如Party -> Person and Organisation；
• 合理复杂的数据模型；
• 一些相当大的表（至少在数十万行中）；
• 多平台：至少有 Oracle、MySQL 和 SQL Server；
• 容易理解。例如，CRM 应用程序就是我所说的易于理解的东西。人们了解客户、客户等等。

谁能指出我这样的事情？

每个Customer人都有一个实际地址和一个可选的邮寄地址。您首选的建模方式是什么？

选项 1.Customer有外键Address

选项2.Customer与 具有一对多关系Address，其中包含描述地址类型的字段

选项 3. 地址信息被反规范化并存储在Customer

我最重要的目标之一是简化对象关系映射，所以我倾向于第一种方法。你怎么认为？

我正在尝试创建一个包含两个主要实体的联系人应用程序 - 个人和公司。一个人可以有许多电子邮件、号码和地址。一家公司也可以有许多电子邮件、号码和地址。我正在尝试确定适合这种情况的设计。

选项 #1 - 多个外键
电子邮件、号码和地址将有两列称为 person_id 和 company_id。根据数据所属的实体，一个将为空，另一个将包含一个链接回父级的 id。

选项 #2 - 每个实体每个类型一个表
我复制每个表，因此会有一个 company_addresses 表和一个 person_addresses 表。我会有两倍多的表，但这是目前最有意义的解决方案。

选项 #3 - 一个链接表
我创建一个表 - “链接”。该表将包含四列：source_id、source_entity、dest_id、dest_entity。因此，如果一家公司获得一个新号码，您将有如下一行：1，号码，2，公司。

选项 #4 - 多个链接表
我为每种类型的链接（company_address、person_address、company_email、person_email 等）创建一个表

你会选择哪个选项？

我正在尝试确定在关系数据库中对记录关系进行建模的最佳方法。这是经典的朋友/关注模式：

~~~~

一个用户可以有零到多个朋友。
一个用户可以有零到多个关注者。

朋友和追随者都是用户本身。

~~~~~

对此进行建模的最佳方法是什么？

谢谢！

情况：
假设我们正在实现一个基于 JCR 并支持本地化的博客引擎。
内容结构看起来像这样/blogname/content/[node name]

问题： 命名内容节点（/blogname/content/ [nodename]）以满足以下要求的最佳方法是什么：

1. 节点名称必须在 HTML 中可用以支持类似 REST 的 URL，即：blogname.com/content/nodename 应指向单个内容项。
2. 上述要求不能产生丑陋的 URL，即：/content/node_name 是好的，/content/node%20name 是坏的。
3. 给定节点名称，编程检索应该很容易，即：//content[@node_name=some-name]
4. 命名方案必须保证节点名称的唯一性。

PS：使用的JCR实现是JackRabbit

我目前正在将一些小型个人网站从 WebForms 转换为 MVC。对于现有站点，数据库架构是可靠的，但我从未真正花时间构建适当的数据/业务模型/层。aspx 页面都使用各种视图和存储过程直接与数据库对话，这些视图和存储过程是为方便起见而根据需要创建的。使用 MVC，我现在正尝试按照他们所说的那样“做正确的事”，并使用 LINQ to SQL 和/或实体框架之类的东西来为应用程序构建一个或多个适当的数据模型。

我的问题围绕着构建数据模型应该有什么目标。我阅读了各种与模式相关的文章，我意识到最终答案可能取决于我的数据的特征。但通常我是否应该尝试构建包含尽可能多的数据库的更大模型，以便只有一种方式与给定的表集交互？或者我应该为每个 MVC 视图构建更小的自定义模型，只包含视图需要的数据和访问权限？

我对这个讨论相当陌生，但即使冒着听起来“无知”的风险，我也必须提出这个问题。为什么我们现在对'DDD'如此强调。我对“DDD”的研究越多，我的应用程序似乎就越复杂。而使用数据库对我的域进行建模有助于使我的应用程序跨层保持一致。然后我可以使用 DAL Helpers（如 SubSonic 或 L2S）轻松访问该模型。这有什么不好？即使在企业应用程序中？

当我们有一个经过尝试和测试的方法时，为什么我们要努力创建一种新的域建模方法？

我愿意听取这里纯粹主义者的意见。

请就以下问题澄清我，谁将做伟大的数据模型设计？技术主管/数据库管理员

谢谢， Gunasekaran Sambandhan

我刚刚开始使用 ASP.NET MVC，试图首先了解这一理念。我想我很清楚控制器和视图所扮演的角色，但我对模型部分有点困惑。一些消息来源说它是域模型，有人说它是数据模型，有人说它是绑定到视图的对象。

恕我直言，这些是非常不同的事情。那么请有人可以一劳永逸地解决这个问题吗？