When OrderDetails is Zero

Questions about the MySQL, PostgreSQL, and most other databases, as well as using it with PHP can be asked here.

Moderator: General Moderators

Post Reply
justbob3377
Forum Newbie
Posts: 4
Joined: Sat Jul 19, 2008 7:39 am

When OrderDetails is Zero

Post by justbob3377 »

Here is something I've been pining over...

Let's say you have a database with an Expense and ExpenseDetail table, respectively.

And, let's say that there are two types of data entry forms:

Form #1: Expense-level only
Form #2: Expense-level + ExpenseDetail-level

For most things (e.g. Groceries, Retail Purchases, etc), you would want to use Form #1 because you likely purchase many "Items" for a given trip to the store (i.e. "Expense").

But, for some "one-off" things (e.g. Haircut, Shoe Shine, Gas Pump Receipt) you could use Form #2 to streamline data-entry.

(Why enter an ExpenseDetail for a Haircut when you only ever get one Haircut at a time - unless you have multiple heads!!) :p


Now for the question...


While such a design wouldn't break any Data Modeling Rules - as far as I know - it could cause conflicts when you query data!!

For instance, if you have a total of 10 purchases, and all 10 have Expense-level data, but only 6 have Detail-level data, then if you queried table ExpenseDetail to find "Total Expenditures" you would get incorrect results.

(If you queried "Total Purchase Amount" in table Expense, however, you would "catch" all 10 purchases and find "Total Expenditures".)


Is this a problem?

Can a person just be mindful of this when you create queries/reports, or is this a "Design Flaw"??



Just Bob
User avatar
califdon
Jack of Zircons
Posts: 4484
Joined: Thu Nov 09, 2006 8:30 pm
Location: California, USA

Re: When OrderDetails is Zero

Post by califdon »

justbob3377 wrote:While such a design wouldn't break any Data Modeling Rules - as far as I know - it could cause conflicts when you query data!!
On the contrary, it does violate schema design rules. You're dividing an entity (the incurring of an expense) across two tables. If you will think of it purely in terms of entities I think you will see that this is so. Define your entities and let them tell you what should go into the tables. If you do that properly, you can decide later how to display them or create data entry forms. If your thinking begins with the forms, you are very likely to be led off-track.

At first glance, I would think that the applicable entities are Expenditures and Categories and perhaps subCategories. It could look something like this:

Code: Select all

[b]tblExpenditures[/b]:
    ExpID  (PK)
    ExpDate
    CatID  (FK)
    ...
 
[b]tblCategories[/b]:
    CatID  (PK)
    ParentID  (FK)
    Category
If a category is a top-level category, it would have a Zero for ParentID, if it is a subcategory, it would have the CatID of its next higher level in ParentID. Expenses could be classified into either categories or subcategories. You should be able to have a single data entry form with a dropdown list of categories, whether they are top level or subcategories.
justbob3377
Forum Newbie
Posts: 4
Joined: Sat Jul 19, 2008 7:39 am

Re: When OrderDetails is Zero

Post by justbob3377 »

califdon wrote:
justbob3377 wrote:While such a design wouldn't break any Data Modeling Rules - as far as I know - it could cause conflicts when you query data!!
On the contrary, it does violate schema design rules. You're dividing an entity (the incurring of an expense) across two tables.
You lost me here, friend?!

This is a parallel to the classic Order/OrderDetails classroom example.

I go to Target and buy a CD, Scotch Tape, Toothpaste, and 5 T-Shirts.

There is one Expense (i.e. Receipt/Order/Invoice) and there are many (8 actually) ExpenseDetails (i.e. CD, Scotch Tape, Toothpaste, and 5 T-Shirts).

** There is nothing to debate on this point, as it is "old as the hills" in terms of problem and solution. **

What I was talking about is...

I then go to SuperCuts and get a Haircut.

There is still one Expense (i.e. Receipt/Order/Invoice), but I am debating if there needs to be any ExpenseDetails (i.e. the same Haircut). It is a "one-off" deal.

Having...

ExpenseID = 2
ExpenseDate = 7/20/08
---------------------------
Description = "Haircut"
UnitPrice = $20
Quantity = 1
ExtendedPrice = $20
---------------------------
TotalSale = $20

seems like overkill for this "one off" transaction, when you could just have...

ExpenseID = 2
ExpenseDate = 7/20/08
---------------------------
---------------------------
TotalSale = $20

califdon wrote: If you will think of it purely in terms of entities I think you will see that this is so. Define your entities and let them tell you what should go into the tables. If you do that properly, you can decide later how to display them or create data entry forms. If your thinking begins with the forms, you are very likely to be led off-track.

At first glance, I would think that the applicable entities are Expenditures and Categories and perhaps subCategories. It could look something like this:

Code: Select all

[b]tblExpenditures[/b]:
    ExpID  (PK)
    ExpDate
    CatID  (FK)
    ...
 
[b]tblCategories[/b]:
    CatID  (PK)
    ParentID  (FK)
    Category
If a category is a top-level category, it would have a Zero for ParentID, if it is a subcategory, it would have the CatID of its next higher level in ParentID. Expenses could be classified into either categories or subcategories. You should be able to have a single data entry form with a dropdown list of categories, whether they are top level or subcategories.
You lost me from this point onward...


Just Bob
Post Reply