![]() |
| ||
|
|
Новости |
Поиск |
FAQ |
Статьи |
Книги |
Новости VCL
| | Форумы ЧАТ |
Орешник |
|
| |||
| |||
« предыдущая ветвь | форум | следующая ветвь »
Как поступить правильно, соблюдая каноны программирования? [D7, WinXP]
kyn66 © (2005-08-19 11:12:00)Уважаемые мастера, САБЖ. Есть таблица Таб1, в которой (после фильтра, к примеру) имеется 30 записей.
Каждая запись ессно имеет свой ID. У нее в подмастерьях имеется ешшо одна таблица Таб2, которая по ID
связана с Таб1. Мне нужно удалить все записи из Таб1 и ессно все подчиненные записи Таб2. Есть два варианта
удаления:
1) Я в цикле прохожу по всем записям Таб1 и через SQL-запрос удаляю все записи из Таб2, где есть связь по ID Таб1
while not Таб1.EOF do
begin
SQL.Add(Format('DELETE FROM %s WHERE OperID = :p1', [Tab2]));
Parameters[0].Value := Таб1.FieldByName('ID').Value;
ExecSQL;
SQL.Clear;
Таб1.Next;
end;
2) Я опять-же в цикле прохожу по Таб1, в некую переменную (S : TStrings) собираю все ID таблицы Таб1, затем SQL-запрос
выполняю тока 1 раз
SQL.Add(Format('DELETE FROM %s WHERE OperID IN (S)', [Tab2]));
ExecSQL;
И тот и другой способ отработают, но меня интересует как правильно нужно поступать?
alex_*** (2005-08-19 15:40:00) [1]у тебя какой сервер, в самом деле?
alex_*** (2005-08-19 15:39:00) [2]а что не понятно? условие можешь выкинуть, если не нужно
kyn66 (2005-08-19 14:48:00) [3]>> alex_*** (19.08.05 12:37) [8]
А что-то я не понял этой строки?
DELETE T2 FROM T2 INNER JOIN T1 ON T2.OrderID = T1.ID AND {условие}Не очепятка случаем?
afanasic (2005-08-19 14:35:00) [4]Согласен, что on delete cascade нужно правильно использовать, то пример Ega23 © никак не подходит - зачем тебе знать историю заказов несуществующего товара??? Если ты хочешь "удалить" товар, то есть, чтобы его не видел пользователь, то достаточно завести поле типа Boolean и проставлять признак, а удаленные потом не показывать... В этом случае у тебя сохраняется структурность и логичность базы, а все эти ручные удаления рано или поздно могут где-нибудь всплыть...
DiamondShark (2005-08-19 14:27:00) [5]
> kyn66 © (19.08.05 11:12)
А тип используемой СУБД нет желания огласить?
Val (2005-08-19 14:20:00) [6]Удалено модератором
Sergey13 (2005-08-19 14:14:00) [7]Удалено модератором
Val (2005-08-19 14:10:00) [8]Удалено модератором
Sergey13 (2005-08-19 13:56:00) [9]Удалено модератором
Ega23 (2005-08-19 13:55:00) [10]Удалено модератором
Val (2005-08-19 13:54:00) [11]Удалено модератором
Sergey13 (2005-08-19 13:51:00) [12]Удалено модератором
Val (2005-08-19 13:50:00) [13]>[9] afanasic (19.08.05 12:44)
Вроде анси это.
>All
Спор о каскадном удалении - ограничения против хп считаю глупым абсолютно - категория "Что лучше - ложка или вилка?".
Ega23 (2005-08-19 13:48:00) [14]например, объект - в одной таблице, а его свойства - по другим таблицам раскиданы
дропаю объект и не заморачиваюсь о свойствах
Это другое дело, тут я, пожалуй, соглашусь.
Но всё равно предпочитаю в хп сначала из таблицы свойств дропнуть, а потом уже сам объект.
Но это уже просто стиль.
К примеру, к меня в основном проекте нет ни одного триггера. И вообще, невозможность использовать хп вместо триггера в моей практике встретилось только один раз.
Leonid Troyanovsky (2005-08-19 13:30:00) [15]
> afanasic (19.08.05 12:55) [12]
> Для ликвидации ошибок программирования есть rollback и дамп...
>
Лучший метод ликвидации ошибок программирования -
ликвидация их носителей.
--
Regards, LVT.
Desdechado (2005-08-19 13:27:00) [16]2 Ega23
ну, на справочники я, например, on delete cascade не ставлю и не даю из них удалять, если есть зависимые записи
но на многие другие вещи это очень удобно
например, объект - в одной таблице, а его свойства - по другим таблицам раскиданы
дропаю объект и не заморачиваюсь о свойствах
Ega23 (2005-08-19 13:12:00) [17]2 Гаврила © (19.08.05 13:08) [14]
зависит от задачи, не так ли?
обрати внимание на для пользователяНИКОГДА не ставлю
Конечно зависит от задачи.
Но преимущество использования хп для этого ещё в том, что, например, после удаления ты можешь занести запись в лог (не transaction log, а свой). Можешь ещё сделать массу полезных вещей. Наложение же on delete cascade на constraint такой возможности не даёт.
Поэтому и считаю этот механизм вредным и развращающим разработчика.
Гаврила (2005-08-19 13:08:00) [18]
> [13] Ega23 ©
> НИКОГДА не ставлю каскадное удаление
зависит от задачи, не так ли?
Ega23 (2005-08-19 13:05:00) [19]Если ты таким образом проектируешь базу, то пользователь потом, удалив одну запись из справочной таблицы, грохнет все рабочие.
Представь стандартную ситуацию: Тип товара -> Товар -> Заказ
Удалив товар какого-либо типа ты рискуешь потерять историю твоих заказов.
Исходя из этого, для пользователя НИКОГДА не ставлю каскадное удаление. Пусть лучше exception получит. А потом, если так надо, удалит заказы, удалит все товары этого типа и только потом удалит тип товара.
А приведённый выше пример хп - этио не пользовательская хп, а системная. Пользователь до неё достучаться НИКОГДА не сможет. Только разработчик. А он уже знает, что такое удаление одного класса (для той хп).
afanasic (2005-08-19 12:55:00) [20]Для ликвидации ошибок программирования есть rollback и дамп...
А это правильный подход, сохраняющий целостность базы - записи во второстепенной таблице не имеют смысла без одной записи в главной, поэтому их просто необходимо удалить, чтобы не засо{заси}рать базу данных...