ztxn

>>Какая из этих структур более предпочтительна для организации программы учета.

Учет подразумевает еще и ведение каких-то преаггрегаций. Запасы, состояния счетов и пр пр.

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

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

Я видел несколько систем, где транзакционные документы сохраняются в трех структурах. 1 — Документы с внешними контрагентами — документы купли/продажи 2) Внутренние документы — перемещения между складами/зонами внутри организации, изменение статуса товара, списания всяческие и пр. 3) Фискальные документы, сиречь чеки. Мне такой подход кажется наиболее подходящим для большинства задач, с которыми мне приходилось сталкиваться.

select name
   ,max(case when phone_type = 'home' then phone end) as home
   ,max(case when phone_type = 'mobile' then phone end) as mobile
from table
group by name

Можно

select * from статьи t
where :n > (select count(*) from статьи s where s.автор = t.автор and s.id<t.id)

Но решение с несколькими запросами с клиента будет куда производительнее.

Возможно тут еще как-то можно применить трюк с переменными…