0

我正在开发一个将用作其他应用程序的可扩展框架的应用程序。

基本类之一称为节点,节点具有内容。SQL 表如下所示:

表节点(NodeId int,....等)

表 NodeContentRelationship(NodeId int、ContentType 字符串、ContentId int)

这将取决于扩展应用程序以创建自己的内容类型的开发人员。

显然,从关系数据库的角度来看,这是不好的,因为无法将外键关系添加到 NodeContentRelationship.ContentId,即使它外键列。

但是,该解决方案非常简单且功能强大,因此我不愿意更改它。

你怎么看 - 我会在赛道上陷入痛苦的世界吗?

4

4 回答 4

8

当心内部平台效应

如果您正在尝试构建一个“可扩展框架”,允许开发人员存储不同“内容类型”的数据并以通用方式将它们相互关联,您可能会发现其他人已经解决 了这个 问题

于 2008-11-17T06:14:09.630 回答
4

为什么不能设置NoteContentRelationship.ContentId为外键?您可以轻松地将关系继承模型与Content表示抽象基类的表和表示派生类的各种表等AnimalContent一起使用。CarContent

于 2008-11-17T06:14:57.880 回答
3

在我看来,这就像 EAV(实体、属性、值)设计的变体。

EAV 设计的优点和缺点已被广泛记录。

以下是从同情的角度对 EAV 的描述:

http://ycmi.med.yale.edu/nadkarni/Introduction%20to%20EAV%20systems.htm

这是一个从敌对的角度来看的:

http://tonyandrews.blogspot.com/2004/10/otlt-and-eav-two-big-design-mistakes.html

在投入数千个工时将数据注入其中之前,请注意 EAV 的缺点。它对程序员来说极具诱惑力,但它可能成为数据管理员的噩梦。

于 2008-11-17T15:12:39.247 回答
0

如果您想实际报告这些数据,那么您将面临一个痛苦的世界。你只是让编写连接等变得更加困难。缺乏约束是不好的,但查询所需的额外工作(恕我直言)更糟。

但是,如果您希望其他开发人员能够扩展系统并将数据存储在数据库中但不能更改数据库模式,则可能没有选择。在这种情况下,答案是尽量减少以这种方式存储的数量。您还可以通过将 ContentType 替换为另一个表中定义的 ContentTypeId 来稍微加快速度。

于 2008-11-17T15:46:35.683 回答