DB设计，规范还是不规范？

Question

使用2012，Asp.net C# MVC 4，实体框架，

嗨，伙计们，我有数据库设计查询，它的实际困惑我，通常我没有问题的DBs。

然而，自从过渡到代码第一步之后，我问自己这个问题.

我正在为我的NopCommerce CMS网站创建一个新的插件，这个插件应该是一个ImageGallery插件。

我希望数据层存储一个

ID,
Name,
LargeImg
SmallImg,
Urlimg

但是我也想要实现这个插件的功能，用户应该能够上传任何图片，然后将这个图像关联到其中选择的部分，我的意思是Img到博客文章，或者Img到新闻帖子，Img到产品帖子或者所有的3。

现在，这三个示例是我唯一能想到的，但正如您已经猜到的，这可能会根据附加内容类型而改变。

现在我立刻想到，很简单，我们只需创建一个字段called.....Type？还是ContentType？该字段将存储图像关联的“类型”，无论是博客、新闻还是产品项目。

这时我想到“但是如果一个图像有多个关联呢？”

在这种情况下，我是否应该：

• 为每个“内容类型”创建单独的列(非规范化)
• 创建名为“内容类型”的1列(规范化)
• 创建一个完全独立的表，称为“内容类型”，并使用关系。

由于某些原因，我通常不会对DB的设计和实现产生空白。

下面的代码是我插件中的域类，我选择了2号，但我不确定是否会继续这样做。

using Nop.Core;
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;

namespace Hroc.Plugin.Misc.ImageGallery.Domain
{
    public class ImageItem : BaseEntity
    {
        public virtual int ImageID { get; set; }
        public virtual string Name { get; set; }
        public virtual byte[] Largeimg { get; set; }
        public virtual byte[] Smallimg { get; set; }
        public virtual string URLimg { get; set; }
        public virtual string Typeimg { get; set; }
        public virtual int LinkID { get; set; }
    }
}

希望你们能指出正确的方法来实现这一点，谢谢！

Answer 1

有了所有的东西，就有了一个交换。

在您的案例中，正常化的好处是：

• 可扩展性-添加另一种内容类型不需要更改结构/类。
• 较小的表(对于可变长度的数据，差异可能并不显著)

缺点：

• 查询--如果需要在一个查询中提取多个类型，则需要去规范化。
• 完整性开销-如果没有正确管理孤立数据的可能性

如果我设计这个特性，我会选择选项3-规范化内容类型还有其他优势，比如能够使用该表进行下拉列表。