> >>>> Incidentally, there's a trick for constraints. Execute each

constraint

> >>>> at row level. If it passes, fine. Otherwise track the row id. At
> >>>> commit time, re-evaluate the failures and act accordingly. This is
> >>>> probably significantly faster than performing all constraint checks

at

> >>>> commit time.
> >> M> Can't this fail for CHECK constraints that include some kind of
> >> M> check on multiple rows or existence of rows?
> >>
> >> and for FKs as well, not to mention self-reference for that matter.
> >>
> >> That's why you retry the failed ones at the end, as I understand.
> >
> > Hm, but a CHECK can be fine for a single row (while importing),
> > but not meet the constraint afterwards.
>
> How? We do not allow (or recommend?) accessing data from the other
> rows/tables in CHECK constraint...

It is allowed.

> But at the moment I have a problem understanding why we're discussing
> how to apply constraints _during: the load, since the original idea was
> to evaluate them _after_ the load (though I do not have profiling
> numbers from Vlad, some maybe indeed CHECK constrainsts can be evaluated
> during the load).

Right :-)

Martijn Tonies
Database Workbench - tool for InterBase, Firebird, MySQL, NexusDB, Oracle &
MS SQL Server
Upscene Productions
http://www.upscene.com
My thoughts:
http://blog.upscene.com/martijn/
Database development questions? Check the forum!
http://www.databasedevelopmentforum.com