Распространено удаление в коде или базе данных?

Question

Я работаю над приложением для iPhone с несколькими связями данных (например, Автор -> Книги). Когда пользователь удаляет объект Author из приложения, у меня появляется несколько триггеров SQLite, которые запускаются при удалении, чтобы удалить все книги из базы данных, у которых внешний ключ соответствует первичному ключу Author.

Я также использую триггер для вставки некоторых данных при создании нового элемента.

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

Что скажете вы?

Answer 1

True. Используйте как можно больше встроенных возможностей базы данных. По крайней мере, попытайтесь начать так, и идите на компромисс, только когда вещи действительно требуют этого.

Answer 2

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

Основываясь на других ответах здесь, это кажется философским выбором. Вероятно, было бы неплохо использовать триггеры или код, но лучше быть последовательным. Поэтому не используйте триггеры для каскадного удаления в одной таблице, а затем код C для другой таблицы.

Поскольку вы пометили вопрос iphone, я думаю, что наиболее важным отличием будет относительная производительность кода C по сравнению с триггером. Вам, вероятно, придется кодировать оба и экспериментировать, чтобы определить разницу, если есть.

Еще одна вещь, которая приходит на ум - это то, что из всех ужасных историй, которые я читал на thedailywtf.com, примерно половина из них, похоже, связана с триггерами базы данных.

Answer 3

Мне нравится идея использования встроенной функциональности базы данных (я не знаком с тем, как она работает) ... но я бы волновался, вернусь ли я к коду через год, помню ли я, как он работал? (Учитывая, что код не прямо передо мной).

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

Answer 4

Я бы использовал функции базы данных для обеспечения целостности отношений, особенно в отношении обновлений / удалений. Есть случаи, когда я мог бы использовать триггер для вставки некоторых дополнительных данных (приходит на ум аудит), хотя я бы старался избегать этого и вставлять все данные из моего приложения. Однако, если вы выполняете несколько вставок, обязательно оберните их все в одну транзакцию, чтобы избежать частичной вставки, которая может привести к потере целостности отношений.

Answer 5

К сожалению, SQLite НЕ поддерживает каскад удаления и т. Д. Из документации по SQLite:

http://www.sqlite.org/omitted.html

Ограничения FOREIGN KEY анализируются, но не применяются. Однако эквивалентное применение ограничений может быть достигнуто с помощью триггеров. Дерево исходного кода SQLite содержит исходный код и документацию для программы на C, которая будет считывать базу данных SQLite, анализировать ограничения внешнего ключа и автоматически генерировать соответствующие триггеры.

Существует некоторая поддержка триггеров, но она не завершена. Отсутствующие подфункции включают триггеры FOR EACH STATEMENT (в настоящее время все триггеры должны быть FOR EACH ROW), триггеры INSTEAD OF для таблиц (в настоящее время триггеры INSTEAD OF разрешены только для представлений) и рекурсивные триггеры - триггеры, которые запускают сами.

Следовательно, единственный способ кодирования каскада удаления и т. Д. С использованием SQLite требует триггеров. С уважением,

Answer 6

Код идет в вашем приложении.

Триггеры кодовые. Функциональность идет в вашем приложении. Нет в базе данных.

Я думаю, что базы данных должны использоваться для данных, а не для обработки. Я думаю, что приложения должны использоваться для обработки, а не данных.

Особенности обработки базы данных просто мутят воду.