>>>>> "Martin" == Martin Ramsch <m.ramsch@stripped> writes:
Martin> On Fr, 1999-07-23 17:48:00 +0300, Sinisa Milivojevic wrote:
>> Vivek Khera writes:
Martin> [...]
>> > It sounds to me like saying "indexes are not supported since they slow
>> > down inserts".
Martin> [...]
>> No, yuo are saying exactly what I am saying.
Martin> Sinisa, you doesn't seem to see Vivek's point:
Martin> He's not talking about saving foreign key information, but not using
Martin> it at all (this in deed would be quite useless).
Martin> He's asking, what speed penalty you would have with tables that are
Martin> not involved in foreign keys (neither as source or target)?
Martin> For operations on such tables I dare to ask, too: why should INSERTs,
Martin> UPDATEs, DELETEs on such tables be slower than they are now - there
Martin> would be no need to do any additional checks (beside checking a tiny
Martin> flag if there are foreign keys involved or not).
Martin> So, if we would use the same database schemes as now--without foreign
Martin> keys--in theory there should be nearly no performance penalty.
Martin> The actual use of them might be cotly, but that's in exchange for
Martin> the gained functionalty.
Martin> I think, this is, what Vivek was talking about ...
Hi!
Basicly you are right; If you are not using foreign keys, then one
needs only to check some code in the table header if one need to do
some very fast extra checking on update, delete, create table,
alter table and drop table (basicly what we do now with GRANT on
tables and columns)
On the other hand, when one opens a new table, one would need to scan every
other table definition if someone else has a foreign key on it.
(A central foreign key table would fix this, but this would make it
harder to just copy tables as files between different databases)
I do have ideas to solve the above, I just have to find time to do it
or find a nice cloning machine.
Regards,
Monty
