SQL: возможна ли строка «Защита от записи»?

Question

Возможно, это глупый вопрос, но можно ли защитить строку данных в базе данных SQL Server от удаления или обновления без установки разрешений пользователя?

Это для строки данных по умолчанию, на которую можно ссылаться для значений по умолчанию?

Спасибо

Answer 1

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

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

Создайте таблицу основных таблиц tblMain с числовым первичным ключом. Для простоты я проверил это с помощью таблицы с одним столбцом intID и заполнил ее значениями 0,1 и 2.

Затем создайте вторую таблицу, tblGuard, с аналогичным числовым первичным ключом. Я добавил одну строку в эту таблицу, значение 1.

Теперь бит обратной логики. Создайте внешний ключ в таблице tblGuard , которая ссылается на таблицу tblMain

ALTER TABLE [dbo].[tblGuard] ADD 
    CONSTRAINT [FK_tblGuard_tblMain] FOREIGN KEY 
    (
        [intID]
    ) REFERENCES [dbo].[tblMain] (
        [intID]
    )

Ограничение будет гарантировать, что строка со значением 1 intID не может быть удалена из таблицы tblMain, поскольку ссылочная целостность таблицы tblGuard требует, чтобы значение 1 существовало в tblMain. Это работает с удаляет и усекает.

Answer 2

Один из возможных подходов, который я когда-то использовал, описан в моем блоге:

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

Answer 3

Вы можете создать триггер, который вызывает ошибку, если эта строка обновлена ​​или удалена.

Answer 4

Я говорю, делайте это "программно". Например, пусть строка с идентификатором 1 всегда будет строкой по умолчанию, затем добавьте ко всем запросам UPDATE или DELETE «WHERE id! = 1» или сделайте эквивалент на любом языке, который вы используете для написания своей логики (PHP, C, VB, и др.)

Answer 5

• Создайте вторую таблицу, в которой строки имеют те же уникальные идентификаторы, что и строки, которые вы пытаетесь защитить.

• Разрешите ВТОРОЙ стол, как вы хотите

• Добавить триггер в первой таблице, который будет удалять / обновлять обе таблицы, если во второй таблице существует совпадающая строка.

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

ПРИМЕЧАНИЕ. Отличие этого метода от других основных методов (использующих VIEW) состоит в том, что он позволяет легко поддерживать набор «фиксированных» строк в отличие от подхода VIEW и позволяет избежать различных проблем с производительностью, обычно связанных с представлениями.

Answer 6

Допустим, ваш MyTable находится на Первичном.

Поместите первую строку в новую таблицу MyTableReadOnly, переместите эту таблицу в свою собственную группу файлов и сделайте группу файлов доступной только для чтения.

Удалить первый ряд из MyTable

Теперь создайте представление, которое

SELECT Columns From MyTableNew
UNION
SELECT Columns From MyTable

Доступ ко всему через представление. Если вы хотите обновить или удалить из представления, вы можете сделать это на MyTable и игнорировать что-либо для MyTableNew. Если вы хотите работать с представлением, вы можете использовать триггеры INSTEAD-OF.