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

Question

选项A

我们正在开发一个小项目，需要定制表的定价向导。 （是的，实际的自定义表 - 你吃的那种。从这里我称之为厨房餐桌，所以我们不要混淆）我想出了一个模型，其中每个厨房餐桌部分是一个数据库表。所以数据库看起来像这样：

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

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

每个部分都必须能够计算其价格。大多数计算非常相似。我喜欢这个结构，因为我可以将它直接拖到linq-to-sql设计器中，并生成所有类。 （更少的代码编写意味着维护更少...）然后我实现了一个计算成本接口，它只接受表的大小。我写了一些测试，这个功能非常好。我添加了一个表，根据以前的选择过滤UI中的部分。 （你不能拥有特定饰面的特定木材。）在模型中有一些其他的例外，我对它们进行了硬编码。这个模型非常严格，不断变化的要求会改变数据模型。 （例如，如果所有桌子突然需要遮阳伞。）

选项B：

在与同事们进行了多次会议之后（可能花了比考虑这个项目大小更多的时间），我的同事们决定他们更喜欢更通用的方法。像这样：

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

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

等...

这是一种更通用的方法，可用于构建任何产品。 （比如，如果他们开始销售椅子......）我认为这需要更长的时间来实施，但将来会更灵活。 （虽然我怀疑我们会重新考虑这个。）你也失去了一些参照完整性 - 你需要触发器来强制不能为表木头设置表格。

问题：

1. 您更喜欢哪种数据库结构？随意建议你自己。
2. 什么是最佳做法？如果您有几个类似的数据库表，是创建1个带有类型列的数据库表，还是创建几个不同的表？我怀疑答案从“它取决于......”开始。
3. 两种方法估计的时间差是多少（1周，1天，150％更长等）

提前致谢。如果您有任何问题，请告诉我，以便我可以更新。

Answer 1

通过设计满足我的客户原始规格的数据库结构，但结果过于严格，我经常会遇到比我应该更多的事情，我总是会采用更灵活的方法，即使它需要更多时间建立。

Answer 2

我现在没有时间给出完整的答案，但我会把它扔掉：

• 基于您用来编码的开发工具来设计数据库通常是一个坏主意。
• 您想要通用到点。数据库中的表应该代表某些东西，并且可以使它过于通用。例如，一个名为“Things”的表可能过于通用。
• 可能会产生超出预期的约束。你的“桌子底座”带有“桌面木板”的例子对我来说没有意义，但是如果你可以扩展一个特定的例子，那么有人可能会帮助你。
• 最后，如果这是一个单个商店的小应用程序，那么您的设计对项目结果的影响要小于您为大量使用和不断更改的应用程序设计的影响。这可以追溯到上面的“过于通用”的评论。当系统的使用最小化且定义明确时，可以过度设计系统。我希望这是有道理的。

鉴于您在下面关于表格基础和树林的评论，您可以设置一个名为TableAttributes（或类似的东西）的表，每个可能的选项都是特定的表属性类型。然后，您可以强制执行任何给定选项仅用于通过外键应用的属性。

Answer 3

数据库架构设计存在过度抽象的趋势，因为变更成本可能很高。我自己，我喜欢具有相当描述性的表名。我经常将架构设计与OO设计等同起来。例如，您通常不会创建名为Thing的类，您可能将其称为产品，家具，物品，与您的业务相关的东西。

在您提供的架构中，有一个抽象（规范）和特定（TableType_LookupID）的混合。我倾向于均衡抽象级别，因此使用像：

这样的实体

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

Answer 4

以下是我的经验告诉我的事情：

1. 您更喜欢哪种数据库结构？毫无疑问，我会选择接近方法。选择最简单的设置。如果你增加复杂性，总是问问自己，它对客户有什么价值？
2. 什么是最佳做法？这确实取决于项目的规模和预期的变化率。作为一般规则，当您希望客户添加新类型时，通用表是值得的。例如，如果您的客户希望能够向表中添加新的“颜色”实体，则需要通用表。您无法预先预测他们将添加什么。
3. 这两种方法的估计时间差是多少？不了解您的业务，技能和环境，不可能提供valid estimate。您对编码充满信心的方法将花费最少的时间。在这里，我的猜测是方法＃1可以快5倍-50倍。通用表很难在数据库和客户端进行。

Answer 5

选项B ..

通用通常比具体更好。软件已经注定要失败或通过它的设计仅针对某一组任务来达到它的容量。如果你构建了一些通用的东西，那么如果用抽象的方法对其可能的位置进行实际分析，它就会减少。只要你远离过度抽象和抽象不足，它可能就是最佳点。

在这种情况下，可能会得出“更少代码更多”的格言，因为您不必再​​回来重新编写它。