4 ms·
If I've understood correctly it's the foreign key column itself that isn't indexed by default. Deleting a record then requires a table scan to ensure that the c
by nickkell 5y ago
If I've understood correctly it's the foreign key column itself that isn't indexed by default. Deleting a record then requires a table scan to ensure that the constraint holds
- dan-robertson 5y agoExample: if you delete a record from the customers table, you want an index on the foreign key in the orders table to delete the corresponding entries. This also means the performance of the delete can have the unfortunate property where the small work of deleting a single row cascades into the work of deleting many rows.
- hinkley 5y agoWhich is why many elect to just ban deletes.
- rjzzleep 5y agoThat’s not the reason. The reason why people don’t delete is because nobody wants to be left with inconsistent data relations. Deleting a customer is more deleting their PII(our scrambling it) and leaving everything else in tact. Or in the case of Silicon Valley, leave everything in tact with a disabled flag and then spam you for the next decade or so.
- tremon 5y agoI don't buy that reason, because that inconsistency can be easily prevented with good schema hygiene (either ON DELETE NO ACTION or ON DELETE CASCADE). The problem is rather that in order to maintain consistent data relations, delete operations must be carefully designed and that part of the functional design is usually skipped because it's perceived as not important. Which is more or less what the GP says as well, deletes are not implemented because doing it properly requires proper design.