Нумерация документов

← →
Leon1 (2005-01-28 08:28) [0]

Народ, ни кто не сталкивался с данной штукой? как лучше реализовать? естественно Номер документа как первичный ключ не подойдет! У меня есть идеи например:
1)реализация с помощью отдельной таблицы с автоинкрементным полем в которую производится вставка перед открытием документа тем самым можно получить значение следующего номера, минус этого способа если документ будет открыт и не записан получится что номер пропал
2)То же что и первое но вставка производится после запсиси документа, а значение автоинкрементного поля получается в момент открытия документа и увеличивается на 1.. минус пользователь может держать фиг знает сколько этот документ открытым и могут родиться документы с содинаковыми номерами
3) SQL запрос на MAX(NumDoc) минус точно такой же как и у 2 способа
4) SQL запрос на COUNT(*) минус номера должны быть изменяемыми и если после первого пошел 10 то следующий получим не 11 а 3...
Мож кто то подскажет еще какие нибудь решения?????

← →
Sergey13 © (2005-01-28 09:19) [1]

>номера должны быть изменяемыми
Это как? Что это за номера такие?
Процесс записи должен быть коротким. Прочитал запись в переменные, работай скока шочешь, перед записью проверь условия и, при выполнении их, быстро запиши.
ЗЫ: Для многопользовательской работы лучше применять соответствующие инструменты. (это я про Парадокс 8-)

← →
Leon1 (2005-01-28 09:46) [2]

Ну положем объем задачи не такой чтобы применять SQL сервера, на счет изменяемых номеров, ну вот смотри, нужно переделать документы или еще что то, в общем такое очень часто происходит когда номер документа может быть изменен пользователем... мало ли какая хрень может случиться что потребуется номер документа изменить...

← →
Sergey13 © (2005-01-28 09:51) [3]

2[2] Leon1 (28.01.05 09:46)
>Ну положем объем задачи не такой чтобы применять SQL сервера,
А какой объем, по твоему критичен?

>мало ли какая хрень может случиться что потребуется номер документа изменить...
Вот именно хрень. Документ же наверное имеет и печатную копию. Перепечатывать. Если ты меняешь один, то может и остальные перенумеровываешь? Это ж быардак получается, ИМХО. ИМХО, опять же, но номер это неизменный атрибут документа.
Что за документы у тебя вообще? Накладные какие нибудь или что?

← →
ЮЮ © (2005-01-28 09:54) [4]

Во-первых, только не инкремент.
Во-вторых, в силу 1)-4) можно сразу взять номер на 1 болше, чем последний MAX(NumDoc) + 1, а при сохранении проверить, не записал ли кто документ с таким номером и, известив об этом сохраняющего документ пользователя, предложить ему новый номер.

← →
Leon1 (2005-01-28 10:25) [5]

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

← →
msguns © (2005-01-28 10:33) [6]

1. Номер документа должен состоять из двух полей: числового и символьного.
2. Номер документа может меняться как при вводе, так и при корректировке документа
3. Номер (числовой) при добавлении документа может вычисляться автоматически как MAX(<Числовая часть номера>) WHERE <Тип документа> and <Условие по году>
4. В структуре записи заголовка док-та предусмотреть поле "Входящий номер" (симв. не менее 24) и "Входящая дата" для сохранения там оригинальных (с документа) номера и даты (используется для приходных и возвратов от покупателей)

← →
msguns © (2005-01-28 10:53) [7]

5. Перед записью нового/измененного заголовка документа можно давать запрос на поиск аналогичного и если есть, давать предупреждение с возможностью вычисления нового автономера. Эта фича, если честно, бывает практически не нужна: вероятность одновременного ввода однотипных документов за достаточно малое время мизерная.

← →
Sergey13 © (2005-01-28 11:08) [8]

[6] msguns © (28.01.05 10:33)
Все правильно, только уж слишком, ИМХО. 8-)
Я не вижу особых причин вообще редактировать номер. Просто смысла не вижу, а гемороя добавляет. Может я и ошибаюсь.

← →
Соловьев © (2005-01-28 11:13) [9]

>[D7, Paradox]
>3) SQL запрос на MAX(NumDoc) минус точно такой же как и у 2 >способа
Почему это минус? Для файловых СУБД это как раз ед. решение.

← →
msguns © (2005-01-28 11:17) [10]

>Sergey13 © (28.01.05 11:08) [8]
>Я не вижу особых причин вообще редактировать номер. Просто смысла не вижу, а гемороя добавляет.

Так от тебя не требуется видеть смысл, от тебя требуется лишь предусмотреть такую возможность ;)

Ладно, так и быть, один из вариантов смысла:
Есть системы, в которых нет счетов. Вернее, они вообще-то могут печататься, по ним резервируется товар и т.д. Фактически же "счет" есть не что иное, как непроведенная накладная отгрузки. Когда покупатель забирает товар, то накладная проводится (снимаются остатки со склада) и "счет" становится "накладной". Естественно, нумерация счетов и накладных разная. Вот оператор перед проведением документа и меняет № с "Номера счета" на "Номер накладной отгрузки"

← →
Sergey13 © (2005-01-28 11:43) [11]

2[10] msguns © (28.01.05 11:17)
>от тебя требуется лишь предусмотреть такую возможность
В том то и дело, что пока не требовалось. 8-)

>и "счет" становится "накладной".
Интересные превращения. Рубли там долларами не становятся? Нет? Жаль. 8-)
Можно конечно придумать ситуации, но смысл этого мне все равно не понятен. Я не против твоей концепции, просто мне она кажется слегка излишней на практике в подавляющем количестве случаев. Может я и ошибаюсь.

← →
Leon1 (2005-01-28 12:17) [12]

Я как раз к этому и склоняюсь, тут как раз назревает вопрос о введении задним числом... это просто мрак получим
1
2
3
4
5
99
6
7
8
9

Как то явно не красиво получается а что делать... ничего...

← →
Leon1 (2005-01-28 12:26) [13]

Вожможен еще вариант такой,
заводится отдельная таблица которая содержит
Уникальный идентификатор(Id),
номер документа(NumDoc),
дата документа(DateDoc),
время документа(TimeDoc),
далее таблица с шапкой документа там контрагенты договора прочая мерзлость, заводится еще одно поле грубо говоря Pid (Parent Id) этот самый Id связывается с Pid т.е. получаем что запись в шапочной таблице документа является дочерней для Таблицы с дребеденбью о номерах и т.п. в таблице с шапками документов на событие OnNewRecord вешаем что то вроде этого
With TQuery.Create(Self) do begin
DataBaseName:="CarsDataBase";
SQL.Add("SELECT MAX(Number)+1 AS MaxDocNumber FROM SRASPOR");
Open;
SRasporTable.Append;
SRasporTable.FieldByName("Number").AsInteger:=FieldByName("MaxDocNumber").AsInteger;
SRasporTable.FieldByName("DocTime").AsDateTime:=SysUtils.Time();
SRasporTable.FieldByName("DocDate").AsDateTime:=Date();
SRasporTable.Post;
Close;
Free;
End;

Тем самым гарантировано не произойдет колизии в момен записи документа номер будет занят на протяжении всего времени работы пользователя с документом а в случае отказа от создания документа можно просто удалить эту запись из таблицы... но это мое ИМХО....

← →
Leon1 (2005-01-28 12:28) [14]

P.S. Кстати при такой схеме работы можно наполнять и табличную часть документа записями не запоминая при этом данные шапки!

← →
Sergey13 © (2005-01-28 12:31) [15]

А какова первопричина твоей озабоченности? Дырки в нумерации? Неупорядоченность номеров при упорядочивании по дате? Так это вроде не регламентируется нигде и никем. Только "красивость" страдает.

Я бы забил на это.

← →
Соловьев © (2005-01-28 12:31) [16]

2 Leon1 (28.01.05 12:26) [13]
Нарываюсь на msguns 8). Но!
Пока не поздно уйдите Вы от этой СУБД, перейдите на нормальную клиент/серверную - FireBird например(http://firebird.sourceforge.net , http://ibase.ru)
Избавите себя от кучи головной боли.

← →
ЮЮ © (2005-01-28 12:33) [17]

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

Последний был № 4
Первый пользователь взял № 5
Второй взял № 6
Второй сохранил
Первый отказался

№ 5 - пропушен

См.[4]
Первый пользователь взял № 5
Второй взял № 5
Второй сохранил
Первый отказался

Если и первый попытается сохранить, то получит предупреждение, что №5 уже существует и будет предложен №6.

← →
Leon1 (2005-01-28 12:40) [18]

Если два пользователя одновременно открыли документ тут и возникает колизия, но если чуть раньше или чуть позже то все буде акейно! в крйнем случае тут можно установить блокировку на таблицу и получим что то вроде пока новый номер добаляется то другой пользователь не может создать новый документ или что то в этом духе, но тут создается другой вопрос! а что если пользователь повис в момент открытия документа.. ведь блок то ни кто не снимет %-) и тута новая проблема..... ох...

← →
msguns © (2005-01-28 12:56) [19]

>Leon1 (28.01.05 12:26) [13]

Предусмотри текстовую часть. Дело в том, что возвраты часто "нумеруют" как <№ прихода>"Возврат" или подобное. Избавишь себя от траблов будущем. Послушайся совет стараго израненого ветерана ;)

>Sergey13 © (28.01.05 12:31) [15]

Дело говорит

>Соловьев © (28.01.05 12:31) [16]

Это я против "птички" !? Саня, ты не прав. Если разрабатывается новый проект или коренным образом перерабатывется старый, я - первый, кто за то, чтоб забыть про локалки (любые)

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

При отображении списка документов на клиенте очень рекомендую предусмотреть панельку для ввода узером доп.условий выборки, куда обязательно включить контрагента и период. И по умолчанию сортировать по дате-времени создания документа (часто они должны совпадать с временем фактического перемещения товара). Такая схема удовлетворяет 99% пользователей проги. А то, что №№ документов будут не подряд - не страшно абсолютно. Хотя бы потому, что если можно, оператор (бухгалтер) может его перенумеровать (например, для внутренних или приходов) или поменять дату.

← →
Leon1 (2005-01-28 12:59) [20]

2 Соловьев да сейчас помоему дело не в самой СУБД а в практике реализации нумерации документов, факт есть факт что инкреметное поле не подойдет, а Paradox это или Interbase именно в данной задаче роли нет ни какой, причем мне известно дофига примеров НОРМАЛЬНОЙ работы с БД Paradox, и помоему Interbase или Paradox дело каждого я лично предпочитаю MSSQL но склонять и пропогандировать к переходу на него не буду и не хочу:-) так лирическое отступление ни кого не хотел обидеть если что

← →
msguns © (2005-01-28 13:06) [21]

>Leon1 (28.01.05 12:40) [18]
>и тута новая проблема..... ох...

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

Советую обратить особое внимание на другие вещи: актуальность остатков и транзакционность (т.е.целостность пакета изменений в БД и т.д.). Здесь ожидаются куда более сурьезные траблы, особенно с учетом кривизны локалок, где парадокс чуть ли не лидирует по глюкавости.

← →
Соловьев © (2005-01-28 13:08) [22]

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

Предпочитаю MS SQL и я, но на него деньги нужны и не малые. А FireBird бесплатен.

← →
msguns © (2005-01-28 13:09) [23]

Ни в коем случае не инкремент для номера !!! Ни в коем случае ! Буквально через неделю эксплуатации проги операторы будут плеваться на такой автономер. Я уж молчу о сбросе нумерации с 1-го января и раздельной номурации для каждого типа документов при том, что заголовки их могут лежать в одной таблице.

← →
Соловьев © (2005-01-28 13:10) [24]

msguns ©
Вам надо за посты памятник ставить, так много писать(и главное по делу) это надо уметь! 8)

← →
Leon1 (2005-01-28 14:00) [25]

2 Соловьев MSSQL за баксы MSDE халява! :-) Поясню, поскольку в Delphi я человек не такой уж и опытный, то избрал для начала Paradox просто посмотреть что да как и вообще что кчему как работает и т.п. я конечно понимаю что есть масса компонент типа FibPLUS которые значительно способствуют у программиста развитие желания и интереса работать над самим программным продуктом а не ловить грабли на тему типа а почему IBTable такой плохой или а почему IBQuery не то.. то.. то.. Именно основное дело заключается в том, что отсутсвует нужная информация или за частую ее просто тяжело выловить в просторах сети или на книжных прилавках, подумайте, чему учат в институтах и в мудреных толстых томах, я лично имею немалый набор книг по Delphi но насколько помню в институте нас учили использовать BDE и Paradox а о сложных фомах мы и знать не знали... показывали общие примеры типа TDataBase TTable TQuery TDbGrid TDBNavigator все... за сим откланились взяли курсовые и бай бай... ни в одной книге я не видел описаний методик реализации механизма рассчета остатков... или механизма подбора по товарной номенклатуре все как то приведено в общем для небольшого количества и естественно литература не дает исчерпывающие ответы на вопросы, после чего возникают мучительные думки... блин а как этот механизм покажет себя на пактике... я сам в основном около 3 лет занимался конфигурированем 1С и как бы и подзабыл уже некоторые аспекты разработки ПО в таких системах как Delphi.... исключительно мое мнение... о данному вопросу... на рынке отсутсвуют просто методические пособия по написанию сложных ERP систем....

← →
msguns © (2005-01-28 14:04) [26]

Крик души ?

← →
Соловьев © (2005-01-28 14:05) [27]

у каждой халявы есть ограничения 8) у MSDE - 5 коннектов.

← →
Соловьев © (2005-01-28 14:07) [28]

> по написанию сложных ERP систем....
о Парадоксе я тут промолчу ... :)

← →
Leon1 (2005-01-28 14:22) [29]

По поводу таблиц посню явно, главная таблица реквизитов, есть таблица со строками документов грубо говоря по механизму
Master->Detail в основной есть Id в другой есть Pid поле, Id является сурогатным ключем следовательно для вставки данных в Detail таблицу нужно
а) чтобы запись с Pid = Id находилась в БД
б) нужно знать этот самый Id чтобы присвоить его Pid
Для любой субд (и это факт) до физического попадания Записи в Master таблицу предугадать какой Id пудет не возможно, если это конечно не однопользоватльская программа
т.е. получается пока шапка документа не записана то речи о вставке стро быть не может, т.е. сначала сохрани шапку а потом вбивай строчки

В случае если в дело вступает 3 таблица то получим следующее:
1) Таблица содержит(ID,NumDoc,DateDoc,TimeDoc);
2) Таблица содержит(IDDOC,KONTR,DOGOVOR, и т.п.);
3) Таблица содержит(PID,TOVAR,RASHOD);
При создании документа вставляем запись в 1 получаем что вставка для 2 и что самое важное для 3 производится до записи документа... пользователем в случае отмены все просто банально удаляется... вот суть идеи

← →
Leon1 (2005-01-28 14:24) [30]

Можно расценить как крик души, а что разве с помошью Paradox нельзя создать путевую трехзвенку? ;-)

← →
Leon1 (2005-01-28 14:29) [31]

Я не упорствую на счет парадокса, поймите меня правильно... я если честно сма склонен к использованию Interbase или еще чего - то из Линейки SQL серверов...

← →
Anatoly Podgoretsky © (2005-01-28 14:40) [32]

Соловьев © (28.01.05 13:08) [22]
Предпочитаю MS SQL и я, но на него деньги нужны и не малые. А FireBird бесплатен.

Заблуждение MS SQL тоже бесплатен, но только сооветстующая облегченная версия, называется MSDE

Leon1 (28.01.05 14:22) [29]
1) Таблица содержит(ID,NumDoc,DateDoc,TimeDoc); -> (ID,NumDoc,DateTimeDoc);

← →
Leon1 (2005-01-28 14:43) [33]

Мне например удобнее DateDoc,TimeDoc, может я конечно и заблуждаюсь но если использовать DateTime то каким образом можно отгруппировать документы в итоге по дням? здается мне что полсе GROUP BY (DateRimeDoc) я получу отдельной строчкой кажный документ...???

← →
Sergey13 © (2005-01-28 14:44) [34]

2[29] Leon1 (28.01.05 14:22)
>Для любой субд (и это факт) до физического попадания Записи в Master таблицу предугадать какой Id пудет не возможно, если это конечно не однопользоватльская программа

Это самое большое твое заблуждение.

← →
Leon1 (2005-01-28 15:03) [35]

Ну положем есть в FibPlus штуевина которая может определить для InterBase значение генератора, но тем неменее когда Master запись отсутствует все равно нельзя вставлять запись в Detail таблицу с отсутсвующим Id из Master...

>Leon1 (28.01.05 15:03)

Повторю еще раз: Вы акцентируете свое внимание абсолютно не на том ! У Вас, простите, каша в голове вместо четко представляемой модели данных, а Вы мало того, что озабочены выбором СУБД (проблема с номером Вами совершенно надумана и мы гуртом долго пытались Вам это втолковать, но, похоже, безрезультатно), так еще абсолютно мизерный трабл пытаетесь "оригинально" решить с помощью этой СУБД. Видимо, подобные задачи Вам в диковинку.
Вот Вам совет:
1. Почитайте что-нибудь о принципах реализации складского учета в торговле, посмотрите работающие программы, их интерфейс, обмен данными с БД и т.д. Поговорите со знакомыми программистами, имеющими наработки в этой области.
2. Почитайте о клиент-серверных СУБД, транзакциях, генераторах, хранимых процедурах..
3. Почитайте хотя бы в основных чертах о принципах построения баз данных, нормализации, избыточности, целостности и т.д.

Уверен, что если Вы воспользуетесь моим советом, то сабжевый вопрос отвалится сам по себе.

С уважением и пожеланием успехов в совсем нелегком деле проектирования Баз Данных.

← →
Leon1 (2005-01-28 15:36) [37]

Мы по всей видимости гом о разных вещах, не составляет проблем сделать нумерацию, не составляет труда написать софт, и модель данных давно есть, вся база данных на лицо, и про реляционные теории мне говорить не нужно, вопрос стоял ели еще кто то понминт есть ли еще способы реализовать мехнаизм нумерации? вместо этого беспочвенные оскорбления и т.п. Просто негде подчерпнуть информацию о том как это реализуется на практике от того и неуверенность прав ли я или нет.... нормализация избыточность целостность..... транзакции... 1НФ 2НФ 3НФ 4НФ.... все это теория... у нормального программиста нормализация БД должна быть автоматически заложена... ай у меня температура 39 меня плющит...

> вопрос стоял ели еще кто то понминт есть ли еще способы
> реализовать мехнаизм нумерации?

реализация механизма базируется на неких правилах.
с т.з. правил "нумерации входящей первички" - таких правил попросту нет.. каждый твой контрагент имеетправо нумеровать свои док-ты как ему вздумается. Отсюда и выводы соотв-щие .. для тебя .. и не только ..

что же касается уникального ID док-та в пределах базы как таковой - это НЕ имеет никакого отношения к "нумерации входящей первички"
каждый док-т в имеет уникальный ID (он же вправе считаться первич.ключем записи для внутренних БД-связей), но не обязан иметь уникальным атрибут под названием "номер входящего документа" - последний вводится на основании реального входящего документа контрагента, этот номер контрагент формирует как ему заблагорассудится, ибо он имеет на то полное право.

>Leon1 (28.01.05 15:36) [37]
>вместо этого беспочвенные оскорбления

Давайте разберемся.
1. По поводу оскорблений. Видимо, основанием для такого "тяжелого" аргумента послужило мое вот это:
У Вас, простите, каша в голове

Это Вы считаете оскорблением ?

Во-первых, видимо, Вас никто никогда не оскорблял.
Во-вторых, если заменить это на слово "неразбериха", Вам станет легче ? Если да, то я не против, давайте заменим. Более нигде, сколько не читал свои посты, не заметил даже намека на оскорбление. Более того, пытался с максимальной вежливостью и ясностью Вам помочь. Причем, вполне искренне.

2. Что касается "почвенности", то о каше я сказал после Ваших [14], [18], [20], [25], [29-31], [33] и (особенно !) [35]
Попробуйте непредвзято прочитать эти свои посты и оценить сам себя. Определенно складывается впечатление, что человек нахватался терминов и кое-каких отрывочных знаний об этих терминах, но четкой картины и, главное, понимания концепции построения БД, у него нет: трехзвенки, ERP, "колизии", "Линейки серверов" - все нарублено в одну кастрюлю, как венегрет.
Это не значит, что чел безграмотный. Вполне возможно, что он спец в программировании, но в другой области., например, в 1С.
Кроме того, на лицо явно недостаточное знание объекта автоматизации, т.е. торговли, а также делопроизводства и бухгалтерии. О чем Вам, кстати, многие тут намекали. Причем в достаточно вежливой форме.

ИМХО, стОит задуматься вместо того, чтобы банально состроить из себя оскорбленного. В следующий раз на Вас просто не будут тратить столько своего времени и внимания. Вам от этого станет легче ?

И еще напоследок: перечитайте еще раз Правила Форума. Там четко сказано, что здесь никто никому ничем не обязан. В следующий раз, прежде чем оскорбиться и, не разбирая клавиш, строчить "ответку", вспомните это золотое правило. Глядишь, и температура не будет повышаться.

Если нужна нумерация уникальная и "без дырок" - без пропуска номеров, тогда
заводим табличку из одной записи с одним полем last_num,
update ... set last_num = last_num + 1, читаем и сразу commit
Другого способа нет, или "дырки" будут, или потенциальное нарушение уникальности

Без дырок говоришь, тогда надо закладывать право обязательности и неудоляемости.

← →
Sergey_Masloff (2005-01-30 11:04) [42]

Petr V. Abramov © (28.01.05 18:47) [40]
>Если нужна нумерация уникальная и "без дырок" - без пропуска >номеров, тогда
> заводим табличку из одной записи с одним полем last_num,
>update ... set last_num = last_num + 1, читаем и сразу commit
А потом юзер думае - а на фиг этот документ. Я его и заводить не буду. И получаем в базе огрызок у которого есть только номер (да и его сохранить не удастся)

> Другого способа нет, или "дырки" будут, или потенциальное >нарушение уникальности
Ну не знаю. Я когда-то сделал так:
1)есть таблица-буфер (кэш, как угодно назови) c полями типа номер, дата резервирования, кто резервировал.
2) Когда пользователь создает новый документ (пока у себя - записи в базу нет) процедура берет новый номер генератора и создает запись в буфере - вася пупкин зарезервировал номер 10 в 9:30 18 января. Коммитим.
3) Пользователь работает с документом. Потом 3 варианта
- все нормально документ пишем в базу. При этом из буфера ранее зарезервированый номер удаляем все в порядке.
- все плохо документ дискардим. В буфере номер помечаем как свободный.
- выключили свет все накрылось. Ничего не далаем да и не можем.

4) Создается новый документ. Перед тем как генерировать новый документ сначала лезем не к генератору а в буфер и ищем там первый номер который а) помечен как свободный (последствие отмены документа) б) зарезервирован более суток (восьми часов, двух часов - настраивается - плод вырубона электричества или снятия клиента по Ctrl-Alt-Del). У этого номера изменяется дата резервирования - дальше см. выше. Если в буфере - кеше записей нет то генерируем новую запись вставляем ее в буфер на кону мочло начинай сначала.

Вся эта петрушка была сделана в моем первом самостоятельном проекте работает уже 8 лет из них 6 лет без моего участия. Сбоев нет все нумеруется.

Как тут весело.

[42] Sergey_Masloff (30.01.05 11:04)
> зарезервирован более суток (восьми часов, двух часов - настраивается
> - плод вырубона электричества или снятия клиента по Ctrl-Alt-Del)

более суток не очень приятно. да и так, остается мизерная вероятность того, что появится документы с нарушеной хронологической последовательностью (например, последовательность:
20.10.2004 235
20.10.2004 237
21.10.2004 236
), а это более недопустимо чем дырки. Точнее, это-то как раз и недопустимо для ряда документов законодательно, а дырки допустимы, по-крайней мере, я не знаю таких документов, где дырки запрещены законодательно.

← →
Sergey_Masloff (2005-01-30 14:55) [44]

Danilka © (30.01.05 13:58) [43]
Ну настрой на 20 минут. Не оформил документ за 20 минут - в сад. Вобщем, все настраивается. В конкретно той задаче были именно такие условия - чтобы дырок не было и 1 день. Так и сделал.

>я не знаю таких документов, где дырки запрещены законодательно
Это в библиотечном учете. Не помню точно но руководящий документ есть. Они до этого шахматки рисовали знаешь наверное такая расчерченая бумажка с номерами присвоил - зачеркни.

Sergey_Masloff (30.01.05 11:04) [42]
> А потом юзер думае - а на фиг этот документ.
Уточняю: вся это происходит непосредственно перед коммит, т.е. когда уже нажато Save и пути обратно нет. Иначе в блокировку вопрешься 100%

> Ну не знаю. Я когда-то сделал так:
> Когда пользователь создает новый документ (пока у себя - записи в базу нет) процедура берет новый номер генератора и ....
Выключили свет -> дырка в номерах :) Генератор-то работает не в контексте транзакции, поэтому при recovery его значение не откатится.

← →
Sergey_Masloff (2005-01-30 16:44) [46]

Petr V. Abramov © (30.01.05 16:29) [45]
Ты не понял метод. Номер генерится ДО всего. Единственно что может произойти - выключение света за ту долю секундыкоторую занимает запись 1 записи в кэш. Если не в лом еще раз прочти изложеную методику.
Начинается все с того что вызывается функция которая
1) Дергает генератор
2) Пишет его значение в кэш с описаными атрибутами
3) Коммитит
4) Возвращает значение пользователю (документа еще нет)

Время выполнения этого - ну не знаю, ну пара-тройка сотен тактов процессора.То есть с выключением очень точно надо угадать.

Номер можно присваивать и после сохранения, только нуже таймстамп. Отсутствие дырок и последовательность в данном случае гарантирована.

> Sergey_Masloff (30.01.05 16:44) [46]
> Ты не понял метод.
IMHO, понял
> Единственно что может произойти -
выключение света за ту долю секунды которую занимает запись 1 записи в кэш.
Вероятность ж... , не спорю, очень мала. Но, к сожалению,
Законы Мерфи имеют приоритет над законами больших чисел

> Anatoly Podgoretsky © (28.01.05 20:14) [41]
> Без дырок говоришь, тогда надо закладывать право
> обязательности и неудоляемости
и регулярного backup`а, чтоб совсем глубокой дырки не было :)

[44] Sergey_Masloff (30.01.05 14:55)
Понятно. Но, как справедливо заметил [41], в таком случае их и удалять надо запрещать.

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