使用一个字段还是一个全新的表？答案

【问题标题】：Use a field or a whole new table?使用一个字段还是一个全新的表？
【发布时间】：2011-06-09 22:13:48
【问题描述】：

在以下两种数据库布局之间进行选择时，我真的可以使用一些见解。

Layout #1          | Layout #2  
                   |  
CUSTOMERS          | CUSTOMERS  
 id int pk         |  id int pk  
 info char         |  info char  
                   |  
ORDERS             | ORDERS  
 id int pk         |  id int pk  
 customerid int fk |  customerid int fk  
 date timedate     |  date timedate  
                   |  
DETAILS            | INVOICES  
 id int pk         |  id int pk  
 orderid int fk    |  orderid int fk  
 date timedate     |  date timedate  
 description char  |  
 amount real       | DETAILS  
 period int        |  id int pk  
                   |  invoiceid int fk  
                   |  date timedate  
                   |  description char  
                   |  amount real

这是针对小型企业（独资经营者）的计费应用程序。第一个布局没有单独的发票表格，而是依赖于 DETAILS 中的字段“期间”作为开票周期编号。第二种布局引入了一个专门用于发票的表格。

具体来说，在这个应用程序中，您会在什么时候看到 Layout #1 被破坏，或者随着数据量的增加，什么样的事情会变得越来越难？在布局#2 的情况下，增加的灵活性/复杂性在实际中意味着什么？对 30-60-90 老化有何影响？我相信这在某个时候是必要的。

更一般地说，这似乎是您是否通过表中的字段或全新表中的字段跟踪/控制某些东西的一般情况，但这并不是真正的规范化问题，是吗？您通常如何做出选择？

【问题讨论】：

我认为您最好为您的客户服务，建议他们购买 Quickbooks 的副本，而不是为他们编写数据库应用程序。
@Catcall 谢谢，但这只是一个练习应用程序。没有客户。我看过你的一些帖子，你似乎知道你的东西。如果您能饶恕它们，我将不胜感激您对编程问题的看法。 :)

标签： database database-design invoice

【解决方案1】：

鉴于之前的 cmets，这就是我的处理方式：

CUSTOMERS
  id int pk
  info char

CASES
  id int pk
  customerid int fk
  dateOpened datetime
  dateClosed datetime
  status int <- open, closed, final billed, etc.
  BillPeriod int <- here is where you determine how often to bill the client.
  BillStartDate datetime <- date that billings should start on.

BILLING
  billingid int pk
  caseid int fk
  userid int fk <- id of person who is charging to this case. i.e. the lawyer.
  invoicedetailid fk <- nullable, this will make it easier to determine if this particular item has been invoiced or not.
  amount money
  billdate datetime
  billingcode int fk <- associate with some type of billing code table so you know what this is: time, materials, etc.
  description char


INVOICES
  invoiceid int pk
  customerid int FK
  invoicedate datetime
  amount money <- sum of all invoice details
  status int <- paid, unpaid, collection, etc..
  discount money <- sum of all invoice details discounts
  invoicetotal <- usually amount - discount.

INVOICEDETAILS
  invoicedetailid int PK
  invoiceid int FK
  billingid int FK
  discount money <- amount of a discount, if any

============

在上面您打开一个“案例”并将其与客户相关联。一个或多个人会持续将 Billings 应用到案例中。

一旦账单开始日期和期间的组合已经过去，系统将创建一个新的发票，其中包含从账单表中复制的详细信息。它应该根据那些尚未计费的详细信息来执行此操作。开具发票后，您应该锁定帐单记录以防将来更改。

如果您需要不同的触发器，您可能需要将“BillPeriod”更改为其他类型的字段。例如，期间只是创建发票的一个“触发器”。

其中可能包括在您达到一定金额时发送发票。这可以在客户或案例级别进行配置。另一种选择是限制支出。例如，在案例级别设置上限值，以防止账单超过上限；或至少导致向相关方发送警报。

【讨论】：

谢谢，克里斯，我很抱歉迟到接受。很好的答案！

【解决方案2】：

我不完全确定为什么将“句点”附加到项目而不是订单本身。布局#1 似乎暗示您可以拥有一个由“详细信息”组成的开放“订单”，这些“详细信息”可能会在几年内被添加和支付。这似乎是非常错误的，应该让会计成为一场噩梦。布局 #2 也好不到哪里去。

一般而言，订单由具有购买或合同日期的单笔交易组成。该事务可能包含多个详细项目，但它仍然是一个事务。它代表买卖双方在某个时间点达成的单一协议。如果购买了新商品，则会创建一个新订单……考虑到这一点，这两种表结构都不起作用。

关于发票。一个订单可能附有一张或多张发票。发票的目标是针对它们应用付款。对于小额交易，发票和订单之间存在一对一的关系。

在较大的交易中，您可能会将多张发票应用于一个订单。例如，如果您签订了“3 次轻松付款 199.99 美元...”的合同。在这种情况下，您将有 3 张发票，每张 199.99 美元应用于一个总金额为 599.97 美元的订单；并且每个都在不同的时间段到期。

Invoice 表应至少包含 Order Id、Invoice Number、Invoice Date、Invoiced Amount、Date Date、Transaction Id（对于信用卡）、Check Number（明显）、Amount Received 和 Date Received 字段。

如果您想了解并支持更多现实世界，那么您还需要一个 Payments 表，其中存储了发票编号、收到（或退款）金额、收到日期、交易 ID 和支票号码。如果您走这条路线，请从 Invoice 表中删除这些字段。

现在，如果您需要支持经常性费用（例如，互联网托管），那么您将拥有一个名为“Contracts”和“ContractDetails”或类似名称的不同表格。这些表将存储合同详细信息（类似于订单和订单详细信息，但包括开始日期、结束日期和重复周期）。当达到下一个计费周期时，详细信息将用于创建订单并生成相应的发票..

【讨论】：

谢谢，我会消化您的回答，但让我澄清一下，这不是一次交易中一次购买六件商品的零售类型。我试图使示例通用，但它是合法的计费，并且命令实际上是法律案件，可能会拖延多年。尽管如此，即使案件尚未结束，时间和费用通常也会按月计费。 “发票”仅针对当前活动，可以通过使用期间字段或将明细行直接关联到发票记录来提取。
PS 我认为酒店应用程序的情况也是如此，客人入住并随着时间的推移产生费用。超出信用额度的客人会被要求支付余额，但“账户”是从入住到退房的一系列费用和付款。
非常有趣的答案，非常有帮助！只是一个简单的问题，发票表中的“发票金额”是什么？这是订单表中订单成本的总和吗？如果不是这种情况，那么不应该将订单的总成本存储在发票表中吗？同样在发票表中是否应包含状态字段？比如到期、已付、未付、已取消？
@user622378：发票金额可能是订单表中的总计，也可能只是其中的一部分。这是为了支持单个订单的多个发票。是的，发票表应该有一个状态字段。

【解决方案3】：

由于您是在进行合法结算，我建议您花一些时间查看Sage Timeslips 的功能。律师的行为不像其他人；律师会计软件的行为与其他会计软件不同。这是企业的本质。

他们有 30 天的免费试用期，您可能可以从帮助文件和文档中学到很多东西。

此外，从用户界面逆向工程数据库设计是一种很好的做法。

【讨论】：