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

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

А в каких тогда случаях, по вашему мнению стоит создать такие итоговые поля с суммами, можно пример ?

т.е. получается, что промежуточные суммы нужны только для повышения скорости выборки, и больше не для чего...?

другой пример:
если например, у меня есть деревянный классификатор таблиц...
тогда как узнать к какому реально типу относится текущая строка в базовом классе... ?

h2ospbА в каких тогда случаях, по вашему мнению стоит создать такие итоговые поля с суммами, можно пример ?

Я согласен со всем выше сказанным,
в поем понимании это всегда компромис между требованиями к скорости выполнения, запросов, отчетов, имеющемяся железе и топологии сетки,
скорости разработки приложения и естественно собственного понимания и опыта

у себя использую остатки
ввиде отдельных данных
1. остатки по счетам-бух,
2 счетам расчетным,
3 остатки в штуках и суммах по складам

сервер р-4 2,3 , 1гиг оперативки, 50 пользователей обычно 15-20работающих

ой да я забыл сказать что типов конструкций - 6 => типов мест также 6....
т.е. это 12 доп полей или 12 запросов...?

т.е. в моём случаи выбы создали доп поля, ведь фактически это тоже самое, что и п3 - остатки мест в штуках количество занятых мест в штуках... ??

h2ospb
я там ошибся 6 запросов с функцией count, хотя не 12...
6 к таблице установленных к-й и 6 к таблице мест в месте продажи...

а по поводу распознования типов
[автор]
если например, у меня есть деревянный классификатор таблиц...
тогда как узнать к какому реально типу относится текущая строка в базовом классе... ?
[/quote]

Как вы распознаёте конкретный тип базового класса в дереве ?

h2ospbой да я забыл сказать что типов конструкций - 6 => типов мест также 6....
т.е. это 12 доп полей или 12 запросов...?

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

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

вот...

нас абсолютно не интересует история... нас интересует количество свободных мест, для поиска и визуального просмотра... типа здесь 6 свободных мест под стенды, и 3 места под фреймы... там вообще 0 своб мест...
когда мы хотим установить конструкцию мы ищем место продажи, где есть свободное место под эту конструкцию, и устанавливаем....

traktor123
Люди чего такая активность ???
Если есть дерево контрагентов например,
persons
Fiz_Faces(persons)
Emps(Fiz_Faces)
Ur_Faces(Persons)
Clients(Ur_Faces)
Firms(Ur_Faces)

Допустим мне нужно вывести список всех сущностей со всеми принадлежащими к ним атрибутами.

Как я буду узнавать, к какому потомку относится текущая строка в persons ?
можно например в persons создать поле person_Type... и указать там реальный конечный тип субьекта(клиент, сеть, сотрудник...)
но что тогда делать если юр лицо у нас может быть и клиентом и также являться сетью ?

тогда меняем структуру:
persons
Fiz_Faces(persons)
Ur_Faces(Persons)

а дальнейшие уровни иерархии, заменяем ролями, прикреплёнными к тоблице
persons как many to one.
Emps
Clients
Firms

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

подскажите идеи плиз!!!!!!

однако