Существует ли способ избежать, чтобы удаление строки на определенном использовании таблицы ограничило или инициировало?
Запустил CSV через сторонний csv to sql generator и решил проблему.
7 ответов
До осуществления этого в ограничении мое решение состояло бы в том, чтобы составить зависимую таблицу, таким образом, строки, на которые ссылаются, не могут быть удалены.
CREATE TABLE NoKillI (
id INT NOT NULL, FOREIGN KEY (id) REFERENCES Accounts(id) ON DELETE RESTRICT
);
INSERT INTO NoKillI (id) VALUES (0);
INSERT INTO NoKillI (id) VALUES (1);
INSERT INTO NoKillI (id) VALUES (2);
Теперь никто не может удалить строки в Accounts со значениями идентификаторов 0, 1, или 2, если они сначала не удаляют соответствующие строки в NoKillI. Можно ограничить удаления против зависимой таблицы с помощью полномочий SQL.
Вы делаете это путем записи триггера базы данных, который огни УДАЛЯЮТ для рассматриваемой таблицы. Все, что это должно сделать, выдают исключение, если идентификатор недопустим.
Если Вы не доверяете своим пользователям, добавьте безопасность.
- Добавьте хранимую процедуру, которая позволяет пользователям удалять строки, которые они хотят с, но запрещают, какой бы ни Вы хотите согласно своим собственным правилам. Затем отклоните, удаляют доступ на таблице и позволяют доступ на выполнение к sproc
- Добавьте вторичную таблицу со ссылками внешнего ключа, назовите таблицу MasterAccounts, или подобный, отклоните, обновляют/удаляют доступ к этой таблице и добавляют ссылки на него в рассматриваемые учетные записи, это будет препятствовать тому, чтобы любой удалил учетную запись, пока существует ссылка от этой таблицы до него
- Добавьте триггер, как OrbMan предполагает
- Добавьте представление, где они могут удалить строки через, заставьте представление пропустить все те учетные записи, которые им не разрешают удалить, отклонить, удаляют доступ к основной таблице и позволяют, удаляют доступ к представлению
Однако если у Ваших пользователей есть доступ достаточно, чтобы говорить с Вашей базой данных через SQL, то Вы действительно просто напрашиваетесь на неприятности. Необходимо ограничить безопасность и только предоставить доступ к базе данных через приложение и установленные протоколы. Затем у Вас есть много опций избежать проблем как это.
Я использую следующий триггер:
CREATE TRIGGER [dbo].[mytable_trd] ON [dbo].[mytable]
WITH EXECUTE AS CALLER
INSTEAD OF DELETE
AS
BEGIN
SET NOCOUNT ON
DECLARE @tn varchar(255)
SELECT @tn = object_name(parent_obj)
FROM sysobjects
WHERE id = @@procid;
SET @tn = 'Deletes not allowed for this table: ' + @tn;
-- Add your code for checking the values from deleted
IF EXISTS(select * from deleted where mycolumn = 1)
RAISERROR (@tn, 16, 1)
END
GO
Вы уверены, что это верно, что Вы никогда не будете хотеть, чтобы кто-либо удалил эти строки? Даже самостоятельно, или dba? Или задания обслуживания DBMS?
Если это будут только некоторые пользователи, то Вам будет нужно что-то как пользовательская таблица с полномочиями, так, чтобы это могло быть запрошено в триггере для различения неавторизованных пользователей от авторизованных пользователей.
Решение, которое я предпочитаю, использует реляционную модель и ее правила целостности.
Для каждой записи в Tbl_Account это не может быть удалено, я включил бы запись Tbl_AccountMaster где Tbl_Account.id_Account внешний ключ. Tbl_AccountMaster не сделан доступным для обновления, кроме администратором базы данных. Никто больше не может затем удалить записи из Tbl_Account это связано с Tbl_AccountMaster.
Править: Я просто заметил, что та же идея была разработана здесь. Спасибо счет!
Вы могли попытаться фильтровать свои запросы при помощи функции, которая проверяет, чтобы удостовериться, что пользователь не пытается удалить Ваш основной счет.