我想将表格的更新重新集中到Feed中。我们来看样本表
新闻，用户 - ＆gt; [信息更新，友谊， 图片，视频]，SomeOtherTable
每次更新或插入时都会触发一个事件。
现在，对于这些不同类型，将会有一些应该生成Feed的处理程序。
问题1： FeedTable，其列，本地化标题和文字。
我的第一个想法。
One Table: "Feed" {date, type, title, ...},
Second Table "FeedDetails[]" {name, value}
我的第二个想法，使用Linq to Sql继承
One Table: "Feed" {title, date, type, text, image1,
image2, image3, imagecount, video,
referenceId, referenceName,
referenceId2, referenceName2, ... }
在此我将创建一些类，然后我将列分配给linqtosql类。问题是本地化，所以在第二种方法中，我会将东西“渲染”到Feed中，因此不会执行任何操作或其他任何操作，它将直接绑定到控件。正如我所说，我有本地化的标题和文本等列，所以我必须将“feed”表拆分为更本地化的版本。
我需要一些清晰，易于维护，易于搜索的概念。有任何想法吗？是否清楚我想要实现的目标？
答案 0 :(得分：1)
如果您的Feed和FeedDetails表在记录之间具有1：1的关系，并且两者都引用相同的概念对象，那么您可以将它们放在同一个表中。不必要的连接只会使事情复杂化，甚至会降低性能。
本地化不会是1：1，因此应该在单独的表中处理，例如：
[TextKey] [RegionID] [LocalizedText]
其中PK是TextKey + RegionID，TextKey映射回Feed表。我同意@Thomas Rushton关于使用View的观点;你也可以使用一个存储过程，因为你将为它提供RegionID以及UserID和许多其他参数。
修改
即使FeedDetails与Feed不是1：1，您也应该为其提供自己的具有特定列名称的表格。使用名称没有特别的优势：值表;当您尝试将值映射回源条目时，您将只添加不必要的连接，开销和复杂性。更重要的是，只要有可能，名称：值表应该避免用于您描述的用途;关系数据库旨在使用列来描述数据，并使用内容的行。在名称中查找您要查找的内容：值表将昂贵和复杂。这会影响性能很多，因为每次要查询时，SQL都必须搜索name列。你不会编写一个程序，其中每个变量都是一个巨大的数组中的无类型object，所以你不应该用SQL做同样的事情。
此外，我不明白为什么饲料和Feed详情不会为1：1。即使有可选部件（如图像，链接或附件），也应尽可能使用可空字段。 Examine RSS feeds，可以选择包含对图像或其他数据的引用。如果这意味着许多可以为空的字段，您可以使用“图像”或“链接”等表格对数据库进行规范化。如果绝对必须，则可以对任何未预料到的特殊数据使用补充XML“misc”列。这是要避免的，但它仍然比使用name：value表更好，以避免SQL的目标和优化的表格形式。
你提到继承，但这并不重要。您的示例中有三个概念对象：新闻条目列表，本地化映射和用户对象。这些对象中没有一个与其他对象有很多共同之处，也没有任何明显的潜在基础对象，所以这里真的不需要继承。你甚至不需要对象组合，因为它们都没有分层数据结构。你说“问题是本地化”，但你也说本地化表存在且工作正常，我不明白为什么这应该是我描述的连接方案以外的问题。