Что

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

Если так, то предложите просчитать Разработчикам кол-во строк за год и объем информации, думаю, что он будет не такой большой как кажется.

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

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

2 ichy: +1!
2 Dasha: журнал операций - это метод, инструмент. но насколько я понял, проблема у вас не в нем, а в сложности осознания того, что существуют как способы присвоить состояние только одному бланку, так и нескольким. причем одновременно.

ЧИТАЙТЕ РАНЕЕ НАПИСАННОЕ...

Что Если так, то предложите просчитать Разработчикам кол-во строк за год и объем информации, думаю, что он будет не такой большой как кажется.

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

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

Именно об этом я и говорю.
Куда может пропасть история, если у вас будут храниться все факты движения (ну или изменения статуса)? Т.е. понятно, что "на складе" куда приходили бланки, их через некоторое время не будет, но документы о приходе их туда и расходе оттуда никуда же не денутся...

Именно об этом я и говорю.
Куда может пропасть история, если у вас будут храниться все факты движения (ну или изменения статуса)? Т.е. понятно, что "на складе" куда приходили бланки, их через некоторое время не будет, но документы о приходе их туда и расходе оттуда никуда же не денутся...

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

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

А зачем вам строки экономить?

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

Действительно, не называйте это актами, не показывайте их пользователям после ввода... (они через некоторое время сами захотят их увидеть . Все равно же ни вы, ни они никуда не денетесь от каких-нибудь форм ввода фактов появления и исчезновения этих бланков

2 Водолей
Наверно так и сделаем. Спасибо за ответы!
2 ichy
Спасибо! Вроде проясняется. Напишу как все закончится.

Всем спасибо за ответы!

А зачем вам строки экономить?

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

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

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

В общем, нужна целостная картина, а не одна-единственная user story.

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

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

P.S. никто ведь не требует, чтобы Вы были разработчиком БД, но понимание "что такое БД и с чем ее едят" у Вас должно быть. на мой взгляд - это понимание у постановщика/аналитика должно быть, что называется, "по определению".

Таким образом, решила пока ограничиться юзкейсами и DFD + краткое описание подходов учета: поштучно и диапазонами с возможными отрицательными и положительными сторонами этих подходов. Теперь отдам это разработчикам. Буду гнуть линию, чтобы учитывать таки поштучно, потому как мне кажется это единственный логичный вариант. Если нет, то потребую конструктивной критики и их варианта решения проблемы. Дальше будет видно.
Спасибо всем за поддержку!!!

Я бы тут различал две стадии учета. На первой - мы имеем дело с пачками этих бланков, которые заказываются, поступают из типографии и передаются в конечные подразделения. И тут намного проще и компактнее учитывать диапазонами номеров. Разрешить в строках документов задавать диапазоны, сделать автоматически поддерживаемую таблицу текущего состояния, тоже с диапазонами. Соображение следующее - на это же надо печатать сопроводительные документы, и не будет. скорре всего. там перечисления номеров. а будут диапазоны - так пусть электронный документ этому соответствует.

А следующая стадия - это уже использование бланков, выписка на них конкретных документов (полисов). Тут надо в таблице состояний просто вести диапазон "использовано", а в документе - указывать номер. Если речь идет об автономной системе учета бланков - то вести отдельную таблицу документов (операций) использования.