ANN: Query A Dataset Beta Download

  • Thread starter Thread starter Adrian Moore
  • Start date Start date
Sahil said:
Okay I gotta rush somewhere so I'll reply quickly -

Why disable constraints when u have them. This is a conventional
database trick. If you disable constraints before a bulk data load,
you save some SERIOUS time in the entire load process. That is why.
Click to expand...

yeah duh, I know that ;) but the reason I mentioned was: if you do
that, you will see a constraint violation AFTER the complete load is
done. Perhaps you're loading 100 tables with thousands of rows and a
constraint violates somewhere in the beginning. You can then terminate
the transaction and fix it. If you re-apply the constraint AFTERWARDS,
your whole database is inconsistent and you'd better have some serious
backups ready.

If you don't want constraints to kick in when doing things with the
database, don't define them, otherwise, why bother? They're there for a
reason, compromising for that reason is equal to not defining them in
the first place.

For initial bulk loads, no problem. Though for every subsequential
load, i.e. there is already data in the db, you're a fool if you
disable constraints during load times.

That's why.:)

FB
- Sahil Malik [MVP]
Upcoming ADO.NET 2.0 book - http://tinyurl.com/9bync
----------------------------------------------------------------------
------


written >> in a plugin model architecture that allowed you to make
them as heavy >> or as light as you wanted them to be.
means >> adding is fast, and removing is a pig. 2.0 implements it as
a red >> black tree - ditto for DataRows.
impression >> >> about them - which in my mind is expressed by the
phrase "Little >> >> knowledge is a dangerous thing".dataset >> > with 1 datatable and no constraints, yes that's
efficient. The >> > point is what's it doing after 3 tables with a
lot of data are >> > added and the constraints set have to be checked
each time you add >> > a row. That's a whole different thing.basic >> > setup, which doesn't have a lot of bottlenecks. The main
issues >> > start when multiple tables with a lot of data are added
and you're >> > adding data which has to be verified through
constraints, that's a >> > whole different thing.
Click to expand...


--
 
For initial bulk loads, no problem. Though for every subsequential
load, i.e. there is already data in the db, you're a fool if you
disable constraints during load times.
Click to expand...

<--- That is when you'd use this trick in DBs (and of course you can
rollback). Ditto for datasets - the initial load is when you'd use it (your
rollback is to toss the database out the window :) ).

- Sahil Malik [MVP]
Upcoming ADO.NET 2.0 book - http://tinyurl.com/9bync
 
I agree with both of you. ;)
The approach I often recommend is to upload to a permanent "work"
table--which has no constraints. Next, run a SP that merges the data and
reports inconsistencies. This protects the data integrity and keeps
performance high as well...

--
____________________________________
William (Bill) Vaughn
Author, Mentor, Consultant
Microsoft MVP
www.betav.com/blog/billva
www.betav.com
www.sqlreportingservices.net
Please reply only to the newsgroup so that others can benefit.
This posting is provided "AS IS" with no warranties, and confers no rights.
__________________________________
 
Back
Top