каскадное обновление и удаление данных

← →
garry_c (2004-06-24 09:43) [0]

Здравствуйте я работаю на Delphi 2.0. Подскажите пожалуйста как организовать каскадное удаление записей в связных таблицах. В IBExpert-е при создании внешнего ключа можно поставить соотвествующие флажки, но тогда ключ вообще не создается. Пробовал прописывать вручную через SQL - тоже эффект.

← →
Курдль © (2004-06-24 09:46) [1]

Лучший вариант - вручную. Т.е. delete - команда на удаление подчиненных записей, потом - на удаление ключевой.

ЗЫ: А откуда такой раритет: Delphi 2.0? :)

← →
Johnmen © (2004-06-24 09:47) [2]

>...тогда ключ вообще не создается.

Значит что-то не так у тебя...

>Пробовал прописывать вручную через SQL - тоже эффект.

Значит пробовал не так...

← →
Соловьев © (2004-06-24 09:49) [3]

> Пробовал прописывать вручную через SQL - тоже эффект.

Какая ошибка?

> Лучший вариант - вручную.

триггер наверное имел автор совета.
ИМХО, лучше использовать ситемные трггеры.

← →
Курдль © (2004-06-24 09:54) [4]

> триггер наверное имел автор совета.
> ИМХО, лучше использовать ситемные трггеры.

Я имел в виду удаление вообще на клиенте т.к. речь велась о связанных таблицах, а не о древовидных структурах. А для последних и вправду лучше триггер, причем собственный, а не стстемный (он может учитывать особенности бизнес-процессов, заложенных в БД).

← →
Соловьев © (2004-06-24 10:00) [5]

> Я имел в виду удаление вообще на клиенте т.к. речь велась
> о связанных таблицах, а не о древовидных структурах

не обязательно связаные таблицы это древовидные.

> Я имел в виду удаление вообще на клиенте

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

← →
Курдль © (2004-06-24 10:10) [6]

> Соловьев © (24.06.04 10:00) [5]
> > Я имел в виду удаление вообще на клиенте
> а вот это уже не надо, так как противречит бизнес-логике.

Это с какого перепугу? Это не противоречит даже целостности данных, т.к. последние защищены механизмом внешних ключей!

← →
Соловьев © (2004-06-24 10:19) [7]

пишут 2 программера - один удалит, другой забыл...А если реализовать данную логику на уровне БД, то пофиг кто пишет.

← →
Курдль © (2004-06-24 10:24) [8]

> Соловьев © (24.06.04 10:19) [7]
> пишут 2 программера - один удалит, другой забыл...А если
> реализовать данную логику на уровне БД, то пофиг кто пишет.

Мало ли что программист забыл - это никакой логике не подчиняется. Главное, что логика хранения данных не будет нарушена.
Зато если даже такие пустяки возлагать на триггеры БД - переносимость программы на другую СУБД станет... непереносимой! :)

← →
Соловьев © (2004-06-24 10:28) [9]

все покажет практика :) И это не пустяки

← →
Sergey13 © (2004-06-24 10:36) [10]

2Курдль © (24.06.04 10:24) [8]
А зачем переносить на другую БД. Ты часто переносишь? ИМХО, такой перенос сродни полному перепроектированию всего и БД и прикладных прог.

Мои приоритеты такие (в порядке уменьшения хорошести 8-)
1.Стандартный констрейнт.
2.Тригер
3.Прикладная программа

2garry_c (24.06.04 09:43)
Ты наверное кнопочки не так нажимал, потому и не получилось. Или из-за древности инструментов проблемы. А мужики раздерутся скоро на теоретической почве. 8-)

← →
garry_c (2004-06-25 17:40) [11]

Спасибо всем! Я в самом деле в конце концов записал вручную два последовательных запроса. Хотя мне казалось, что существуют инструменты более высокого уровня.

← →
Курдль (2004-06-25 18:17) [12]

> Sergey13 © (24.06.04 10:36) [10]
> А зачем переносить на другую БД. Ты часто переносишь? ИМХО,
> такой перенос сродни полному перепроектированию всего и
> БД и прикладных прог.

Одного переноса хватило, чтобы раз и навсегда заречься писать бизнес-логику на сервере. А получается это элементарно - на старый рабочий проект нарисовывается новый клиент и говорит: "MS SQL - это Аццтой! Мы хотим на Оракле!".
Кроме того, одно дело - найти логическую ошибку (или чуток поменять логику) в цепочке из десятка-другого функций делфёвого исходника, а другое - когда это десяток разбавлен еще и десятком серверных процедур.

>garry_c (25.06.04 17:40) [11]

Они действительно существуют. И придуманы не просто так.
А рассуждения Курдль (25.06.04 18:17) [12] запросто приводят к нарушению целостности данных. Но видимо ему важнее "переносимость", чем целостность...:)

← →
Курдль (2004-06-25 22:21) [14]

> Johnmen © (25.06.04 22:09) [13]
> А рассуждения Курдль (25.06.04 18:17) [12] запросто приводят
> к нарушению целостности данных. Но видимо ему важнее "переносимость",
> чем целостность...:)

Интересно, из какой это части "рассуждения Курдль (25.06.04 18:17) [12]" следуют такие выводы? Там вроде ясно написано "...заречься писать бизнес-логику". Именно бизнес-логику, а не поддержку целостности.
В нашем конкретном случае (удаление записей из связанных таблиц) работа 2-мя запросами от клиента никак не нарушит целостности данных даже при выполнении элементарных правил РБД - создания внешних ключей для связанных таблиц.

>Курдль (25.06.04 22:21) [14]
>работа 2-мя запросами от клиента никак не нарушит целостности данных

Да ? Уверен ?
А я могу запросто 2-мя запросами порушить целостность. Если твоя б.-л. не учитывает ссылочную целостность...
Или ты считаешь, что ссылочная целостность не есть часть б.-л. ?
:)

← →
Курдль (2004-06-27 20:07) [16]

> Или ты считаешь, что ссылочная целостность не есть часть
> б.-л. ?

Если честно, не считаю. Не буду спорить "по понятиям", но я под бизнес-логикой имел в виду логику автоматизируемого процесса.
Повторяю, - достаточно защитить "связку" таблиц при помощи foreign key и тогда порушить целостность сможет только админ и только при помощи drop...

каскадное обновление и удаление данных Найти похожие ветки