Ronnie,

Glad to see it's all 'happening' now. i think your idea of the parent table is a good concept which will no doubt be 'bastradised' to the n'th degree to fit all scenarios (i mean this in a +ve sense as i know what can happen will happen!!).

if you normalise the tables and require to do multiple updates to keep everything in sync (and i think you should), then look to your old friend TransactionScope. This way, you can do 'seemingly' multiple insert/deletes within your BLL whilst keeping your heirarchical data integrity intact. this has a ripple down effect (i.e if you delete a parent id, then all hierarchies below will be similarly deleted, but only if the master record delete succeeds [remember, we're operating at the BLL level, so we can't use any database specific transactional logic]. if you need help on 'seeing' what this means, then just let me know but it's similar to the BLL.Hotel.Hotel DeleteHotel method (and all other 'DeleteObject' methods).

Other than that, i guess the only other area to be aware of (tho' it sounds like you're well aware of most scenarios) is the critical section where you consume the external data and make the updates to your own 'internal' data structure. In this scenario, many folk opt for a mapping structure in order to keep their own data discreet from the consumed data (i.e. a small two column table is created which maps the key field of the consumed data onto the internal key data table. I don't know if this is applicable/desirable or not - but is worth 'noting' (even if only academically).

ok - hope this hasn't raised more than it's settled. Looking fwd to seeing your initial implementation(s)....

[edit] another good example of the TransactionScope stuff is in the actual TBH code under BLL.Store.Order. look in particular at InsertOrder, tho UpdateOrder is a good one too ;)

jimi

http://www.originaltalent.com