Генерация номера заказа

← →
geg © (2004-03-30 16:55) [0]

На InterBase Было сделано GENERATOR->procedure->IBStoredProc = новый номер
А ка реализовать тоже самое на SQL server 2000

← →
Delirium © (2004-03-30 16:55) [1]

NewID()

← →
Fiend © (2004-03-30 17:22) [2]

а не проще ли указать что поле identity?
ибо для NEWID надо и специальный тип поля использовать

← →
geg © (2004-03-30 17:33) [3]

Проще но мне номер нужен сразу, что бы вставлять данные в другие таблицы. а поле identity просто как генератор добовляет к последнему +1 и все..

← →
bushmen © (2004-03-30 17:33) [4]

Добавляешь записи через хранимую процедуру, а потом возвращаешь через параметр номер заказа

← →
bushmen © (2004-03-30 17:34) [5]

>просто как генератор добовляет к последнему +1 и все..

Не такой он уж и простой. Все зависит от умения программиста! :)

← →
geg © (2004-03-30 17:37) [6]

Да через процедуру это идее нужно попробывать.

← →
Delirium © (2004-03-30 17:46) [7]

"а не проще ли указать что поле identity?" - если подходить к вопросу академично и в соответсвии с рекомендациями Microsoft, то GUID как раз то - что нужно, однако, мало кто стрит БД грамотно и потому, можно и Identity, хотя лучше - хранилище идентификаторов.

← →
Romkin © (2004-03-30 17:47) [8]

Для абстрагирования метода генерации уникальных идентификаторов для каждой записи можно вынести его в хранимую процедуру, которая будет возвращать ID новой записи. Это позволяет легко добавлять записи в подчиненную таблицу, не производя никаких дополнительных манипуляций. В дальнейшем вы можете возложить на эту процедуру, например, генерацию идентификаторов в заданном диапазоне, или обеспечить сквозную нумерацию. Для хранения идентификаторов проще всего иметь отдельную таблицу примерно следующего вида:

create table Seeds ( TableName varchar(30), --имя таблицы ID int, --ID последней вставленной записи в данную таблицу LowOffset int --нижняя граница диапазона ) go

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

insert into Seeds(TableName, ID, LowOffset, HiOffset) values("MyCoolTable", 0, 0, 1000000) go

Текст процедуры в простейшем случае будет выглядеть так:
create procedure CLIENT_ID @TableName varchar(30), @ID int output as update Seeds set ID = ID + 1, @ID = ID + LowOffset where TableName = @TableName go

При обновлении (update) таблицы накладывается блокировка изменения, которая не позволит другому клиенту выполнить эту же процедуру одновременно с первым. Помимо вышеперечисленного такой подход упрощает жизнь при необходимости репликации данных между филиалами. Тогда в каждом филиале настраивается свой диапазон, и первичные ключи гарантированно не будут пересекаться.

(c) http://rsdn.ru/article/db/midas_migration.xml

← →
bushmen © (2004-03-30 17:56) [9]

>первичные ключи гарантированно не будут пересекаться.

А это как сказать :) Потому что можно и затереть эту табличку и удалить запись

← →
Delirium © (2004-03-30 18:03) [10]

"затереть эту табличку и удалить запись" - то, что так подробно обрисовал Romkin и называется хранилище идентификаторов - фундаментальная часть любой серьёзной БД, так что улыбаться тут нечему.

Если не ошибаюсь, для identity настраивается приращение и откуда стартовать, так что для филиалов тоже подойдет. Можно, например, для одного филиала сделать четные, для другого нечетные. :))
А для вставок в подчиненные таблицы есть переменная @@identity, довольно удобно все это в мс-скуле сделано, правда я в нем новичек еще.

хе-хе, а ветка-то старая, что-то я ее поднял по ссылке зачем-то. :))

>Danilka ©
Если почитаете выше, то я и говорил о том, что зачем мучаться с созданием собственной процедуры генерации, если есть identity ?!

[13] bushmen © (31.03.04 16:07)
Читал :))
Просто, это, вроде, не особо восприняли, ссылаясь на вставку в другие таблицы. Плюс еще Romkin ссылку привел о фишке, котрая позволит при репликации, вот я и уточнил, что если сразу о репликации думать, то и штатные средства прокатят.

Генерация номера заказа Найти похожие ветки