Еще один НЕСчастный случай.


[ Пpишедшие ответы ] [ Отпpавьте свой ответ ] [ Пеpеговоpный пункт ] [ FAQ ]

Posted by Владимир Секретев (65.48.81.63) on December 20, 2002 at 22:11:32:

In Reply to: Еще один частный случай. posted by Скакунов Денис г.Братск on December 16, 2002 at 18:30:15:

План счетов содержит 80 – 100 тысяч субсчетов. Из них на начало следующего года необходимо оставить около 10 тысяч субсчетов.

Извини, Денис, но раз зашел разговор про частный случай, разреши мне задать частный вопрос. А почему так происходит? Почему через границу года не переходят 90% субсчетов? Неужели ВСЕ товарные запасы распродаются к концу года, поставщики и подрядчики разоряются, долги закрываются, материальные активы списываются? Что это за субсчета такие, что на них храниться? Если не коммерческая тайна, конечно.

Можно предположить, что предприятие торгует резисторами и на каждый заводится субсчет. Тогда, конечно, 100,000 за год продать не проблема.


Для того чтобы сбросить балласт и не перетаскивать в новый год распухшие acnt.a3p,


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

extra.e,

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


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

Так, 90% счетов убиваем, а то, что осталось - перекодируем! Короче говоря, переделке подвергается 100% плана счетов. К чему это я клоню? К тому, что, вероятно, БД спроектирована не самым оптимальным образом... И если разобраться, то, вероятно, не потребуется не только наличие механизмов чистки плана счетов, но и такой большой план счетов не потребуется.

Кажется, что действительно нужны только те 10% субсчетов, которые переходят-таки из года в год, а информацию, хранящуюся в остальных 90,000 можно разместить где-то в другом месте?

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

Однако приветствуя появление Адаптера я думал, прежде всего, о том, что ОБА года получили возможность работать с ОДНИМ планом счетов, что очень важно по нескольким причинам:

1. План счетов поддерживается в синхронном состоянии (равен сам себе).
2. Сделан первый шаг в направлении разработки сервера, который сможет (надеюсь) работать с многолетними базами, как с одной.

И это очень отрадно.

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

А нафига, спрашивается, тогда Адаптер нужен? Запустите два сервера и нечего уважаемому Автору голову морочить!




Пpишедшие ответы:



Отпpавьте свой ответ

Name:
E-Mail:

Subject:

Comments:
Link URL:
(можно не вводить)
Link Title:
(можно не вводить)
Image URL:
(можно не вводить)
ВАЖНО: Если отпpавленное сообщение не будет видно сpазу в
списке сообщений, нажмите клавишу Reload в browser'e.


[ Пpишедшие ответы ] [ Отпpавьте свой ответ ] [ Пеpеговоpный пункт ] [ FAQ ]