Flights should have a foreign key constraint back to useraircraft to ensure that every aircraft used in a flight is in that user's aircraft list. We currently enforce this in code, should enforce it at the database level as well.
Need to test things like account deletion, aircraft merging/migration, etc. to ensure that none of these happen out of order in the code.
I don't think this will improve performance all that much, but it should obviate the need for the missing user aircraft check in AdminAircraft (and will allow for a significantly faster orphaned aircraft check (because we could then remove the left join on the flights table - quick test suggests this speeds that query up from about 20s to about 5s).
NOTE: adding the key below is SLOW, but it doesn't appear to impact the site.
ALTER TABLE logbook.flights
ADD CONSTRAINT fkuseraircraft
FOREIGN KEY (idaircraft , username)
REFERENCES logbook.useraircraft (idAircraft , userName)
ON DELETE RESTRICT
ON UPDATE RESTRICT;
Flights should have a foreign key constraint back to useraircraft to ensure that every aircraft used in a flight is in that user's aircraft list. We currently enforce this in code, should enforce it at the database level as well.
Need to test things like account deletion, aircraft merging/migration, etc. to ensure that none of these happen out of order in the code.
I don't think this will improve performance all that much, but it should obviate the need for the missing user aircraft check in AdminAircraft (and will allow for a significantly faster orphaned aircraft check (because we could then remove the left join on the flights table - quick test suggests this speeds that query up from about 20s to about 5s).
NOTE: adding the key below is SLOW, but it doesn't appear to impact the site.
ALTER TABLE
logbook
.flights
ADD CONSTRAINTfkuseraircraft
FOREIGN KEY (idaircraft
,username
) REFERENCESlogbook
.useraircraft
(idAircraft
,userName
) ON DELETE RESTRICT ON UPDATE RESTRICT;