> There is no right or wrong answer to this as you are only building a small
> system with limited users.
>
> From a true modelling point of view then Scenario 2 is correct, but as you say
>that then makes your solution more complicated for a novice to use.

Okay, good, so at least I was on track!


> Scenario 1 will work and be simple to manage (apart from all the blank fields)

Valid point.


> So it is really up to you which you would be happiest with.
>
> Personally I would go with Scenario 2 - you will soon get the hang of how
> to piece it all together for your queries

Again, that is good to know that I wasn't off my rocker!

So, how would you do Scenario #2?

(Confession: I have spent most of my time using MS Access for projects like this. It is a decent quick-n-dirty DB tool, but one key thing it lacks is that Access's entire paradigm is built around "bound forms" where you are typing directly into the DB! This makes for shorter dev times, but actually create a thousand times more work in the long run. Point is I have limited experience developing in REAL databases...)

Let's say I have...

tblExpense
tblFuel
tblElectric
tblNaturalGas

which all contain "Expense-level" data, but where tblExpense is my "super-type" and the others are "sub-type" tables.

The user ("me") decides to enter a Gas Receipt.

The user goes to the "Expense Entry Form" and enters...

ExpenseID *system generated unique number
ExpenseDate
MerchantName
ServiceType
PumpNo
FuelType
TotalGallons
CostPerGallon
PaymentType
CCName
CCLast4
OrderTotal

and then clicks "Submit".


At this point, I would use an SQL INSERT statement to write the BLUE fields to tblExpense and the RED fields to tblExpenseDetail, right??

Is that the way it would work in a "normal" (i.e. non MS Access) database, especially if it was using Web Forms??


Just Bob