В проектирование БД я создал топик http://www.sql.ru/forum/actualthread.aspx?tid=516822 решил его продублировать еще здесь т.к. я думаю что люди пишущие под cache могут мне подсказать в каком направление двигаться (сам я использую ООБД отличную от cache). Вопрос состоит в том как правильно спроектировать классы для задачи бухгалтерского учета с учетом что хранение данных будет производиться с помощью ООБД т.е. классы лягут в базу. Например нужен ли отдельный хранимый класс доступный из вне под проводку (полупроводку)?

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

krvsa
Звучит как приговор...


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

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


То что проводок много и меня вгоняет в ступор :) Как то противоестественно для меня думать о каждой проводке как об отдельном объекте.

Правда самая частая операция которая производится над набором записей проводок это их выборка и агрегация, вот и возникает вопрос а может это можно было бы делать как то иначе без проводок?

Для затравки попробую привести часть своих мыслей которые у меня стали возникать когда я стал смотреть на эту задачу через призму ООП. И так такого понятия как проводка в принцыпе не существует для БУ имет значение понятие остака на счете на дату и оборотов по счету. Таким образом мы имеем объект счет который может вернуть свой текущий остаток и остаток на любую дату, остаток на счете может меняться с помощью документов, должна веститсь история изменения значения счета что бы мы могли его возвращать на дату (тут собственно и возникает нечто вроде полупроводки, но угол зрения несколько другой не что сродни ведению истории изменения значения и способы хранения здесь могут быть весьма различны т.к. ООБД в этом нам предоставляют большой выбор)... В такой структуре мы можем легко отвечать на вопрос по поводу суммы на счете, оборотов по счету (один остаток минус другой). Проблемы возникают при проведение документов задним числом (на мой взгляд тут ничего не разрешимого нет), трудно ответить на вопрос о том какие проводки сформировал документ но мы можем сказать какие счета он изменил и на сколько, не разрешимой проблеммой в данной структуре является ответ на вопрос каая сумма была переданна с одного счета на другой... Вот такие вот мысли на тему :)