Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations gkittelson on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Ordering system data model

Status
Not open for further replies.

AppDev76

Programmer
Jun 8, 2004
65
US
Hi,
(sorry if I'm not in the right forum but I didn't find a form for database design)
I am designing an ordering system.
I need to be able to accept orders from different objects:
1.Person
2.Division (departments)
3.Job Accounts

In other words I can charge a purchase to a devision, person or a job.
My problem is that I can't decide which design is better:

1.Having a SuperType entity for orders and then one subtype for each obejct (OrderSubPerson,OrderSubDivision ...). This design will enable me to better manage data integrity, however the application developemnt will be harder.

2.Have one table for orders and in that table have a field for ObjectType and another field for the primary key of a specific record in that object. The problem then is that I can't create refrential integrity cause I have different data types in that field.

3.Create a new table called BillingToAccount (BillAcctID,BillAcctName,BillAcctTypeID) and subtype tables for each object:
tblBillAcctSubDivision(BillAcctID,DivisionID),tblb illAcctSubJob(BillAcctID,JobID)... .On my Orders table I will have a field for BillingAcctID that will be linked to the supertype billing account. This way I can manage the data integrity better but its more work for the application developers and also more load on the server since I have to create a billing account for every new entry in the Person,Job or Division table.
In addition to that I don't really have additional fields if an order is for a specific object so the subtype table will only hold the ID of that object.

Which design should I go for?
 

I would suggest you prototype these models and make sure you are meeting your requirements.

You have a purchase across three areas - could you simply have a table with a column that suggests where the order came from and where the order should be billed.

You have not stated if the "objects" need to know if the other has made an order.
 
Thank you for your reply.
My first solution was the same as you mentioned. I would have one column for where the order came form (person, division or job) and another for the primary key of person, division or job).
The problem then would be in managing the refrential integrity on the server, meaning that I am refering to different entities in the same field and how will I join them?

The solution that I have came accross is to have a super type table for Order and subtypes for OrderPerson,OrderDivision and OrderJob. The only pain is that three different forms need to be created on the application level for Inserts and updates.

What is your suggestion?

Again, this is my first purchasing system and your help would greatly be appreciated.

Thanks
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top