Подтвердите, прежде чем удалят/обновят в Studio управления SQL?

Я предложил бы, чтобы Вы всегда писали оператор SELECT с оператором Where сначала и выполнять его для фактического наблюдения то, что строки будут команда DELETE удалять. Затем просто выполнитесь, УДАЛЯЮТ с тем же оператором Where. То же касается ОБНОВЛЕНИЙ.

Под Инструментами> Опции> Выполнение запросов> SQL Server> ANSI, можно включить опцию Implicit Transactions, что означает, что Вы не должны явно включать команду Begin Transaction.

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

Можно привести лошадь орошать...

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

Попытайтесь использовать a BEGIN TRANSACTION перед выполнением Вашего DELETE оператор.

Затем можно принять решение COMMIT или ROLLBACK то же.

В 2005 SSMS можно включить эту опцию под Tools|Options|Query Execution|SQL Server|ANSI... проверяют SET IMPLICIT_TRANSACTIONS. Это потребует, чтобы фиксация влияла на обновление/запросы на удаление для будущих соединений.

Для текущего запроса перейдите к Query|Query Options|Execution|ANSI и установите тот же флажок.

Эта страница также имеет инструкции на 2000 SSMS, если, именно это Вы используете.

Как другие указали, это не обратится к первопричине: почти столь же легко вставить ФИКСАЦИЮ в конце каждого нового запроса, который Вы создаете, как это должно исчерпать запрос во-первых.

Именно поэтому я полагаю, что Вы всегда должны:

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

2 Выбора данные перед удалением

3 Экранных разработчика, использующие интервью и процесс оценки результатов деятельности :)

4 Основных оценки результатов деятельности, на сколько таблиц базы данных они не удаляют

5 производственных данных Обработки, как будто это было ядовито и очень бояться

Во-первых, это - то, для чего контрольные таблицы. Если Вы знаете, кто удалил все записи, можно или ограничить их полномочия базы данных или иметь дело с ними с точки зрения производительности. Последний человек, который сделал это в моем офисе, в настоящее время находится на испытательном сроке. Если она сделает это снова, то она будет отпущена. У Вас есть обязанности, если у Вас есть доступ к производственным данным и удостоверяясь, чтобы Вы не наносили ущерба, один из них. Это - проблема производительности так же как техническая проблема. Вы никогда не будете находить способ препятствовать тому, чтобы люди делали немые ошибки (база данных не имеет никакого способа знать, имели ли Вы в виду, удаляют таблицу a или удаляют таблицу a, где идентификатор = 100 и подтверждение будет поражен автоматически большинством людей). Можно только попытаться уменьшить их путем проверки людей, которые работают, этот код ответственны и путем помещения в политики места помочь им помнить, что сделать. Должны быть уволены сотрудники, у которых есть шаблон поведения безответственно с Вашими busness данными (particulaly после того, как им дали предупреждение).

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

Пример удаляет со встроенным выбором

delete a
--select a.* from 
from table1 a 
join table 2 b on a.id = b.id
where b.somefield = 'test'

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

По большей части производственные данные не должны быть изменены на лету. Необходимо написать сценарий изменения и проверить его на dev сначала. Затем на напоминании, все, что необходимо сделать, запущено скрипт без изменений вместо того, чтобы выделить и выполнить маленькие кусочки по одному. Теперь реальный мир inthe, это не всегда возможно как иногда, Вы фиксируете что-то поврежденное только на напоминании, которое должно быть зафиксировано теперь (например, когда ни один из Ваших клиентов не может войти в систему, потому что критические данные были удалены). В случае как это у Вас не может быть роскоши репродуцирования проблемы сначала на dev и затем записи фиксации. Когда у Вас есть эти типы проблем, Вы, возможно, должны зафиксировать непосредственно на напоминании, и Вы должны иметь только dbas или аналитики базы данных, или менеджеры конфигурации или другие, которые обычно ответственны за данные по напоминанию, делают фиксацию не разработчик. У разработчиков в целом не должно быть доступа к напоминанию.

Поставьте свой лучший Trogdor и Burninate, пока они не будут учиться вставлять оператор Where.

Лучший совет состоит в том, чтобы получить muckety-навозы, которые слоняются без дела в базе данных для использования транзакций при тестировании. Это имеет большое значение для предотвращения моментов "возгласов". Протест состоит в том, что теперь необходимо сказать им ФИКСИРОВАТЬ или ОТКАТЫВАТЬ, потому что наверняка они собираются запереть DB, по крайней мере, однажды.

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

Вероятно, единственное решение будет состоять в том, чтобы заменить кого-то кем-то еще ;). Иначе они будут всегда находить свое обходное решение

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

Разве там путь не состоит в том, чтобы дать пользователям результаты, в которых они нуждаются, не обеспечивая необработанный доступ к SQL? Если у Вас, по крайней мере, было отдельное поле записи для того, "ГДЕ", Вы могли принять значение по умолчанию оно к "ГДЕ 1 = 0" или что-то.

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

Другая ужасная опция состоит в том, чтобы создать триггер, чтобы записать, что все УДАЛЯЕТ (возможно, по некоторому минимальному количеству записей) к таблице журнала.

Заблокируйте его вниз:

REVOKE удалите права на всех своих таблицах.

Вставьте контрольный триггер и контролируйте таблицу.

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