数据库方法-冗余数据

发布于 2024-11-25 20:14:05 字数 244 浏览 1 评论 0原文

我有 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 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

凤舞天涯 2024-12-02 20:14:05

我建议:

products (product_id, name, price, etc)
orders (order_id, date, payment_method, etc)
orderitem (orderitem_id, order_id, product_id, ...)
shipment (shipment_id, order_id, ... )

发货有点多余 - 我会将地址等添加到订单中......

I would suggest:

products (product_id, name, price, etc)
orders (order_id, date, payment_method, etc)
orderitem (orderitem_id, order_id, product_id, ...)
shipment (shipment_id, order_id, ... )

shipment is kind of redundant - I'd add the address etc into orders...

浮光之海 2024-12-02 20:14:05

你可以这样做,但要小心 - 如果订单表中的信息可能更改,这将是一个问题 - 即,如果订单表中的相应记录更改了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.

我早已燃尽 2024-12-02 20:14:05

遵循真与美的原则,您不应该存储冗余数据 - 这是发生错误的好机会,它很丑陋,它会导致未来开发人员的头脑混乱。

你可以打破真与美的原则,但前提是你遇到了无法用其他方式解决的问题。例如,如果您发现连接到订单表的查询太慢,那么对数据进行非规范化(这是您正在执行的操作的技术名称)是可以的 - 如果您记录它并确保所有开发人员都理解。

只是避免查询中的额外连接似乎不是一个足够好的理由......

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....

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文