В базе данных SQLite лучше использовать tirggers для обработки изменений каскадных таблиц, или это лучше делать программно?

Question

Фон

У меня есть несколько проектов, в которых для данных используется БД SQLite. Данные, хранящиеся в базах данных, очевидно, хранятся в нескольких таблицах, связанных значениями ключ / внешний ключ.

Дело в том, что в этих базах данных, если что-то меняется на одну запись, мне приходится обновлять несколько других таблиц. Лучший пример с моей головы - удаление записи. Я должен убедиться, что все другие записи, относящиеся к удаляемой, также удалены. Теперь этот пример может быть решен с использованием значений ключа / внешнего ключа, я полагаю, но как насчет более сложных обновлений?

Сейчас я не профессиональный администратор БД, но я знаю, что в БД должна быть целостность данных, иначе все станет плохо.

Вопрос

Итак, мой вопрос. Я знаю, что у меня больше контроля при программном обновлении связанных таблиц, но за счет человеческих ошибок и времени. Я могу что-то пропустить или неправильно внедрить обновления таблиц, и это займет намного больше времени, чтобы кодировать в обновлениях. С другой стороны, я могу включить триггеры и позволить БД обрабатывать обновления других таблиц, но затем я теряю много контроля.

Так, какой из них лучше? Каждый из них лучше в разных ситуациях?

Answer 1

С другой стороны, я могу включить триггеры и позволить БД обрабатывать обновления других таблиц, но затем я теряю много контроля.

Какой контроль вы думаететы проигрываешь?Если целостность данных требует, чтобы «такое-и-такое обновление здесь требовало дополнительных обновлений там и там », вы не потеряете контроль, кодируя это втриггер.Вы централизуете управление и делегируете его в dbms, единственное программное обеспечение, которое может гарантировать, что каждое приложение соответствует этим требованиям.

Я знаю, что у меня больше контроля при программном обновлении связанных таблиц, но ценой человеческих ошибок и времени.Я могу что-то пропустить или неправильно внедрить обновления таблиц, и это займет намного больше времени для кодирования в обновлениях.

Вы думаете как программист, а не дизайнер баз данных.(Это наблюдение, а не критика.) Не думайте: «Я мог бы что-то упустить».Такое мышление действительно не вписывается в цель.

Вместо этого, когда у вас возникает искушение делегировать целостность данных коду приложения, подумайте: «Каждый программист и каждое новое или измененное приложение, которое обращается к этой базе данных с настоящего момента до конца времени, должно сделать ее совершенно правильной».

Теперь, если честно, это действительно звучит для вас хорошей идеей?

(В последней компании из списка Fortune 500, в которой я работал, программы были написаны как минимум в двух десяткахразные языки попали в свою базу данных OLTP.)