>>Hi,
>>
>>I'm designing a new system that tracks Authorizations for Services (AS) and Orders.
>>
>>Information about Authorizations for Services will be entered, and, if approved, corresponding order information will be entered. Authorizations for Services information includes, among other items, vendor and (internal) account information.
>>
>>Orders can be entered in other parts of the system, so they do not necessarily have an Authorization for Service associated with them. Order information also includes, among other items, vendor and (internal) account information (if the order is for an AS, the vendor and account are the same).
>>
>>So, I was thinking that I'd have the following tables and types of fields:
>>
>>AS table:
>> PK (primary key)
>> ...other fields...
>> iAccountVendor (foreign key to AccountVendor table)
>> ...other fields...
>>
>>Order table:
>> PK (primary key)
>> ...other fields...
>> iAccountVendor (foreign key to AccountVendor table)
>> ...other fields...
>>
>>AccountVendor table:
>> PK (primary key)
>> iVendor (forign key to vendor definition table)
>> iAccount (forign key to account definition table)
>>
>>Is this a good way to do it? any suggestions for an alternative that might be better?
>>
>>TIA for any input. J
>
>Jill,
>Your design looks right to me. As I understand there is a many-to-many relation between Vendors and Accounts. I might choose to have iVendor, iAccount fields directly in AS and Orders tables instead of using intermediate AccountVendor key.
>Cetin

Hi Cetin, thanks for responding.

Well, the vendor and account will always be the same for the AS and the Order, so instead of having to update them in 2 places, it seemed better to have an intermediate table...j