【发布时间】:2013-05-25 00:33:57
【问题描述】:
我正在尝试设计一个数据库,并且想知道我的设计是否有意义。
我正在尝试为小型内部复印店设计一个数据库来跟踪订单和定价工作。我认为创建关系数据库将是存储此信息的好方法。典型订单的几个例子是:
- 订单 #1:100 套 7 张黑白页面和 3 张彩色页面,装订在 20 磅 8.5x11 普通纸上
- 订单 #2:一张 24" x 36" 海报,层压并安装在泡沫芯上
我开始着手的设计是这样的:
例如,我有:
- 产品:{复制订单、海报}
- 属性:{黑白页面、彩色页面、套装、装订、纸张尺寸、纸张类型、海报尺寸}
- 属性选项:{Staple Upper-Left, ..., 8.5x11, ..., Plain 20lb, ..., 24" x 36", ...}
到目前为止,我认为这是合理的。我不知道如何添加定价配置文件。问题是属性选项的价格取决于其他属性选项,并且在每种情况下都不同。使用上面的例子:
- 订单 #1 的价格:[在 8.5x11 普通纸上打印的黑白价格]x[黑白页数] + [在普通 8.5x11 纸上打印彩色的价格]x[彩色页数] + [数量套数]x[订书钉价格]
- 订单 #2 的价格:[24x36 层压并安装在泡沫芯上的海报的价格]x[海报数量]
此外,我们对不同类型的客户收取不同的价格,所以我计划有多个价格配置文件。
在关系数据库中是否有任何合理的方法可以做到这一点?或者我应该以其他方式做吗?现有数据库设计不佳(几年前由我设计),并且大多数属性硬编码为字段名称,每个产品都有单独的表。例如,paper_type 是 copy_orders 表中的一个字段,而 poster_size 是 poster_orders 表中的一个字段。我使用代码来计算价格。我想设计一些更好、更灵活的东西。
我(显然)不是关系数据库方面的专家,因此我们将不胜感激任何建议!谢谢!
【问题讨论】:
-
我建议您提供一个实体关系表以便更快地回复。
-
我贴的图不够吗?我不确定还要上传什么 - 有没有更好的方法来上传图表?
-
ERT 表包括 1:1、1:many 等关系船以及共享列(如外键)。您可以尝试从您的方案中导出一个。
-
哦,我明白了。是的,我在那里有点懒惰,还没有定义它们。
标签: database-design relational-database