Обновите значения в базе данных напрямую или удалите - добавьте их снова - PullRequest
1 голос
/ 07 декабря 2008

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

Это немного увеличивает нагрузку на систему, но из-за этого мы не столкнулись с проблемами производительности.

Всегда ли это лучше всего делать?

Ответы [ 6 ]

3 голосов
/ 07 декабря 2008

номер

Используйте инструкцию UPDATE.

Кроме того, если вы беспокоитесь о целостности, включите его в транзакцию:

BEGIN TRAN T1

-- This update is part of T1
UPDATE Table1 SET Col1='New Value' WHERE Col2 = @Id;

-- Time to commit your changes. 
-- If for any reason something fails, 
-- everything gets rolled back
COMMIT TRAN T1
2 голосов
/ 07 декабря 2008

номер

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

1 голос
/ 07 декабря 2008

Как получается, что все не корректно обновлено в противном случае?

0 голосов
/ 08 декабря 2008

Удаление-вставка является более дорогой операцией, чем обновление.

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

Также рассмотрите влияние на триггеры и ведение журнала. И вы должны предоставить права на вставку и удаление, если вы могли просто предоставлять привилегии на обновление.

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

0 голосов
/ 07 декабря 2008

Как и все остальные, используйте ОБНОВЛЕНИЕ.

Еще одна причина: если у вас есть CASCADE DELETE для каких-либо ограничений ссылочной целостности, DELETE, а затем INSERT, теряет подчиненные данные. Если у вас нет CASCADE DELETE, возможно, вы не сможете УДАЛИТЬ запись, поскольку на нее все еще ссылаются другие таблицы.

0 голосов
/ 07 декабря 2008

Под «базой данных» я полагаю, вы имеете в виду базу данных SQL. Опасность выполнения delete затем insert заключается в том, что, если вы не будете осторожны со своими транзакциями, они не атомарны. В промежутке между удалением строки и вставкой новой кто-то мог проскользнуть похожую строку, что привело к сбою insert в некоторых ограничениях. Это также пустая трата усилий, потому что есть update, как отмечает Дж. Холланд. Все это будет сделано в один выстрел. Поместить его в свою собственную транзакцию, вероятно, не нужно, поскольку обновления являются атомарными.

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...