| Форумы
ЧАТ |
Орешник |
|
| Форумы -» | Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG |
|
| ||
|
|
Новости |
Поиск |
FAQ |
Статьи |
Книги |
Новости VCL
| | Форумы ЧАТ |
Орешник |
|
| |||
| |||
| |||
« предыдущая ветвь | форум | следующая ветвь »
Автоматическая номерация документов [D7, MSSQL]
Ярослав © (2005-05-31 08:21:00)Подскажите как автоматически назначать номера документов, т.е. записям БД. Они могут состоять как только из цифр, так и смешанные, т.е. буквенно цифровые, но это не есть особая проблемма, как сделать так чтобы они были уникальные и монотонно возрастающие.
Например когда два пользователя одновременно создают записи в одной таблице, чтобы им не назначилось одинакового номера. И если один из пользователей создовал документ и передумал, а номер документу был уже назначен, то другому пользователю был бы назначен это номер, т.е. небыло разрывов в нумерации.
Может есть какие нибудь статейки по этому поводу, поделитесь ссылками.
Cobalt (2005-06-01 13:16:00) [21]2 Тучудище (01.06.05 10:04) [40]
Надо понимать, какие требования вводят какие ограничения,
и какие ограничения вводят новые требования.
Если требуется непрерывность номеров - то хрен вам, а не отображение номера до его сохранения.
Если требуется отображение номера документа до его сохранения- то хрен вам, а не непрерывность номеров.
Иначе как обеспечить последовательность документов?
Порядок номеров = порядок заведения документа. Документ №76 заведён позже документа №77?
Тучудище (2005-06-01 10:04:00) [22]Давайие посмотрим в сторону 1Ц... что же мы там видим???? А видим мы там вот что....
1) Имеется табличка (1SDNLOCK.DBF для DBF) или (_1SDNLOCK для MSSQL)
2) В этой табличке имеется всего 2 поля
а) тип документа
б) номер документа
3) При создании пользователем нового документа формируется новый номер и добавляется в эту табличку
4) В случает отмены ввода документа, удалении документа номер так же изымается из вышеупомянутой таблицы
5) Большой минус всего этого в следующем:
Пусть пользователь А открыл документ и получил номер для него
Пусть пользователь Б открыл документ и получил номер для него
Пользователь Б сохранил документ
Пользователь А не сохранил документ
Номер пользователя Б стал последним
Когда номер пользователя А просто исчез
Вот пробел в нумерации готов
Это что касается присвоения номера в момент открытия нового документа.... хотя на практике 1Ц-шная система сбоя не давала(я не видел такого сопровождаю ее уже около 5 лет)
Как бы сделал я:
1) Не стал бы использовать генераторы ни в коем случае
2) Не стал бы использовать autoincrement котегорично
3) Далее идем по разветвлению,
a)если номер документа требуется в момент открытия документа(чем черт не шутит)... то ввел бы доп таблицу и последовал бы по
пути 1Ц
б)если номер присваивается после вставки документа, что менее капризно и риск пробелов в нумерации более менее ниже чем у варианта 'а' то создал бы механизм который присваивает новый номер документа в момент вставки нового документа в БД
в)проводил присвоение нумерации документов в конец дня(идеально), но фиг кто даст такое сделать! :-) а жаль! :-)
Anatoly Podgoretsky (2005-06-01 09:43:00) [23]Johnmen © (01.06.05 09:17) [35]
Вот тут много чего наговорили, только создаётся впечатление, что многие пытаются совместить две различные сущности - суррогатный ключ, по большому счёту никакого отношения к "жизненному" номеру документа не имеющий, и собственно сам этот номер.
Сообственно и сам номер документа - это не номер, а шифр/код документа. Номером называют по привычке и путают еще и с идентификатором записи.
ANB (2005-06-01 09:37:00) [24]
> Не стОило так однозначно относить себя ко "многим". :)
- да вроде ветку посмотрел - никто и не советует номер документа за суррогат держать. Имхо. Може чего и не углядел. А вот сам я раз на грабли наступил капитально. До сих пор старый проект с такими ключами. Ух и задрался я потом перебивать ключи при изменении даты документа. Молодой был, глупый, теорию не читал, да ее тогда толком и не было, как не было автоинкрементов и сиквенсов в Clipper.
Johnmen (2005-06-01 09:32:00) [25]>ANB © (01.06.05 09:21) [36]
Не стОило так однозначно относить себя ко "многим". :)
ANB (2005-06-01 09:21:00) [26]
> Johnmen © (01.06.05 09:17) [35]
- смотри мой пост [13]. Я там разношу понятия ключа и номера. Имхо, никто не давал советов объединять эти понятия. Просто нужна уникальная нумерация без дырок. Проблема старая и по человечески - плохо решаемая. Например, мой способ не очень подходит для счетов (когда нужно быстро сообщить клиенту номер). На одной из работ решили проблему просто - забили на дырки.
Johnmen (2005-06-01 09:17:00) [27]Вот тут много чего наговорили, только создаётся впечатление, что многие пытаются совместить две различные сущности - суррогатный ключ, по большому счёту никакого отношения к "жизненному" номеру документа не имеющий, и собственно сам этот номер.
Не стОит этого делать.
anatolyk (2005-05-31 21:46:00) [28]Я попытался сделать что-то вроде этого (MSSQL):
CREATE PROCEDURE [sp_GetFirstEmptyCodeByRecid]
@Recid Int
AS
select top 1 (Код+1)
from dbo.СтрокиПрайсЛистов T1
where (p_recid = @recid) and
((select top 1 Код from dbo.СтрокиПрайсЛистов T2 where (p_recid = @recid) and (код > T1.Код) order by код) - код) > 1
order by код
GO
где Код-понятно,
p_recid - id прайс-листа (с которым связаны СтрокиПрайсЛистов)
Не идеально, но работает.
Fay (2005-05-31 20:22:00) [29]Polevi © (31.05.05 17:58) [31]
>> для номеров документов непрерывность не нужна
Но всё меняется, когда приходят ОНИ - заказчики, считающие иначе!
8)
Anatoly Podgoretsky (2005-05-31 19:15:00) [30]Нулевой © (31.05.05 17:21) [30]
У тебя есть проблемы, хочешь поговорить?
Polevi (2005-05-31 17:58:00) [31]для номеров документов непрерывность не нужна
для счетов фактур см [13] + возможность всеже редактировать этот номер, для того чтобы бухгалтер мог при желании сделать "дробный" номер счета-фактуры - 1234/5 - без этого иногда никак
Нулевой (2005-05-31 17:21:00) [32]
> msguns © (31.05.05 15:55) [28]
1. Без проблем
2. именно второе, ситуация со счетом не канает, у меня другая ситуация.
3. так проще.
5. раздельная нумерация не нужна.
6. можно, без проблем (во второй таблице)
7. не понял?
Все написано о лично моей задаче, так что нечего пинать.
Из всего никто автору ничего не предложил, кроме как использовать Autoinc. Но он не подходит, как и мне не подходит.
100% даст разрыв в номерах, мне это важней всего (верной для пользователя это было под №1).
> Anatoly Podgoretsky © (31.05.05 15:58) [29]
Чем хамить, что-нибудь предложите автору, причем бесплатно!
Anatoly Podgoretsky (2005-05-31 15:58:00) [33]Они больны головой.
msguns (2005-05-31 15:55:00) [34]>Нулевой © (31.05.05 15:36) [23]
>Я делал так:
таблица 2 поля: 1-номер док., 2-год (для того чтобы год начинать с документа № 1,... новый год опять 1)
Start транзакция
блокировка таблицы
Update записи
ОК - Commit
иначе RollBack
транзакция короткая
полученный номер присваиваю номеру док. в другой табл. имеющей свой отдельный ID записи.
работает 2-3 пользователя введено 700 записей без проблем пока,
без разрывов.
Круто.
Вопросы тов.лектору:
1. А если надо номер писать вот так: 2005/10 или 10/2005 или 10-05 и т.д. (что, какмправило и наблюдается в реальной жизни) ?
2. Что такое "Update записи" - это когда юзер получает формочку и срочно бежит в тулет до обеда ? Или когда он уже нажал кнопульку ? В последнем случае номера, очевидно, он не еще знает.
Если второе, то как быть с такой ситуевиной. Менагер по продажам по телефону выписывает счет (или сразу накладную), в котором надо заполнить 30 полей, а его заказчик спрашивает № чтобы бежать в банк платить. Что ему скажет менагер,- мол, обожди, паря, щас тут у меня стартанет транзакция, сработает триггерец и, ежели не будет конфликта, то я скажу тебе номер ?
3. Если есть другая таблица только для номеров, то зачем тогда в первой поле "Год" ?
4. 2-3 пользователя весьма маловероятнисто начнут ввод документов одновременно (в интервале 1-2 сек, которого вполне хватит серверу, чтобы "зарезервировать" № даже если он не autoinc
. Так что не очень убедительно.
5. Как решен вопрос о раздельной нумерации разных видов документов ?
6. Можно ли поменять № в документе ? А если нет, то как быть, если это все же необходимо ? Удалять старый и перезаводить по новому ?
7. Чем же так страшны разрывы ?
Sergey13 (2005-05-31 15:48:00) [35]2[25] Нулевой © (31.05.05 15:42)
>Это уже не отменить так как все связано с кнопкой
Связь с кнопкой еще не гарантирует невозможность отмены (хотя бы аварийной) если внутри транзакции только апдейт первой таблицы.
Нулевой (2005-05-31 15:42:00) [36]Сняв естественно блокир.
Нулевой (2005-05-31 15:42:00) [37]Это уже не отменить так как все связано с кнопкой Сохранить или ОК или Добавить и т.д., отменить можно только Update в первой таблице.
Sergey13 (2005-05-31 15:39:00) [38]2[23] Нулевой © (31.05.05 15:36)
>полученный номер присваиваю номеру док. в другой табл
А если это отменить?
Нулевой (2005-05-31 15:36:00) [39]Я делал так:
таблица 2 поля: 1-номер док., 2-год (для того чтобы год начинать с документа № 1,... новый год опять 1)
Start транзакция
блокировка таблицы
Update записи
ОК - Commit
иначе RollBack
транзакция короткая
полученный номер присваиваю номеру док. в другой табл. имеющей свой отдельный ID записи.
работает 2-3 пользователя введено 700 записей без проблем пока,
без разрывов.
msguns (2005-05-31 15:29:00) [40]Т.е. я хочу сказать, что, конечно, не автоинкремент ;))
| |
Страницы: 