|
Нужна помощь при добавлении данных в базу
|
|||
---|---|---|---|
#18+
> Автор: НадеждаМ Что мы должны Вас пытать? Вы можете изложить все требования к этим номера и их использование операторами? Я правильно понял, что нумерация документов должна быть "бездырочной" и не зависить от вводящего оператора? Posted via ActualForum NNTP Server 1.4 ... |
|||
:
Нравится:
Не нравится:
|
|||
07.02.2011, 15:34 |
|
Нужна помощь при добавлении данных в базу
|
|||
---|---|---|---|
#18+
НадеждаМ2 - непрерывность необходимаДля чего? Зачем? Чем обусловлена необходимость? Вас это спрашивают. Просто "так пользователи захотели" или таки есть какие-то более основательные причины? Все говорят, что надо, но пока ни один заказчик не смог обосновать эту необходимость. Боюсь, что и в Вашем случае будет то же самое и кроме неопределенного "ну, надо" ничего более конкретного не будет. ... |
|||
:
Нравится:
Не нравится:
|
|||
07.02.2011, 15:36 |
|
Нужна помощь при добавлении данных в базу
|
|||
---|---|---|---|
#18+
Игорь Горбонос> Автор: НадеждаМ Что мы должны Вас пытать? Вы можете изложить все требования к этим номера и их использование операторами? Я правильно понял, что нумерация документов должна быть "бездырочной" и не зависить от вводящего оператора? Если требуется непрерывность номеров, то тогда: 1. Редактирования номера документа пользователем должна быть запрещена! 2. Удаление документа не допустипо. Вместо этой операции должна быть в системе допустима операциия, выводящая документа из документаоборота ("аннулирование документа"). Т.е. документ в системе есть (и занимает номер), но имеет специальный статус "аннулирован" и не участвует нигде в операциях(удален и т.п.). Другой вариант иметь таблицу удаленных номер и в процедуре выделение нового номера искать и в ней, но это не избавит вас от наличия пропущенных номеров на какой-то момент времени (удалили 3 документа, а добавили только 1). С уважением, Алексей ... |
|||
:
Нравится:
Не нравится:
|
|||
07.02.2011, 15:48 |
|
Нужна помощь при добавлении данных в базу
|
|||
---|---|---|---|
#18+
Sergey SizovНадеждаМ2 - непрерывность необходимаДля чего? Зачем? Чем обусловлена необходимость? Вас это спрашивают. Просто "так пользователи захотели" или таки есть какие-то более основательные причины? Все говорят, что надо, но пока ни один заказчик не смог обосновать эту необходимость. Боюсь, что и в Вашем случае будет то же самое и кроме неопределенного "ну, надо" ничего более конкретного не будет. этой необходимости нет и в нормативке (или я чего-то не знаю) по поводу "дырок" проблему решает реализация "сторнирования документов" в системе, а не просто удаление т.е. при "правильной" организации процесса никто не мешает иметь в системе: документ №2 - оформленный, утвержденный и выданный документ №3 - оформленный, сторнированный по какой-либо причине и не выдававшийся никому документ №4 - оформленный, утвержденный и выданный .... при этом никто не мешает вести какие-либо журналы рег-и исходящих документов, в которых будет регистрация: 100. ...... 101. документ №2 от ... 102. документ №4 от ... ... т.е. наличие "дырок" в журнале регистрации - это не смертельно и ни кем не контролируется и не карается. а дырки - в голове у руководителей, которые от разработчиков требуют реализации таких задач. ну цен. бланки - это иное и не относится к тек.обсуждению, но и там также имеется регламентированный способ учета и списания испорченных и т.д... ... |
|||
:
Нравится:
Не нравится:
|
|||
07.02.2011, 15:59 |
|
Нужна помощь при добавлении данных в базу
|
|||
---|---|---|---|
#18+
НадеждаМ2 - непрерывность необходима 3 - с каждым новым годом номер документа должен начинаться с 1, потому значение napr_id не присваиваем значению number Для поддержания непрерывности Вам потребуется таблица, содержащая "дыры" в нумерации. Это чтобы новый документ брал номера из этих дыр. Чтобы не заморачиваться с разделением функционала сначала на поиск "дыр", а потом на последовательную нумерацию можно сразу создать таблицу с максимально возможным количеством номеров за год. Т.е., например, Вы знаете, что за год создется примерно 1`000 документов. Значит, создаете таблицу с 2`000 записей (нужен запас), где есть поле с порядковым номером. Кроме того, добавляется поле с признаком "Использовано" Предположим, что эта таблица называется tabNum, код записи - это поле nextNum, а признак использования - поле isUsed. Тогда код определения ближайшей не использованной записи получается примерно такой Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16.
Разумеется, при удалении документа надо будет снять признак "Использовано" с соответсвтующей записи. Если необходимо, то добавьте поле с номером года и включите год в условие поиска. Однако у такого подхода тот недостаток, что при большом количестве номеров он становится слишком не поворотлив. Долго рабтает, да и места много занимает. В принципе, можно, конечно, его оптимизировать в этом смысле. Например, хранить в таблице только дыры, а очередной номер брать из обычного счетчика (таблица с одной записью в которой увеличивается значение поля). Только подумайте еще раз, Вам действительно нужна реальная непрерывность номеров или это просто пожелание из разряда "хотелось бы, но если не получится - не страшно". Стандартное решение в данном случае - это таблица-счетчик. Примерно то, что Вам показали на foxClub. Т.е. никто не стремится использовать "дыры" в нумерации. Умерла, так умерла... ... |
|||
:
Нравится:
Не нравится:
|
|||
07.02.2011, 21:40 |
|
Нужна помощь при добавлении данных в базу
|
|||
---|---|---|---|
#18+
Sergey SizovНадеждаМ2 - непрерывность необходимаДля чего? Зачем? Чем обусловлена необходимость? Вас это спрашивают. Просто "так пользователи захотели" или таки есть какие-то более основательные причины? Все говорят, что надо, но пока ни один заказчик не смог обосновать эту необходимость. Боюсь, что и в Вашем случае будет то же самое и кроме неопределенного "ну, надо" ничего более конкретного не будет. Непрерывности требуют для целей проверки. Допустим, что при проверке выясняется, что документы с номерами 133,134 есть, а следом за ними идёт документ 136. Возникает вопрос: "А где у нас документ с номером 135? Неужели вы такие, сякие нехорошие, удалили его из списка? К вам наверняка обращался клиент с этим документом... а вы тут следы заметаете... " ... |
|||
:
Нравится:
Не нравится:
|
|||
01.03.2011, 17:53 |
|
Нужна помощь при добавлении данных в базу
|
|||
---|---|---|---|
#18+
BestiAНепрерывности требуют для целей проверки. Допустим, что при проверке выясняется, что документы с номерами 133,134 есть, а следом за ними идёт документ 136. Возникает вопрос: "А где у нас документ с номером 135? Неужели вы такие, сякие нехорошие, удалили его из списка? К вам наверняка обращался клиент с этим документом... а вы тут следы заметаете... " кто проверяет? ... |
|||
:
Нравится:
Не нравится:
|
|||
01.03.2011, 18:16 |
|
Нужна помощь при добавлении данных в базу
|
|||
---|---|---|---|
#18+
BestiAВозникает вопрос: "А где у нас документ с номером 135? Неужели вы такие, сякие нехорошие, удалили его из списка? К вам наверняка обращался клиент с этим документом... а вы тут следы заметаете... " Это возможно только в случае, если имеется "твёрдая копия" с таким номером, с вашими реквизитами и с подписью некоего ответственного лица. Любые другие варианты просто не катят... И наличие отсутствия некоего "номера в последовательности" при условии, что аудит не выявил нарушения в движении документов и итогах оборотов - из разряда абстракций. Некомпетентность руководителей даже в пределах собственных полномочий и обязанностей, конечно-же, никто не отменял. НО! - это не ваши проблемы как разработчика. Поскольку вам никто не представил норматив, требующий непрерывной нумерации. Где-то так примерно... ... |
|||
:
Нравится:
Не нравится:
|
|||
02.03.2011, 03:35 |
|
Нужна помощь при добавлении данных в базу
|
|||
---|---|---|---|
#18+
А что если применять следующий алгоритм: Пишем хранимую процедуру: 1. получить максимальный номер документа в таблице на текущий момент и запомнить значение его автоинкрементного поля ID 2. Запомнить новый уникальный идентификатор. (NewID()) 2. Вставить новую строку в таблицу попутно вставив в неё этот идентификатор. 3. Получить ID только что вставленной записи по значению идентификатора. 4. Вычислить новый номер как значение предыдущего + число вставленных между максимальной и новой записей + 1 5. записать вычисленный номер и вернуть его Такая схема не спасёт от пропусков в нумерации, если документ удалить из середины, но при непрерывном заполнении она по идее должна нормально работать. Хочу услышать мнения по этому поводу. ... |
|||
:
Нравится:
Не нравится:
|
|||
03.03.2011, 14:23 |
|
Нужна помощь при добавлении данных в базу
|
|||
---|---|---|---|
#18+
НадеждаМпрошелмимо делают наоборот. как-то так: при наборе(подготовке документа, или до опред.статуса док-та) номер не присваивают, а присваивают в момент сохранения и отображают сообщение об успешном сохранении документа и "светят" присвоенный ему номер. В принципе я так и предполагала сделать, но диспетчера развизжались, а спорить с ними не хотелось. Придется принуждать... НадеждаМ2 - непрерывность необходима Если предложение выдавать номер постфактум не подходит, то можно предложить еще один вариант: Сделать отдельную таблицу выданных номеров, где выданный номер закрепляется за оператором, оператору дается возможность создать документ с номером который уже за ним закреплен. Для повышения внимательности операторов издать внутренний указ "За взятый и неиспользованный номер в течении дня/недели/месяца штраф оператору 100р за каждый пропущенный номер, с вывешиванием фото оператора на доску позора" ... |
|||
:
Нравится:
Не нравится:
|
|||
03.03.2011, 14:40 |
|
Нужна помощь при добавлении данных в базу
|
|||
---|---|---|---|
#18+
Dima TДля повышения внимательности операторов издать внутренний указ "За взятый и неиспользованный номер в течении дня/недели/месяца штраф оператору 100р за каждый пропущенный номер, с вывешиванием фото оператора на доску позора" операторам обратиться в труд.инспекцию и прокуратуру по факту грубого нарушения ТК РФ. ... |
|||
:
Нравится:
Не нравится:
|
|||
03.03.2011, 15:21 |
|
|
start [/forum/topic.php?fid=41&gotonew=1&tid=1584518]: |
0ms |
get settings: |
12ms |
get forum list: |
16ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
125ms |
get topic data: |
11ms |
get first new msg: |
9ms |
get forum data: |
3ms |
get page messages: |
53ms |
get tp. blocked users: |
1ms |
others: | 17ms |
total: | 255ms |
0 / 0 |