代码之家 › 专栏 › 技术社区 › Shawn

决定定价向导的数据库结构

database-design linq-to-sql sql

Shawn · 技术社区 · 16 年前

我们正在处理一个小项目,它需要自定义表的定价向导。(是的,真正的定制餐桌——你吃的那种。从这里开始,我将称它们为厨房桌子,这样我们就不会感到困惑)我想出了一个模型,其中每个厨房桌子部分都是一个数据库表。所以数据库是这样的:

TableLineItem
-------------
ID
TableSizeID
TableEdgeWoodID
TableBaseID
Quantity

TableEdgeWoodID
---------------
ID
Name
MaterialUnitCost
LaborSetupHours
LaborWorkHours

每个部件都必须能够计算出其价格。大多数计算结果都非常相似。我喜欢这种结构,因为我可以将它直接拖到linqtosql设计器中,并生成我所有的类。(更少的代码编写意味着更少的维护…)然后我实现了一个计算成本接口,它只接受表的大小。我已经写了一些测试和这个函数。我还添加了一个表来根据之前的选择在UI中过滤部件。(你不可能有一个特定的木材有特定的饰面。)在模型中还有其他一些一次性的例外,我把它们硬编码了。这个模型非常严格,不断变化的需求会改变数据模型。(例如,如果所有的桌子突然都需要雨伞。)

选项B:

Spec
----
SpecID
SpecTypeID
TableType_LookupID
Name
MaterialUnitCost
LaborSetupHours
LaborWorkHours

SpecType 
--------
SpecTypeID
ParentSpecType_SpecTypeID
IsCustomerOption
IsRequiredCustomerOption

等。。。

问题:

您喜欢哪种数据库结构?请随意提出你自己的建议。
什么是最佳实践?如果有多个类似的数据库表,您是创建一个带有类型列的数据库表,还是创建几个不同的表?我怀疑答案是以“视情况而定…”开头
两种方法估计的时间差是多少(1周、1天、延长150%等)

提前谢谢。如果你有任何问题请告诉我,这样我就可以更新这个。

5 回复 | 直到 16 年前

dsteele 16 年前

由于设计的数据库结构符合客户最初的规范,但结果却过于严格,我经常会采用更灵活的方法,即使设置起来需要更多的时间。

Tom H zenazn 16 年前

我现在没有时间给出完整的答案,但我会把这个扔掉:

基于开发工具设计数据库通常是个坏主意,而开发工具正是用来编写代码的。
你想成为普通人吗 到一定程度 . 数据库中的表应该表示某种东西,而且有可能使其过于通用。例如,一个名为“Things”的表可能太通用了。
可能会产生超出预期的约束。你的“桌子底座”和“桌子木头”的例子对我来说没有意义,但是如果你能扩展到一个具体的例子,也许有人能帮上忙。

根据您在下面关于表基和木材的注释,您可以设置一个名为tabletattributes(或类似的)的表,并且每个可能的选项都是特定的表属性类型。然后,您可以通过外键强制任何给定的选项仅用于其应用的属性。

D'Arcy Rittich 16 年前

在您提供的模式中,抽象(spec)和特定(TableType_LookupID)混合使用。我倾向于平衡抽象级别,因此使用以下实体:

ProductGroup (for the case where you have a product that is a collection of other products)
Product
ProductType
ProductDetail 
ProductDetailType
etc.

Andomar 16 年前

我的经验告诉我:

毫无疑问,我会选择第一种方法。选择最简单的设置。如果你增加了复杂性,一定要问问自己,它对客户有什么价值?
什么是最佳实践? 这确实取决于项目的规模和预期的变化率。一般来说,当您希望客户添加新类型时,泛型表是值得的。例如,如果您的客户希望能够向表中添加一个新的“color”实体,则需要通用表。你不能事先预测他们会加什么。
valid estimate . 您对编码有信心的方法将花费最少的时间。在这里,我的猜测是方法1的速度可能是5-50倍。通用表在数据库和客户端都很困难。

Jas Panesar 16 年前

选项B。。

一般来说,通用的比具体的好。 软件已经注定要失败或达到它的能力,它的设计只是为了一组特定的任务。如果你构建了一些通用的东西,如果用一个现实的分析来抽象它可能会走向何处,那么它的破坏会更少。只要你远离过度抽象和抽象不足,这可能是最佳选择。

在这种情况下,“代码越少越好”这句格言可能会被引申到你不必再回来重新编写它了。