Hello. The problem is actually in the title. There are three labels, with a 1 to many dependency:
apps.id
Ver─versions.app_id
T─translations.app_id

When rows from the bottom two tables are added or removed, the entry in the corresponding field of the apps table changes.
trigger (for example, translations after delete )

BEGIN UPDATE apps SET translations_count = translations_count - 1 WHERE apps.id = OLD.app_id LIMIT 1; END

trigger ( apps before delete )

 BEGIN DELETE FROM app_info_translations WHERE app_info_translations.app_id = OLD.id; DELETE FROM app_versions WHERE app_versions.app_id = OLD.id; END

When I delete a record from apps, the trigger deletes the records from the dependent tables, which in turn try to modify this same record in apps (and then an error occurs).

Question : how to rebuild the base, leaving the same functionality, but get rid of the error? Those. with the ability to delete the entry from the apps

ps triggers are added to store statistics in the records of the apps table, instead of constantly selecting different information from a heap of tables.

  • one
    And if the trigger on the update also do before. he will then try to work out when the records in the upper table will be gone and there will be nothing to update. although xs of course. And you can try to remove the trigger for deletion from child tables and instead foraign keys in the child tables on delete cascade - Mike
  • but on delete cascade triggers do not run. Although in principle it is logical that when deleting, both the row and all dependencies in other tables will not matter. - Newbie127

1 answer 1

Thanks Mike for the tip. T.K. Almost all the "statistical" data about the related records of other tables is stored in the row to be deleted from the apps - it is logical to delete them not by a trigger, with the data changed "manually" but simply on delete cascade.