数据库方法-冗余数据
我有 3 个表:
products (id, name, price, etc)
orders (id, date, payment_method, etc)
shipments (id, order_id, product_id, address, etc)
我的问题是:保留在shipments 表product_id 中是否正确?我将其保留在这里是为了在不使用订单表的情况下查找有关已发货产品的信息。
I have 3 tables:
products (id, name, price, etc)
orders (id, date, payment_method, etc)
shipments (id, order_id, product_id, address, etc)
My question is: It is correct to keep in shipments table product_id? I keep it here to find information about a shipped product without using orders table.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(3)
我建议:
发货有点多余 - 我会将地址等添加到订单中......
I would suggest:
shipment is kind of redundant - I'd add the address etc into orders...
你可以这样做,但要小心 - 如果订单表中的信息可能更改,这将是一个问题 - 即,如果订单表中的相应记录更改了product_id,数据库将不一致。
我确实使用了冗余列,例如在静态字典中。
还要检查数据库设计的范式(NF),我不确定这种冗余是否不违反某些范式。但是否保留一些 NF 取决于您。
You can do it, but be careful - if the information in table orders could change, it would be a problem - i.e. if the appropriate record in table orders changes the product_id, the database would be inconsistent.
I do use redundant columns e.g. in static dictionaries.
Also check for the NORMAL FORMS (NF) of database desing, I'm not sure if this redundancy doesn't violate some normal form. But it is up to you if you decide to keep some NF or not.
遵循真与美的原则,您不应该存储冗余数据 - 这是发生错误的好机会,它很丑陋,它会导致未来开发人员的头脑混乱。
你可以打破真与美的原则,但前提是你遇到了无法用其他方式解决的问题。例如,如果您发现连接到订单表的查询太慢,那么对数据进行非规范化(这是您正在执行的操作的技术名称)是可以的 - 如果您记录它并确保所有开发人员都理解。
只是避免查询中的额外连接似乎不是一个足够好的理由......
Following the principles of truth and beauty, you should not store redundant data - it's a great opportunity for bugs to occur, it's ugly, it causes confusion in the minds of future developers.
You're allowed to break the principles of truth and beauty, but only if you run into a problem you cannot solve in any other way. For instance, if you find your queries are just too slow by joining to the orders table, denormalizing the data (which is the technical name for what you're doing) is okay - if you document it and make sure all developers understand.
Just avoiding an extra join in a query doesn't seem like a good enough reason....