我有一个用例,我需要为不同口味的冰淇淋建模参考数据.说我有50种口味的冰淇淋: -
- 所有口味都会分享20种属性,例如冰冻温度,奶油味
- 每种口味的冰淇淋都有20-30个属性,不会与其他口味共享,例如: -
- 草莓冰淇淋可能会跟踪酸味,水果百分比等.
- 巧克力冰淇淋可能会追踪苦味,可可等级.
我如何在数据库模型中整齐地建模这些数据,纯粹从存储/检索的角度来看？
我能想到的选择: -
- 每种口味一张桌子.这将需要50个表,每个表将有20个彼此重叠的列,以及另外20-30个属性,这些属性将是独特的.
- 优点:很好地模拟每种风味的数据
- 缺点:列重叠和需要大量表
- 所有口味的一张桌子.这只需要1个表,但需要1000多列,其中大部分都是空的.
- 优点:一般来说,很好地模拟冰淇淋的数据
- 缺点:大量的列和大量的"浪费"空间
- 所有风格的一个键值表,包含flavor Id,属性名称和属性值.
- 优点:最简单的创建和插入数据
- 缺点:难以提取,不是真正的数据模型本身,难以形成属性约束或与其他属性相关的属性