Ed Carp wrote:
> >Yes, but all DELETE/UPDATE without dependencies would also have to look
> into the dependencies table, and that's an extra overhead.
> Well, yes, but you'd gain integrity. :) There's no way to do it without
> having extra overhead.
> >Also I have a running application, which uses dependencies between two
> >They wouldn't be handeled this way. This would lead to do it myself on some
> >and let it do mysql on others. Not very transparent.
> If the table were global and database_name fields were added, it'd work.
> Also, you want to be able to turn it on and off.
That's a nice thought.
But I think the 'turning off' would be realised by having a flag.
The testing of the flag will also take time.
So this woun't prevent me from having overhead.
> >I think when stored procedures are out in mysql, you could do such things
> if you need it.
> >Till then be patient :)
> I'm scratching my head- what do stored procedures have to do with integrity?
> Triggers would help, because mysql could set up internal triggers to check
> the integrity itself - is this what you meant?
No, I meant stored procedures. You are right about triggers. Triggers can mainly be the
flag for turning integrity checks on/off you
I was thinking of a stored procedure which could be used to delete related rows from
tables. This way would prevent the extra
overhead for checking tables that don't have any related tables on deletion and you don't
need to maintain a relations table like
the one described by yourself.
Hope that cleared it a bit.