Sales Order meets Purchase Order

[John Reid]

Hi,

I have a SalesOrder (SOTable) that is made up of many SaleItems (SItable).
Each SaleItem may or may not be made up of subparts (SSItable).
I have a Purchase Order (POtable) that needs to purchase the above items and
subitems.
The existing design stores the purchase order data for each item or sub item
in the SItable or SSItable respectively.
The business needs to make changes to the items on every Purchase Order.
This part is running stoo slowly and the queries underlying it are complex.
(maintenance is time consuming)
So, should the design be changed and to what? I thought of saying each
Purchase Order is made up of Purchase items and each Purchase Item is
connected to either the SItable or the SSItable.

salud

John

 

[Yuan Shao]

Hi John,

Thanks for your post. According to your description, I understand that this
is a database design problem. If I have misunderstood, please feel free to
let me know. Based on my experience, this kind of issue is generally
consultant and hard to make a decision. I searched the following related
articles for you.

289533 Where to Find Information About Designing a Database in Access
http://support.microsoft.com/?id=289533

283878 Database Normalization Basics
http://support.microsoft.com/?id=283878

283698 ACC2002: "Understanding Relational Database Design" Document
Available
http://support.microsoft.com/?id=283698

Also, if you want us to help you design this Access database in detail, due
to the complexity of this issue, it would be best to contact Microsoft
Product Support Services via telephone so that a dedicated Support
Professional can assist with your request. To obtain the phone numbers for
specific technology request please take a look at the web site listed below.
http://support.microsoft.com/default.aspx?scid=fh;EN-US;PHONENUMBERS

Thanks for using MSDN newsgroup.

Regards,

Michael Shao
Microsoft Online Partner Support
Get Secure! - www.microsoft.com/security
This posting is provided "as is" with no warranties and confers no rights.