sql – 数据规范化在什么时候变得荒谬?

前端之家收集整理的这篇文章主要介绍了sql – 数据规范化在什么时候变得荒谬?前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。
我经常发现自己质疑在创建数据库和关系时是否采用正确的方法来规划未来的可扩展性.

我有以下情况:

>我有一个Donor表和一个Recipient表.两个表共享公共信息,例如first_name,last_name,email_address,date_of_birth等.如果您原谅我的面向对象语言,它们似乎都共享一个共同的抽象类型的Person.有可能某个接受者的某个人以后可能会通过捐赠来成为捐赠者,因此重要的是不要在表格之间复制信息.我应该选择继承模式,还是应该将Donors和Recipients外键到Person表?
>最初,我在考虑简单地将email_address和街道地址属性属性直接映射到需要它们的东西,但是可能会出现一个人有多个电子邮件地址或邮寄地址(即:家庭,工作等)的可能性. ).这意味着我们有一个像这样的模型:

create table person(id int primary key auto increment,...,default_email_address);

create table email_address(id int primary key auto increment,email varchar(255),name varchar(255),is_default bool,person_id int);

这让事情变得有点复杂,你可以想象.名称字段还包含默认值列表以及允许自定义输入.我不能只把它变成一个枚举字段,因为有可能有人会收到大量的电子邮件,这些电子邮件可能会有所不同……(这就是我尖叫出来的那一点“它是否值得信赖它” !?!?“并对项目感到沮丧

我想这真正归结为以下几点:数据规范化在什么时候变得荒谬可笑?我的目标是创建一个非常好的向前兼容的数据模型,我不会自己创建以后创建.

解决方法

at what point does data normalization become ludicrous?

在它停止建模实际要求时.

举个例子:

>使用捐赠者和收件人表,如果任何一个人很可能同时成为两者,那么分离出一个人实体是有意义的.如果这种情况很少见,则不然.>使用email_address和street_address情况,取决于您是否需要存储倍数(期望是什么?).您可能希望为每个业务单位存储单独的版本(例如shipping_address vs billing_address).

原文链接:https://www.f2er.com/mssql/77623.html

猜你在找的MsSQL相关文章