Употребление базы данных - хорошая или плохая практика?

Question

Нужно понять, является ли процедура Upsert (вставка или, если существует, затем обновление) плохой практикой в ​​программировании базы данных.Я работаю на SQL-сервере, если это имеет какое-либо отношение.

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

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

Ищем некоторые идеи / обсуждения, которые помогут мне прийти к выводу по этому вопросу.

Спасибо.

Обновление В ответ на комментарии:

Конкретный контекст, на который я ссылаюсь, - это создание или обновление представления данных сущности домена в базе данных.Скажем, например, объект «Персона» существует как представление таблицы «Персона» в базе данных.Мне просто нужен механизм для создания новой персоны или обновления существующей.Здесь у меня есть возможность создать хранимую процедуру Upsert или две отдельные хранимые процедуры - одну для обновления, а другую для вставки.

Какие-либо преимущества или недостатки в представлении anyones?

Answer 1

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

Вторая проблема связана с воскрешением удаленной записи.Скажем, процесс «A» запрашивает запись, процесс «B» удаляет ее, а затем процесс «A» отправляет изменение.Запись, которая должна была быть удалена, теперь возвращается в базу данных, а не передает исключение обратно в «A», которое было удалено.

Answer 2

Я люблю программировать специально.

Либо я создаю что-то, и в этом случае я бы хотел, чтобы вставка не удалась (дублировала), если там уже была сущность. Или я обновляю то, что, как я знаю, уже есть, и в этом случае я бы хотел, чтобы обновление завершилось неудачно (чего на самом деле не происходит).

С upsert / merge это становится нечетким. Разве я не преуспел? Я частично преуспел? Некоторые значения в строке являются моими (из вставки), а некоторые были там раньше?

Сказав это, Upserts полезны (именно поэтому они были реализованы с самого начала), и запретить их было бы просто глупо. Это похоже на запрет дорог, потому что преступники используют их, чтобы убежать от полицейских. Существует бесконечное количество случаев, когда упор является единственным разумным способом ведения дел. И любой, кто работал с синхронизацией данных между системами, знает это.

Answer 3

Зависит от того, что вы говорите.Данные?Ну, это определяется процессами манипулирования данными или?Если мне нужно вставить ИЛИ обновить, то мне нужно это сделать.если речь идет об объектах схемы, похоже.

Answer 4

Возражение в первом примере двух процессов - когда второй процесс «воскрешает» удаленную запись, добавляя новую с тем же ключом, - справедливо только в определенных случаях, которые могут возникнуть из-за плохой конструкции ИЛИ произойдет независимо от того, записала ли процедура «upsert» запись с идентичным ключом или две отдельные процедуры записали вставленную запись.

Если необходимо избегать идентичного ключа, во вставке используется автоматически увеличивающийся идентификационный ключ. Там, где идентичного ключа не нужно избегать, необходимо реализовать хороший дизайн базы данных, чтобы избежать создания «фантомных объединений». Например, в мире телекоммуникаций телефонные номера часто используются повторно и являются «уникальным» ключом. Они не могут быть первичным ключом, потому что человек № 2 может «наследовать» номер телефона, но, вероятно, не должен «наследовать» просроченный неоплаченный счет человека № 1 или историю звонков и т. Д. Таким образом, комбинация автоматического увеличения первичного ключа с датами обслуживания или другими уникальные идентификаторы будут использоваться в любой логике соединения для предотвращения неправильного объединения данных.