Question

I could really use some insights on choosing between the following two database layouts.

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  

This is a billing application for a small business, a sole proprietor. The first layout has no separate table for invoices, relying instead on the field ‘period’ in DETAILS for the billing cycle number. The second layout introduces a table specifically for invoices.

Specifically in this application, at what point do you see Layout #1 breaking, or what kind of things will get harder and harder as the amount of data increases? In the case of Layout #2, what does the added flexibility/complexity mean in practical terms? What are the implications for 30-60-90 aging? I’m sure that will be necessary at some point.

More generally, this seems to be a general case of whether you track/control something through a field in a table or a whole new table, yet it’s not really a normalization issue, is it? How do you generally make the choice?

Answer 1

Given the previous comments, this is how I would approach it:

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

===========

In the above you open a “case” and associate it with a customer. On an ongoing basis one or more people apply Billings to the case.

Once the combination of the bill start date and period have elapsed, then the system will create a new Invoice with Details copied from the Billing table. It should do this based on those details that have not already been billed. You should lock the billing record from future changes once it has been invoiced.

You might have to change “BillPeriod” to some other type of field if you need different triggers. For example, period is just one “trigger” to create an invoice.

One might include sending an invoice when you hit a certain dollar amount. This could be configured at the customer or case level. Another option is capping expenditures. For example putting a cap value at the case level which would prevent billings from going over the cap; or at the very least causing an alert to be sent to the relevant parties.