dba*_*aut 5 database-design sql-server
我正在为当地一家慈善机构建立数据库。该数据库将填充来自不同来源的条目并每天更新。
其中一个元素(例如汽车)与许多元素(例如汽车颜色)有关系。
我的一位正在帮助该项目的朋友建议使用 JSON 字段。我不是 DBA,也许我不完全理解使用 JSON 相对于多对多表的好处。
我可以按如下方式构建汽车表:
其中条目将是:
Cars
+----+--------+-------------------------------+
| id | name | colors |
+----+--------+-------------------------------+
| 1 | Fiesta | { "15": "red", "22": "blue" } |
+----+--------+-------------------------------+
Run Code Online (Sandbox Code Playgroud)
或者我可以构建一个多对多表:
其中条目将是:
Cars
+----+--------+
| id | name |
+----+--------+
| 1 | Fiesta |
+----+--------+
Colors
+----+------+
| id | name |
+----+------+
| 15 | red |
+----+------+
| 22 | blue |
+----+------+
CarsColors
+----+-------+---------+
| id | carID | colorID |
+----+-------+---------+
| 1 | 1 | 15 |
+----+-------+---------+
| 2 | 1 | 22 |
+----+-------+---------+
Run Code Online (Sandbox Code Playgroud)
就我个人而言,我发现第二种方法会更干净,特别是因为将来我们需要执行“查找所有红色汽车”之类的操作。我知道答案可能是“视情况而定”,但是,请问您能给我指出正确的方向吗?
“找到所有红色的汽车”是一个关系问题,因此具有您在第二个示例中设计的表结构的规范化关系数据库比 JSON 更有意义。JSON 使高度可变和无结构的场景变得更容易,但是当您在对象(实体)之间存在关系(例如Cars和 )时Colors,那么使用 JSON 而不是关系数据库是“懒惰的开发人员解决方案”。从长远来看,当您必须询问像您的示例这样的关系问题时,当数据存储在 JSON 中而不是具有规范化表的关系结构时,需要做更多的工作。
| 归档时间: |
|
| 查看次数: |
1091 次 |
| 最近记录: |