Мастера DELPHI (документация, исходники, скачать)

Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG

« предыдущая ветвь | форум | следующая ветвь »

(Oracle) Как правильно написать триггер для автоприсвоения ID [MySQL]

Страницы: 1 2 3 4 5 6 >
ANB © (2005-09-27 14:12:00)
Попробовал сделать так :
create or replace trigger GT_Product_PK_TR before insert on GT_Product for each row declare begin if :New.ID is null then select GT_Product_SQ.Nextval into :New.ID from dual; end if; end GT_Product_PK_TR;
Получил проблему - если ID жестко задавать в инсертах, то сиквенс не мотается и потом лезут ошибки.
Переделал :
create or replace trigger GT_Product_PK_TR before insert on GT_Product for each row declare Cur_SQ number; begin if :New.ID is null then select GT_Product_SQ.Nextval into :New.ID from dual; else select GT_Product_Firm_SQ.Currval into Cur_SQ from dual; while (Cur_SQ < :New.ID) loop select GT_Product_Firm_SQ.Nextval into Cur_SQ from dual; end loop; end if; end GT_Product_PK_TR;
В таком варианте вроде, получше, но все равно можно нарваться на дублирование записей. Можно воткнуть еще проверку на существование уже сгенеренного ID и прокручивать сиквенс до нужного значения, но, во первых, полезут ошибки "таблица мутирует", во вторых это ничего особо не даст, т.к. если я умудрюсь в двух разных сессиях сгенерить один и тот же ID, то про триггер на них никак не поругается, так как записи еще не закоммичены, а проблема вылезет при коммите. Хотя, возможно, я не так понял механизм транзакций.

ANB (2005-09-30 11:58:00) [1]

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

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

Курдль (2005-09-30 11:10:00) [2]

> Danilka © (30.09.05 10:53) [108]

Не согласен по всем 3-м пунктам!

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

Если в БД хотят сделать общий идентификатор для разных таблиц, производят процесс наследования "inherit" от материнской таблицы. Если на одну запись в материнской таблице не могут ссылаться 2 записи в дочерних - взводят свойство наследования "mutually exclusive".

Пользу получения значения ID до исполнения DML я уже неоднократно приводил - чтобы заполнять связанные таблицы и при этом не держать транзакцию открытой (это важно при многопользовательском режиме).

ADO.NET не делает то-же самое, что ты написал в [67]. Но делает это на самом низком интерфейсном уровне и гарантирует от ошибок прикладного программирования.

Danilka (2005-09-30 10:53:00) [3]
[81] Fay © (29.09.05 16:38)
Примеров полезности генераторов/сиквенсов не привязанных к конкретной таблице, таки да, согласен, можно найти.
Триггеры before тоже полезны бывают.
А вот именно необходимость знать значение ид таблицы до инсерта я не могу придумать.

[106] Курдль © (30.09.05 10:14)
То-есть, фактически ADO.NET делает то-же самое, что я написал в [67].

kesha (2005-09-30 10:34:00) [4]

> Курдль © (30.09.05 10:14) [106]

Spasibo, potom obdumau.

Курдль (2005-09-30 10:14:00) [5]

> kesha © (29.09.05 18:25) [100]
> a esli sna4ala sochranil na lokal PK, a 4eres 2 dnja sbrosil v global DB

Я не понял, это вопрос? И в чем его суть?
Если просто держать заполненный датасэт (напоминаю - не TDataSet из Delphi, а System.Data.DataSet из ADO.NET, - для особо любознательных), который содержит в себе несколько таблиц со связанными данными, релэйшны и констрэйнты, - то ничего с ним не случится. Все "автоинкрементные" идентификаторы, внешние ключи и т.п. заполняются фиктивными данными (напр. для integer рекомендованы -1, -2, -3...). А в момент исполнения метода Update объекта DataAdapter, все они преобразуются в реальные значения из генераторов, последовательностей и т.п.

Если же Вас интересует, как сохранить данные из такого датасэта на 2 дня, чтобы потом их вставить в БД - есть метод DataSet.WriteXml(string filename);
который сохранит весть датасэт в XML, сохранив всю иерархию данных.

ANB (2005-09-30 10:03:00) [6]

> Sergey13 © (30.09.05 09:31) [104]
- а всего то просил посмотреть триггер.

Sergey13 (2005-09-30 09:31:00) [7]
Ну и бодягу вы тут развели. Даже для потрепаловки приличный объем.
А щас еще и холивар начнется.
8-)

ANB (2005-09-30 09:27:00) [8]

> Fay © (29.09.05 17:00) [98]
> 2 ANB © (29.09.05 16:58) [96]
> >> ???
> !!!
- чем оптимизатор MS SQL лучше ораклового ?

Fay (2005-09-29 19:18:00) [9]
B cmbIcJIE, "XOTb 4EPE3 DBA rODa" 8)

Fay (2005-09-29 19:17:00) [10]
2 kesha © (29.09.05 18:25) [100]

Хоть через а года

kesha (2005-09-29 18:25:00) [11]

> Курдль © (29.09.05 17:03) [99]

a esli sna4ala sochranil na lokal PK, a 4eres 2 dnja sbrosil v global DB

Курдль (2005-09-29 17:03:00) [12]

> ANB © (29.09.05 16:57) [95]
> - лучше не ругайся, а изучай грабли. От сумы и работы с
> MS SQL ни один программист не застрахован :)))

Честно говоря, я уже второй год, как перешел в основных проектах на вижуал кролика. Так что эти проблемы совсем канули в лету. Ведь в ADO.NET о таких мелочах, как ID вообще не задумываешься: набил датасэт связанными таблицами и сбросил в базу. Он сам разрулит, кому-что подставить.

Fay (2005-09-29 17:00:00) [13]
2 ANB © (29.09.05 16:58) [96]
>> ???
!!!

Fay (2005-09-29 16:59:00) [14]
2 ANB © (29.09.05 16:56) [93]
1) А почему, собственно, "до" ?
2) GUID-ы экономить не пробовали ? 8)

ANB (2005-09-29 16:58:00) [15]

> Есть причины, которые позволяют мириться с некоторыми недостатками.
>
> Пожалуй главная (но не единственная, конечно) из них - оптимизатор
> MSSQL (vs Oraclevs FB).
???

Fay (2005-09-29 16:57:00) [16]
2 Курдль © (29.09.05 16:53) [92]

Есть причины, которые позволяют мириться с некоторыми недостатками.
Пожалуй главная (но не единственная, конечно) из них - оптимизатор MSSQL (vs Oracle vs FB).

ANB (2005-09-29 16:57:00) [17]

> Курдль © (29.09.05 16:53) [92]
- лучше не ругайся, а изучай грабли. От сумы и работы с MS SQL ни один программист не застрахован :)))

ANB (2005-09-29 16:56:00) [18]

> Я писал, зачем получать "до" в [66].
> Чтобы заполнить максимум данных на клиенте

Хм. Странно. Была у меня раз задачка, где я заполнял на клиенте настроечную таблицу, а потом пересылал пачку записей за одну транзакцию. Но мне не пришлось заранее доставать ID. Это некошерный подход, доставать ID до того, как юзер нажмет кнопку ОК.

Курдль (2005-09-29 16:53:00) [19]

> Fay © (29.09.05 16:46) [87]
>
> 2 Курдль © (29.09.05 16:41) [83]
> >> То ли SCOPE_IDENTITY, то ли нечто похожее!
> Ни в коем случае!!

А чего тогда молчат все апологеты MS SQL? 8-()
Это ж полная Ж! :-(

Курдль (2005-09-29 16:51:00) [20]

> - хоть я MS SQL и не люблю, но вот логика триггеров мне
> там больше понравилась. Во всяком случае, мутаций таблиц
> там не бывает.

Мутаций не бывает, т.к. он блокировщик, а не версионник! :)

> ANB © (29.09.05 16:45) [86]
> А зачем его получать до ? Плюс, ходят слухи, что таки в
> следующей версии генераторы появятся.

Я писал, зачем получать "до" в [66].
Чтобы заполнить максимум данных на клиенте, не держа при этом транзакцию открытой. Это корпоративный стандарт! Никаких "прокруток", никаких "max(ID)" и т.п. Только заранее получить, и пользовать.

Страницы: 1 2 3 4 5 6 >

Наверх

	« предыдущая ветвь \| форум \| следующая ветвь »