Здравствуйте VladD2, Вы писали:
VD>У меня есть желание создать конструктор который позволит собирать учетные приложения визуально. Основу этого конструктора представляет несколько доработанная схема представленная выше. Подробнее о планах и идеях можно прочесть здесь: http://www.optim.ru/Software/rus/ascConcept/ascconcept.asp
Влад, у тебя же там ничего про веб-сервисы. В сад... и срочно затачивать концепцию под веб-сервисы
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте George_Seryakov, Вы писали:
A>>А почему должны быть "записи"? Имхо, достаточно одной, в которой мы бы видели счет, с которого берем средства, счет, на который их относим, сумму и время проведения операции. Все это было в той табличке, с которой начался разговор.
GS>Достаточно для учета, недостаточно для рабского воспоизведения принципа двойной записи.
Здравствуйте Tiger, Вы писали:
T>ЭЭЭЭЭЭЭЭЭЭЭ!!!!! Господа шорошие Олл!!!!
Ты чего орешь? К чему столько эмоций?
T>Во первых товарищь из зала весьма верно подметил про аналитики. Т.е. единственное решение (ИМХО конечно) это сделать плоскую таблицу (id_проводки, дебет, кредит, сумма, аналитика1, ... аналитикаN) НО таблица получается громоздкой. В ней всяких пустот образуется немерянно так как разные счета имеют разные аналитики.
А тебе не кажется, что путем дальнейшей нормализации такую таблицу можно привести к набору таблиц, выглядещему более элегантно? Кроме того тут тебе параллельно предлагают тоже очень неплохое решение (вынесение аналитики в план счетов).
T>Дальше хуже. (Ну уж я не говорю о тяжеловестности запросов, в смысле оптимальности выполнения и тяжести создания запросов). А вот то-что количество аналитик оказывается жестко фиксированным это плохо, так как по некоторым сведениям если организация начинает наращивать количество аналитик по счетам то их возрастание происходит экспоненцияльно!!!.
Не должно быть оно фиксированным, оно должно изменяться в ходе работы с системой.
T>А писать динамические запросы которые позволят вам менять количество аналитик это получается такоооооой изврат, что самому тошно становиться.
Поясни, что ты имеешь в виду?
T>Есть некое шестое^2 чувство что просто структура таблиц должна быть совсем не такой как в классическом варианте плоского журнала проводок. Но вот какой — сие есть тайна!!! По крайне мере пока. Это и заставляет искать хоть что-то (любую информацию).
Может быть, стоит начать с Дейта? Или чего-нибудь подобного?
T>И кстати!!! Еще есть проблема откатов и удалений из журнала проводок. Воооот проблемка. мне начинет казатся, что здесь уже начинает играть роль фундаментальные ограничения баз данных — то что кортежи (записи) должны быть взаимонезависимы. А если мы хотим изменить историю проводок задним числом то получаем что у нес "поедет" все последующая история.
Какая история? Куда поедет? Тебе тут уже написали про материализованные представления.
Здравствуйте VladD2, Вы писали:
VD>Я так понимаю у тебя главное непонимание в том как в приведенном варианте аналитику считать. Да? Тогда продаю часть своих идей образца 1996 года...
VD>...
VD>ExtRef – список дополнительных аналитических признаков. Может быть любой длинны. В реальной учетной системе нужно описать какие и сколько справочных значений можно присвоить к Z-объекту каждого типа.
Нечто подобное приходило и в мою голову.
Была идея хранить аналитические признаки в одной таблице, что-то вроде
id
entry_id
analytic_value_id
т.е. если какому-то счету, участвующему в проводке, соответствует N аналитических признаков, то в этой таблице появляется N записей. Это дает неограниченное количество аналитических признаков, но работать с такой таблицей крайне не удобно. Т.е. получалось что SQL запросы с группировкой нужно формировать динамически, что не есть хорошо.
VD>Анализируем ошибки... Хотя зачем? Ты и так все верно подметил. Но (!) почему ты считаешь, что аналитические признаки должны быть отделены от дебета и кредита?
Что имеется ввиду под неотделимостью??? Например можно создать справочник (таблицу) аналитик и сопоставлять id баолансового счета id аналитики. Эо называется неотделимостью?
VD>Это главная твоя ошибка и большинство ваятелей бухгалтерий (ну, и КИС). Бьюсь об заклад, что смогу переформулировать любую постановку задачи, так чтобы в проводке были только дебетовые и кредитовые аналитические признаки! (подсказка: обычно это делается добавлением промежуточных проводок).
Интересная мысль — надо ее повертеть. (Тут могут быть проблемы с целостносью данных)
VD>Теперь просто воспользуемся опытом и знаниями из умных книжек...
А вот и интересно спросить КАКИХ книжек (учитывая что с Дейтом все в порядке ИМХО). Вот как раз и интересна специализированные книжки по данной теме. Я просто абсолютно убежден что таковые должны быть (уж на буржуйском точно)
Применим принцип денормализации и получим не одну убогую таблицу, а две (и не убогие). Первая описана выше, но вместо дебетового и кредитового счета введем понятие дебетового и кредитового аналитического признака. В 1996 я назвал их Z-объектами (почему Z? Об этом я скажу потом...). Вторая таблица содержит эти самые аналитические Z-объекты (и их атрибуты).
VD>Z-объект – это минимальный аналитический признак на котором можно подбить микро-баланс, т.е. все операции (проводки) по такому объекту рано или поздно в сумме дадут нуль (от сюда и Z-объект). Так как меньше этой операции в системе не регистрируется, то можно смело оставить в проводке только дебетовый и кредитовый Z-объект. Зато на Z-объекты можно навесить аналитику любого уровня сложности. Самым универсальным способом будет добавить еще одну таблицу которая содержит ссылку на Z-объект и список справочных значений. Примерами Z-объектом могут быть: заказ, расчетный счет (или некоторый минимальный признак на этом счет, если ведется аналитика по р.с.), авансовый отчет и много другое.
VD>Ниже приведена упрощенная ER-схема БД реализующей описанные выше принципы. VD>ftp://ftp.optim.ru/pub/Tests/ZObj/shem1.GIF VD>Tran – таблица проводок. VD>ZObj – Z-объекты. (Tran имеет две ссылки на ZObj, так как Z-объекты проходят и по дебету и по кредиту проводки... шо поделаешь та самая двойная запись ;) ). VD>ZObjType – типы Z-объектов. VD>Ref – справочники. Здесь представлено упрощенно. Реально это отдельная песня (считайте, что вместо этой таблицы присутствует крутая структура хранящая все справочники учетной системы, а это их инкапсулированное представление). VD>ExtRef – список дополнительных аналитических признаков. Может быть любой длинны. В реальной учетной системе нужно описать какие и сколько справочных значений можно присвоить к Z-объекту каждого типа.
VD>У меня есть желание создать конструктор который позволит собирать учетные приложения визуально. Основу этого конструктора представляет несколько доработанная схема представленная выше. Подробнее о планах и идеях можно прочесть здесь: http://www.optim.ru/Software/rus/ascConcept/ascconcept.asp
VD>Если кому интересно, то пишите мы открыты для сотрудничества.
Подытоживая предложенное:
1) Большое спасибо
2) Идеи интересные, надо их смоделировать. Сейчас, с наскоку не могу ничего сказать. Надо над ними помидитировать и посоветоваться с духом компьютера ;)
3) По поводу сотрудничества идея интересная, тоже надо обдумать как. Так как большой этап уже сделан
4) Вопрос с откатами и удалениями....
Здравствуйте IT, Вы писали:
IT>Здравствуйте VladD2, Вы писали:
VD>>У меня есть желание создать конструктор который позволит собирать учетные приложения визуально. Основу этого конструктора представляет несколько доработанная схема представленная выше. Подробнее о планах и идеях можно прочесть здесь: http://www.optim.ru/Software/rus/ascConcept/ascconcept.asp
IT>Влад, у тебя же там ничего про веб-сервисы. В сад... и срочно затачивать концепцию под веб-сервисы
А-га. И конвертацию всего что под руку попало в XML.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте Willi, Вы писали:
W>Нечто подобное приходило и в мою голову. W>Была идея хранить аналитические признаки в одной таблице, что-то вроде
W>id W>entry_id W>analytic_value_id
W>т.е. если какому-то счету, участвующему в проводке, соответствует N аналитических признаков, то в этой таблице появляется N записей. Это дает неограниченное количество аналитических признаков, но работать с такой таблицей крайне не удобно. Т.е. получалось что SQL запросы с группировкой нужно формировать динамически, что не есть хорошо.
1. Уменьшили количество id.
2. Несколько более хитро формировали запросы. Вообще это тема для отдельной (и довольно большой) статьи. Главное для решения этой проблемы сломать сложившиеся стереотипы и смотреть на аналитические признаки как на список полиморфных отрибутов. Т.е. z-объект — это объект некоторого класса, а справочные значения — это набор атрибутов определяемый классом z-объекта. Далее все становится довольно просто. Наша задача заключается в отборе z-объект в сответсвтвии с ограничениями накладываемыми на тип и значения атрибутов и последующем суммировании (агрегировании) результатов. Т.е. взгляд на учет шиворот-навыворот (в ОО-стиле). Правда тут приходится отходить от канонов реляционных СУБД и отрабатывать логику полиморфизма на среднем слое (или на триггерах).
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте Tiger, Вы писали:
VD>>Анализируем ошибки... Хотя зачем? Ты и так все верно подметил. Но (!) почему ты считаешь, что аналитические признаки должны быть отделены от дебета и кредита? T>Что имеется ввиду под неотделимостью???
В "единственном" решении аналитические признаки были перечислены внутри проводки, т.е. они не были привязаны к дебету или кредиту, а являлись отдельными признаками (признаками проводки). Это и приводило к негибкости и отсутствию нормальной мат.модели.
T>Например можно создать справочник (таблицу) аналитик и сопоставлять id баолансового счета id аналитики. Эо называется неотделимостью?
В моей концепции есть понятие минимального аналитического признака (Z-объекта) группирующего вокруг себя необходимые аналитические признаки. Бухгалтерский счет это всего лишь один из них. Причем фиксированный (постоянно существующий). Я бы задал его как отдельное поле в таблице Z-объектов.
VD>>Это главная твоя ошибка и большинство ваятелей бухгалтерий (ну, и КИС). Бьюсь об заклад, что смогу переформулировать любую постановку задачи, так чтобы в проводке были только дебетовые и кредитовые аналитические признаки! (подсказка: обычно это делается добавлением промежуточных проводок).
T>Интересная мысль — надо ее повертеть. (Тут могут быть проблемы с целостносью данных)
Нет. Здесь проблем с целостностью не возникает. Проблемы с ней возникают во второй части марлизонского балета... когда приходится создавать универсальный список аналитики. Там придется пописать бизнес логики (вернее даже не бизнес, а прикладной), но это с лихвой окупается (за счет немереной гибкости). Вообще главное в моей концепции смотреть на проводки не как на документы (!), а как на минимальные транзакции из которых складывается граф учета на предприятии. Документы же формируются на базе Z-объектов проводок и атрибутов Z-объектов (хотя первичные документы типа платежки или кассового ордера один к одному отражаются на проводку).
VD>>Теперь просто воспользуемся опытом и знаниями из умных книжек... T>А вот и интересно спросить КАКИХ книжек (учитывая что с Дейтом все в порядке ИМХО). Вот как раз и интересна специализированные книжки по данной теме. Я просто абсолютно убежден что таковые должны быть (уж на буржуйском точно)
Книжки по основам БД? Да их море. Почти везде разбираются вопросы нормализации данных и построения эффективных решений. Ну, а книжек по проектированию учетных решений, да еще таких чтобы били действительно полезны я не встречал...
T>4) Вопрос с откатами и удалениями....
Это чисто технический вопрос. Его можно даже (частично) решать средствами некоторых СУБД (например, Oracle 9i поддерживает партишоны которые видны только определенному кругу людей. В конце моделирования все изменения можно откатить или принять. Можно организовывать лог отката, и т.п. Но по своей практике скажу, что лучше потратить время на проработку учетной схемы, отдача будет бОльшая.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте VladD2, Вы писали:
VD>Здравствуйте Willi, Вы писали:
W>>Нечто подобное приходило и в мою голову. W>>Была идея хранить аналитические признаки в одной таблице, что-то вроде
W>>id W>>entry_id W>>analytic_value_id
W>>т.е. если какому-то счету, участвующему в проводке, соответствует N аналитических признаков, то в этой таблице появляется N записей. Это дает неограниченное количество аналитических признаков, но работать с такой таблицей крайне не удобно. Т.е. получалось что SQL запросы с группировкой нужно формировать динамически, что не есть хорошо.
VD>1. Уменьшили количество id. VD>2. Несколько более хитро формировали запросы. Вообще это тема для отдельной (и довольно большой) статьи. Главное для решения этой проблемы сломать сложившиеся стереотипы и смотреть на аналитические признаки как на список полиморфных отрибутов. Т.е. z-объект — это объект некоторого класса, а справочные значения — это набор атрибутов определяемый классом z-объекта. Далее все становится довольно просто. Наша задача заключается в отборе z-объект в сответсвтвии с ограничениями накладываемыми на тип и значения атрибутов и последующем суммировании (агрегировании) результатов. Т.е. взгляд на учет шиворот-навыворот (в ОО-стиле). Правда тут приходится отходить от канонов реляционных СУБД и отрабатывать логику полиморфизма на среднем слое (или на триггерах).
Все это конечно очень здорово (без всякой иронии).
Но вот простой пример, я хочу получить баланс, причем не просто по счетам, но и с группировкой по аналитикам. Что-то вроде:
Товары на складе 1000
Продукты питания 200
Вобла 50
Пиво "Lowenbrau" 150
Одежда 400
Джинсы 250
Майки 150
Обувь 400
Кроссовки 200
Ласты на каблуках 200
Здесь
"Товары на складе" — это счет,
"Продукты питания", "Одежда", "Обувь" — аналитики типа "Вид товара"
все остальное — аналитики типа "Товар"
SELECT
SUM( entry_volume )
...
GROUP BY
account_id,
analytic_0_id
analytic_1_id
...
analytic_N_id
мы тут же получем нужный нам результат.
Но такая таблица будет наполовину или даже больше (зависит от N) пустой, да и вообще криво как-то смотрится.
Но если значения аналитик хранить так как я писал раньше
tblEntries
----------
entry_id
entry_volume
account_id
tblEntryAnalytics
----------
id
entry_id
analytic_id
то я ума не приложу как тут итоговые запросы строить.
Здравствуйте VladD2, Вы писали:
VD>Книжки по основам БД? Да их море. Почти везде разбираются вопросы нормализации данных и построения эффективных решений. Ну, а книжек по проектированию учетных решений, да еще таких чтобы били действительно полезны я не встречал...
Влад, а может, посоветушь наиболее толковые книжечки по БД, окромя Дейта, конечно же. А то я одной из частей своего тела чую, что маловато у меня знаний для решения задач подобного рода.
Здравствуйте alexm1202, Вы писали:
A>Здравствуйте George_Seryakov, Вы писали:
A>>>А почему должны быть "записи"? Имхо, достаточно одной, в которой мы бы видели счет, с которого берем средства, счет, на который их относим, сумму и время проведения операции. Все это было в той табличке, с которой начался разговор.
GS>>Достаточно для учета, недостаточно для рабского воспоизведения принципа двойной записи.
A>Так тебе шашечки или ехать?
Ни того ни другого, к счастью. Но меня начинает забавлять дискуссия, развернувшаяся вокруг такого, в общем-то, тривиального утверждения, что двойной учет — это намеренная денормализация.
А кто помнит, сколько есть нормальных форм? Может перечислить? Привести примеры? Показать типичные (для форм данной нормальности) нарушения целостности?
A>BR, Alex.
Здравствуйте Willi, Вы писали:
VD>>Книжки по основам БД? Да их море. Почти везде разбираются вопросы нормализации данных и построения эффективных решений. Ну, а книжек по проектированию учетных решений, да еще таких чтобы били действительно полезны я не встречал...
W>Влад, а может, посоветушь наиболее толковые книжечки по БД, окромя Дейта, конечно же. А то я одной из частей своего тела чую, что маловато у меня знаний для решения задач подобного рода.
Здравствуйте George_Seryakov, Вы писали:
GS>>>Достаточно для учета, недостаточно для рабского воспоизведения принципа двойной записи.
A>>Так тебе шашечки или ехать?
GS>Ни того ни другого, к счастью. Но меня начинает забавлять дискуссия, развернувшаяся вокруг такого, в общем-то, тривиального утверждения, что двойной учет — это намеренная денормализация.
А ты не мог бы обосновать это тривиальное утверждение, если тебе не трудно?
GS>А кто помнит, сколько есть нормальных форм? Может перечислить? Привести примеры? Показать типичные (для форм данной нормальности) нарушения целостности?
Я так понимаю, что вопрос риторический и ты намекаешь на то, что люди, принимающие участие в обсуждении слабо знакомы с реляционной теорией и принципами проектирования реляционных БД? Если так, то ты не мог бы пояснить, как ты пришел к такому заключению?
Здравствуйте alexm1202, Вы писали:
A>Здравствуйте George_Seryakov, Вы писали:
GS>>>>Достаточно для учета, недостаточно для рабского воспоизведения принципа двойной записи.
A>>>Так тебе шашечки или ехать?
GS>>Ни того ни другого, к счастью. Но меня начинает забавлять дискуссия, развернувшаяся вокруг такого, в общем-то, тривиального утверждения, что двойной учет — это намеренная денормализация.
A>А ты не мог бы обосновать это тривиальное утверждение, если тебе не трудно?
Да ты его сам обосновал. "По одному счету и по другому счету". Или кто там определение двойной записи приводил?
GS>>А кто помнит, сколько есть нормальных форм? Может перечислить? Привести примеры? Показать типичные (для форм данной нормальности) нарушения целостности?
A>Я так понимаю, что вопрос риторический и ты намекаешь на то, что люди, принимающие участие в обсуждении слабо знакомы с реляционной теорией и принципами проектирования реляционных БД? Если так, то ты не мог бы пояснить, как ты пришел к такому заключению?
Нет-нет, я никого не оцениваю. Причем ответы на эти вопросы я и сам не знаю, с трудом первые три могу сообразить, но какая из третьих — уже не догоняю. Но зато знаю, где посмотреть про это. Баркера надо читать! Ну, или спросить у тех, кто знает.
Здравствуйте George_Seryakov, Вы писали:
GS>>>Ни того ни другого, к счастью. Но меня начинает забавлять дискуссия, развернувшаяся вокруг такого, в общем-то, тривиального утверждения, что двойной учет — это намеренная денормализация.
A>>А ты не мог бы обосновать это тривиальное утверждение, если тебе не трудно?
GS>Да ты его сам обосновал. "По одному счету и по другому счету". Или кто там определение двойной записи приводил?
Я приводил. И я ей-богу не догоняю, о чем ты говоришь. Давай еще раз. Принцип двойной записи гласит: "Если средства где-то появились, то значит где-то они исчезли. И наоборот." Следовательно, фиксируя приход/расход средств на каком-либо счете мы обязаны указать корреспондирующий счет, с/на который эти средства расходуются/приходуются. Если не отвлекаться на детали, в которых, как известно, дьявол :) то для реализации этого принципа подходит такая табличка:
create table operation
(operid int not null,
credit int not null,
debit int not null,
opersum money not null,
operdate datetime not null,
constraint pk_operation primary key (operid))
Я не вижу здесь нарушения 1-3НФ, НФБК, 4-5НФ, как и не вижу возможностей для возникновения каких-либо аномалий обновления, что в свою очередь свидетельствовало бы о нарушении каких-то НФ. Если я не прав, пожалуйста, поправь меня. В противном случае поясни, что ты имеешь в виду под "намеренной денормализацией"? Я эти слова понимаю как осознанный отход от какой-то из перечисленных НФ, сделанный по каким-то соображениям (производительности, например).
GS>>>>Ни того ни другого, к счастью. Но меня начинает забавлять дискуссия, развернувшаяся вокруг такого, в общем-то, тривиального утверждения, что двойной учет — это намеренная денормализация.
A>Я приводил. И я ей-богу не догоняю, о чем ты говоришь. Давай еще раз. Принцип двойной записи гласит: "Если средства где-то появились, то значит где-то они исчезли. И наоборот."
"Каждая хозоперация подлежит отражению в одной и той же сумме одновременно по дебету одного счета и кредиту другого." Твои слова?
Это значит, что где-то есть один счет и другой счет. У них есть кредит с дебетом. И вот в кредите одного и дебите другого (в двух разных местах!) хозоперация и отражается, причем в одной и той же сумме. Про два места ясно? Спорить будешь?
A> не прав, пожалуйста, поправь меня. В противном случае поясни, что ты имеешь в виду под "намеренной денормализацией"? Я эти слова понимаю как осознанный отход от какой-то из перечисленных НФ, сделанный по каким-то соображениям (производительности, например).
Что в двух местах. Намеренная денормализация, сделанная по соображениям контроля и восстановления целостности.
Т.е. журнал транзакций двойной записью не является.
Здравствуйте George_Seryakov, Вы писали:
GS>А кто помнит, сколько есть нормальных форм? Может перечислить? Привести примеры? Показать типичные (для форм данной нормальности) нарушения целостности?
Ты путаешь понятия нормализации/нормальной формы и целостности данных. В не полностью нормализованных таблицах всего лишь происходит дублирование данных которое в конце концов может привести к нарушению целостности, но все же это не одно и тоже.
А про то, что можно делать учетные системы с прилично нормализованными таблицами и в тоже время использовать принцып двойной записи я тебе уже показал рашьше. Если с чем-то не согласен, так сформулируй с тем, а так получается разговор с глухим.
PS
100% нормализация вещь вообще зачастую избыточная...
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте George_Seryakov, Вы писали:
A>>А ты не мог бы обосновать это тривиальное утверждение, если тебе не трудно?
GS>Да ты его сам обосновал. "По одному счету и по другому счету". Или кто там определение двойной записи приводил?
Извини, но это демагогия. Тебе вопрос задали (причем не просто так), а ты...
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте George_Seryakov, Вы писали:
A>>Я приводил. И я ей-богу не догоняю, о чем ты говоришь. Давай еще раз. Принцип двойной записи гласит: "Если средства где-то появились, то значит где-то они исчезли. И наоборот."
GS>"Каждая хозоперация подлежит отражению в одной и той же сумме одновременно по дебету одного счета и кредиту другого." Твои слова?
Мои.
GS>Это значит, что где-то есть один счет и другой счет. У них есть кредит с дебетом. И вот в кредите одного и дебите другого (в двух разных местах!) хозоперация и отражается, причем в одной и той же сумме. Про два места ясно? Спорить будешь?
Буду спорить :) Про два места совсем неясно. Если мы можем отразить операцию по дебету одного счета и кредиту другого не только одновременно, но и в одном кортеже, то я не понимаю как это противоречит приведенному определению? Кредит и дебит при этом действительно будут разными местами :) но эти места — два разных атрибута одного кортежа.
Здравствуйте alexm1202, Вы писали:
GS>>"Каждая хозоперация подлежит отражению в одной и той же сумме одновременно по дебету одного счета и кредиту другого." Твои слова?
A>Мои.
GS>>Это значит, что где-то есть один счет и другой счет. У них есть кредит с дебетом. И вот в кредите одного и дебите другого (в двух разных местах!) хозоперация и отражается, причем в одной и той же сумме. Про два места ясно? Спорить будешь?
A>Буду спорить Про два места совсем неясно. Если мы можем отразить операцию по дебету одного счета и кредиту другого не только одновременно, но и в одном кортеже, то я не понимаю как это противоречит приведенному определению? Кредит и дебит при этом действительно будут разными местами но эти места — два разных атрибута одного кортежа.
А то, что сделана оговорка "в одной и той же сумме" тебя не наводит на мысли? Зачем она нужна если ты свел две записи (смысле бухучета) к одному кортежу (или записи в смысле БД)?
Давай так: вот ссылка на бухгалтерский учебник в которой явно говорится (и показывается на примерах), что двойная запись требует двух записей: http://www.ait.spb.ru/buh_aud/buh004.html. Попробуй найти и представить текст, в котом столь же явно говорилось бы, что для двойной записи хватило бы "отразить операцию по дебету одного счета и кредиту другого не только одновременно, но и в одном кортеже". Найдешь — сравним источники.
В сад... и срочно затачивать концепцию под веб-сервисы 
Если нам не помогут, то мы тоже никого не пощадим.
К чему столько эмоций?
весьма верно подметил про аналитики. Т.е. единственное решение (ИМХО конечно) это сделать плоскую таблицу (id_проводки, дебет, кредит, сумма, аналитика1, ... аналитикаN) НО таблица получается громоздкой. В ней всяких пустот образуется немерянно так как разные счета имеют разные аналитики. 
