|
su.dbms.sql
- SU.DBMS.SQL ------------------------------------------------------------------
From : Ilya Zvyagin 2:5020/400 11 Apr 2001 10:28:08
To : All
Subject : Re: Дремина хитрость 2
--------------------------------------------------------------------------------
Tolik Gusin wrote in message <3AD313A3.92EB9A40@giac.dp.ua>...
>> или как ноpмальные люди - SP на вставку.
>Это можно легко сделать в случае One Master-One Detail, а вот в случае
>One Master-Many Detail
>этот фокус уже не пройдет.
Рассказывай ... Еще как пройдет.
>Далеко не всегда можно разделить ввод в MASTER и DETAIL на две фазы.
>И пример когда это сделать нельзя (или очень не желательно) я привел
>выше.
>Что ты тогда будешь делать ?
1) Клиентскую транзакцию ( из нескольких процедур, потом клиент будет
COMMIT-ить)
2) 2 процедуры - одна вставляет Master и одну запись Detail , другая -
просто одну запись Detail. Если конечно семантика позволяет. Hо я на
практике вообще никогда такого не встречал, чтобы в Detail в состоянии
проекта (т.е . того, что еще редактируеться ) требовалось бы обязательное
наличие записи/N записей ( если об этом речь ) - это всегда можно проверить
ПОЗЖЕ.
3) Самый "железный" вариант - т.н. "имитация транзакций".
Делаеться набор таблиц, порезанных по пользователям ( с @@spid в одной из
колонок ),
аналогичный по полям с редактируемыми таблицами. В процессе редактирования
данные вставляються в эти таблицы (без большой охватывающей транзакции).
По завершению редактирования вызываеться некая процедура типа
CommitMyChanges,
которая в одной транзакции проверяет данные (данного пользователя ) и
переносит
все в основные таблицы, если все хорошо.
Это позволяет избежать транзакций, управляемых клиентом (чего я лично очень
не
люблю ).
>И заодно спрощу и у тебя:
>Как ты поступаешь в случаях описаных мной выше ? Как ты реализуешь,
>работаешь со связками
>One Master-Many Detail в случяе который я описал ?
Я до сих пор честно говоря не понял, в чем же у тебя проблема.
Я думаю, в нежелании писать нестандартный код ( или лишний )
в Дельфи - все на связанных таблицах хочешь устроить.
--- ifmail v.2.15dev5
* Origin: FCT Saint-Petersburg (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
