Top.Mail.Ru
Мастера DELPHI, Delphi programming community Титульная страница Поиск, карта сайта Написать письмо 
| Новости | Поиск | FAQ | Статьи | Книги | Новости VCL |
| Форумы ЧАТ | Орешник | KOL и MCK |
Форумы -» Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG

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

Автоматическая номерация документов [D7, MSSQL]


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

Ярослав ©   (2005-05-31 08:21:00) 

Подскажите как автоматически назначать номера документов, т.е. записям БД. Они могут состоять как только из цифр, так и смешанные, т.е. буквенно цифровые, но это не есть особая проблемма, как сделать так чтобы они были уникальные и монотонно возрастающие.
Например когда два пользователя одновременно создают записи в одной таблице, чтобы им не назначилось одинакового номера. И если один из пользователей создовал документ и передумал, а номер документу был уже назначен, то другому пользователю был бы назначен это номер, т.е. небыло разрывов в нумерации.
Может есть какие нибудь статейки по этому поводу, поделитесь ссылками.


msguns   (2005-05-31 15:27:00) [41]

>Petr V. Abramov ©   (31.05.05 15:10) [20]
>> очередной холивар ?
> Да :)

Ща.. шаблю прадедову возьму.. ;)

>Не стоит. Откатится транзакция по каким-либо причинам, и дырка готова

Для ентова есть правка ручками. Если следовать основным канонам делопроизводства, то все номера документов вместо с вх/исх информацией регистрируется в отд. журналах. Куда вовсе несложно глянуть, чтобы "подсмотреть" послений номер реальногодок-та.
Если же таковой журнал недоступен, то нет ничего страшного в пропуске номера. Делопроизводство не допускает одинаковой нумерации, но ничего не говорит по поводу "дырок".

Строить же специально какие-то таблицы по крайней мере нерационально, т.к. придется учитывать ВСЕ ВИДЫ документов, а это не всегда удобно и даже возможно. Написать же запрос (ХП), который будет резервировать № для указанного вида документа, причем с учетом возобновления нумерации с начала года, не проблема. Конфликт же уникальности опять же легко блокируется предваряющей перед вставку проверкой.

(Шаблю зачехлил, достал щит +6 к интеллекту ;))


Petr V. Abramov   (2005-05-31 15:10:00) [42]

> msguns ©   (31.05.05 09:17) [6]
> очередной холивар ?
 Да :)
> Числовой № получается автоинкрементом
 Не стоит. Откатится транзакция по каким-либо причинам, и дырка готова


Anatoly Podgoretsky   (2005-05-31 10:29:00) [43]

DenK_vrtz ©   (31.05.05 10:02) [17]
И идем вешаться.


ANB   (2005-05-31 10:22:00) [44]


> DenK_vrtz ©   (31.05.05 10:02) [17]
- положим, автоинкремент в мсскуле практически заменяет сиквенсы оракла. Имхо, их таки проще всего юзать. И быстрее, чем блокировка. Я блокировку только для DBF юзал, в клиппере, но там другого способа не было.


DenK_vrtz   (2005-05-31 10:02:00) [45]

Еще один "древний" способ.

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

Либо играть со спец. таблицей.


Nikolay M.   (2005-05-31 10:00:00) [46]

Один из вариантов: придумать алгоритм, который на основе ПК-Identity-поля и, возможно, некоторых других полей таблицы (например, дата-время создания документа, его тип, юзер и тд) формирует буквенно-цифровой код. Алгоритм реализовать в функции и подставить вызов этой ф-ции в вычисляемое поле таблицы. Если номер документа нужно видеть сразу до момента физической вставки записи, такое решение будет довольно геморойным.


Anatoly Podgoretsky   (2005-05-31 09:56:00) [47]

Ну например как в 13, естественно на поле наложить ограничение уникальности. Вместо удалений документа использовать понятие аннулирование, с указанием причины. Дырок не будет, поскольку документы не удаляются, номер не изменяется. Требуемое изменение номера делается через анулирование и создание нового документа. В MSSQL есть много механизмов генерации "номеров", identity, тригера, хранимые процедуры.
Номер естественно присваивается только при регистрации.


Ярослав   (2005-05-31 09:42:00) [48]

>> Anatoly Podgoretsky ©   (31.05.05 09:29) [10]
А как правильно сделать?


ANB   (2005-05-31 09:39:00) [49]


> Ярослав   (31.05.05 09:28) [8]
- предлагаю вариант для приказов :
- В момент создания документа присваиваем ему только ИД, а номер оставляем Null.
- Когда пользователь документ полностью оформит, он отправляет его на регистрацию. Журнал регистрации можно оформить в виде отдельной таблички с автоинкрементом. Автоинкремент, если его не дергать спец.процедурами, более - менее гарантирует уникальность, а монотонность ты обеспечиваешь явной операцией регистрации и проверками до вставки.
- С момента регистрации запретить пользователю удалять документ. И вообще не разрешать менять номер ручками.
Все имхо.


msguns   (2005-05-31 09:34:00) [50]

>Ярослав   (31.05.05 09:28) [8]
>Но меня интересует могут ли одновременно сработать на сервере две ХП или триггера и назначить одинаковые номера?

1. Одновременнодве ХП (и просто 2 запроса) на сервере не работют.
2. Для того и придуман автоинкремент, чтобы номера не повторялись.
3. Для "непрерывности" автоинкремент не походит, как и вся описанная технология. Необходимо делать самому автонумерацию (через спец. таблицу) для каждого типа документов.
4. А зачем именно непрерывность ?


Sergey13   (2005-05-31 09:34:00) [51]

2 [8] Ярослав   (31.05.05 09:28)
Во первых срабатывать будут не две ХП или триггера, а один тригер 2 раза. Кроме того есть еще транзакции и ограничения. Это (при правильном применении) практически непробиваемая защита.
Во вторых, я бы все таки посоветовал разнести номера документов и их ИДшники.


Anatoly Podgoretsky   (2005-05-31 09:29:00) [52]

Ярослав   (31.05.05 09:28) [8]
Считай что они работают одновременно, поэтому могут если сделаешь неправильно.


Sergey13   (2005-05-31 09:28:00) [53]

А по мне так вариант Danilka ©   (31.05.05 08:40) [1] наиболее приемлем. Нафига тот номер узеру до записи?


Ярослав   (2005-05-31 09:28:00) [54]

msguns ©   (31.05.05 09:17) [6]
Это все хорошо, но веть тогда о монотонности можно забыть ведь автоинкремент будет всегда новый, а она монотонность нужна бывает, иначе бы я о ней и не спрашивал, например номера приказов на предприятии как правило по порядку идут, да и много других таких документов.
А то что не видно номера в момент добавления так это не беда, в MS SQL его и так не видно... Да и ползователь готовя документ не знает о его будующем номере, да как правило и не надо ему его знать.
Но меня интересует могут ли одновременно сработать на сервере две ХП или триггера и назначить одинаковые номера?


Anatoly Podgoretsky   (2005-05-31 09:22:00) [55]

Ярослав   (31.05.05 09:17) [5]
Имеется ввиду изменение номера, если мы имеем его, то имеем и дыру, кроме этого еще имеем и подделку.


msguns   (2005-05-31 09:17:00) [56]

№ документа состоит из 2-х частей: числовая и символьная.
Числовой № получается автоинкрементом, символьная часть вводится ручками.
Для униакльности создается индекс
Числовой номер "вытягивается с сервера на клиент, но может корректиться юзером перед вставкой. Вариант Danilka ©   (31.05.05 08:40) [1] не советую категорически, т.к. юзер не видит № при добавлении документа, а сие не есть гуд (очередной холивар ?)


Ярослав   (2005-05-31 09:17:00) [57]

Danilka ©   (31.05.05 08:40) [1]
А два триггера не могут одновременно сработать?

>> DenK_vrtz ©   (31.05.05 09:04) [3]
А можно поинтересоваться как...

Anatoly Podgoretsky ©   (31.05.05 09:07) [4]
Ну с запретом на удаление то все ясно, а изменение то зачем запрещать?

В том то и дело, что готовые документы удалять нельзя, и их номера другим присваевать, но вот если пользователь ошибочно чтото ввел и тут же удалил, пока документов с большим номером ни кто не сделал. Выбрать тот же номер для нового документа нет проблемм, но здесь как раз меня и интересует именно одновременное внесение записей в таблицу, могут ли например два триггера одновременно сработать?


Anatoly Podgoretsky   (2005-05-31 09:07:00) [58]

Что бы не было разрывов в нумерации надо запретить изменение и удаление.


DenK_vrtz   (2005-05-31 09:04:00) [59]

>на счет разрывов нумерации проблема актуальная по сей день...

эта проблема уже давно решена, но каждый решает ее своим способом :)


Тучудище   (2005-05-31 08:48:00) [60]

Имхо на счет разрывов нумерации проблема актуальная по сей день...


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

Наверх

Титульная страница Поиск, карта сайта Написать письмо