Всем привет от самоучки любителя выносящего мозг десятилетиями )))))
И так друзья, кому не в лом, ответьте рекомендациями.
Много повидал подходов и реализаций. Где то свои пихнул )))
С годами менялось представление о тех или иных вещах....
Так вот, я все это к чему- прошу помощи!

Исходные данные:
1. Очень очень очень ленивый программист самоучка.
2. СУБД Postgre
3. Подобие софта работающего с СУБД пункта 2.
4. Не хочу классов в прямом понимании ))))))))))) как отдельных сущностей - только Query
5. Классы хочу, но лишь как базовые, для предоставления общих свойств и методов и возможно где то реалзизации интерфейсов, для дочерних (зебегая вперед, все вьюшки - фреймы и редакторы формы наследуемые, но это только для моей лени, что свойства и метода по сто раз одни и те же не мутить) -реализовано.
Забегая вперед, я да же MVVM реализовал на c#(wpf) но вот не лежит душа и все тут, порыпался порыпался, добился результатов и все... комп неделю не включал домашний )))) вернулся к Delphi.

И так в чем суть то в обще вопросов, а она в логике архитектуры, вот чего мне всегда реально не хватало, так это подобного опыта с нуля.
Что я решил.
1. DataModule , на него кидаю кучки Query (надоели мне все сложные запросы и всяческие FieldByName в последствии), ну допустим справочников. Это чисто плоские..точнее сами запросы плоские, типа Select поля from таблица.
-За чем? - Другие Query, без сложных запросов (если того не требуют, а просто связь отобразить) выполнят не сложный запрос к другим таблицам, а прилукапятся.
И тут первый вопрос, что быстрее, если таблица уже вскрыта в DataModule и сделается лукап нового Query по полю или запрос c присоединением Join, с точки зрения как нагрузки сети , так и (пусть это глупо прозвучит) отображения результата в виде грида клиенту?

2. Вьюшка (не буду заморачивать, тут вопрос не в этом о ее концепции создания) - Frame, таких фреймов может быть много, как с ними совладать я разберусь... допустим он один, допустим это справочник пользователей, у пользователя есть роль, хочу увидеть эту роль по имени - делаю лукап поле (ко вскрытому ранее в datamodule справочнику)

3. Форма редактор, наследница там чего то, где есть ряд свойств и методов ,которые могу передать от вьюшки. Кинул DataSource на форму редактор (без Query), форма редактор на показ инициируется и копирует в Query (виртуальную, созданную в run-time - поле класса, и ее физической datasource (этой формы) присваиваю DataSet в виде этой Query)
-За чем? - Ленив, хочу сказать POST и все и это работает (надоели мне все сложные запросы и всяческие ParamByName в последствии), но только если есть либо точная копия с полями либо скопировать в рантайм )))
Вопрос. Как скопировать поля из одной Query в другую без гемороя, включая Lookup?
всякие там
...
query2.CopyFields(query1)
...
или
...
with query2.FieldDefs.Count-1
....
работает если лукапов нет

нагородил следующий огород, только не смейтесь, не украшал, пробовал разные варики, какой то заработал, кидаую ))))



Может есть какой простой способ ?

kill_zdm,

ну и тут я только TStringField и TIntegerField обработал, так их понятно больше, вот это и ломает )))

edruzenko,

Вы абсолютно в этом уверены? Извините, что спрашиваю, лично не проверял, мне нужно мнение - кто реально исследовал. Вот смотрите, допустим мне необходимо получить данные из связанных таблиц в кол-ве 10+ , т.е. 10+ Join, тут и запрос громоздкий ну это ладно и к СУБД напряг + нагрузка на сеть, а если уже вскрыты данные из этих таблиц, которые будут лукапиться и они в ОЗУ живут, разве это не быстрее произойдет ?
Я просто рассуждаю, не уверен абсолютно ))

Gator,

спасибо большое, виноват, исправлюсь

delphinoteskill_zdm,

1. локальный лукап vs северный - всё зависит от...
можно делать и так, и так
в многопользовательской среде наверное лучше серверный, чтобы не обновлять локальные справочники постоянно

3. по сути нужен клон исходного НД (без данных, либо только для редактируемой записи) - там должен быть метод на подобии Clone

1. Конечно серверный менее геморойный я понимаю, с другой стороны при тех же равных, нагрузка возрастает сильно при многопользовтаельской , когда один и тот же справочник к примеру дергается по 100++++ раз , только что бы отобразить связанное с ним имя к примеру по ключу. Как показала практика, справочники в целом меняются не часто, часть из них в обще единожды с начальным заполнением, тут как мне видится необходимо только грамотную валидацию на существующие проверять - ну и волшебную кнопку - обновить данные добавить )))
3 - должен быть но не нашел ((((
повторюсь , я все облазил, кучу всего перепробовал, все копируется кроме лукап полей ((( сдался и начал писать свой огород, может кто реально сталкивался и знает как тот метод зовется )))

Hammerkill_zdm,
Мои 5 копеек
1. Грузить справочники на клиента без разбора = зло
2. Использовать обращение не к таблицам а ко вьюхам (лучше всего индексированным) где есть все джойны какие надо (упаси Боже в этом случае всякие правые, левые всякие другие кроме Inner). Надеюсь что такое индексы и статистика в этом случае рассказывать не стоит?
3. Ты уверен что локап не копируются? Если правильно понял юзаем UniDac? Насколько я помню есть отдельный метод копиравания полей со всякими настройками.

3. Не копируется.. ну или копируется но это все на уровне оперативы, т.е. без запроса - отслежено в DbMonitor. Да, юнидаки, не смог найти я этот метод (((((((((((

вроде вот оно Query1.CopyFields(TDataSet) --- все коприуется кроме лукапов :(

kill_zdmHammerkill_zdm,
Мои 5 копеек
1. Грузить справочники на клиента без разбора = зло
2. Использовать обращение не к таблицам а ко вьюхам (лучше всего индексированным) где есть все джойны какие надо (упаси Боже в этом случае всякие правые, левые всякие другие кроме Inner). Надеюсь что такое индексы и статистика в этом случае рассказывать не стоит?
3. Ты уверен что локап не копируются? Если правильно понял юзаем UniDac? Насколько я помню есть отдельный метод копиравания полей со всякими настройками.

3. Не копируется.. ну или копируется но это все на уровне оперативы, т.е. без запроса - отслежено в DbMonitor. Да, юнидаки, не смог найти я этот метод (((((((((((

вроде вот оно Query1.CopyFields(TDataSet) --- все коприуется кроме лукапов :(


не очень понял, простите, сам вопрос на счет копирования, я думал Вы про переброску данных. В общем - не копируется, уже по другому отвечу. К примеру Query2 имеет 3 поля физически и один лукап -выполнив метод Query1.CopyFields(Query2) по факту только физические скопирует. Count полей после метода отличается ну и при обращении к лукап полю по имени - облом, нет такого.

Hammerkill_zdm,
Мои 5 копеек
1. Грузить справочники на клиента без разбора = зло
2. Использовать обращение не к таблицам а ко вьюхам (лучше всего индексированным) где есть все джойны какие надо (упаси Боже в этом случае всякие правые, левые всякие другие кроме Inner). Надеюсь что такое индексы и статистика в этом случае рассказывать не стоит?
3. Ты уверен что локап не копируются? Если правильно понял юзаем UniDac? Насколько я помню есть отдельный метод копиравания полей со всякими настройками.

2. Вьюшка ни чем не лучше того же запроса с точки зрения производительности, лишь меньший код в Query

kill_zdmHammerkill_zdm,
Мои 5 копеек
1. Грузить справочники на клиента без разбора = зло
2. Использовать обращение не к таблицам а ко вьюхам (лучше всего индексированным) где есть все джойны какие надо (упаси Боже в этом случае всякие правые, левые всякие другие кроме Inner). Надеюсь что такое индексы и статистика в этом случае рассказывать не стоит?
3. Ты уверен что локап не копируются? Если правильно понял юзаем UniDac? Насколько я помню есть отдельный метод копиравания полей со всякими настройками.

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

edruzenkokill_zdm,


kill_zdm что быстрее, если таблица уже вскрыта в DataModule и сделается лукап нового Query по полю или запрос c присоединением Join, с точки зрения как нагрузки сети , так и (пусть это глупо прозвучит) отображения результата в виде грида клиенту?
разумеется join быстрее на порядки.

Дошли руки , проверил.
Схема, повторюсь следующая.
1. В DataModule, Query подгружают необходимые мне справочники для лукапа (плоские запросы к таблицам, которые будут использоваться исключительно для лукапа. При старте системы - живут в оперативе)
2. На вьюшках - фреймы , уже свои Query, которые запрашивают так же плоские данные от сущности, лукапя необходимые для визуальной составляющей поля из смежных таблиц , получая данные из тех самых Query из DataModule уже загруженных.

Результаты:
Заполнил тестовую таблицу 10к записями с ключевкой к трем таблицам
Выполнил Join к трем таблицам наблюдая в DbMonitor UniDac
-0,46 до 0,52
То же самое с лукапами
0,15 до 0,16
Скорость и дельта значительно ниже
Далее понизил на маршрутизаторе себе скорость до 512 кб/с для эксперимента и наглядности (база данных на хосте)
Join вырос катастрофически, а дельта еще более катастрофично, разброс составлять стал порой до минуты.
С лукапами, результат стал еще более впечатлительным - уже не разы , а десятки раз быстрее

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

Может, что пока и упускаю, выслушаю с удовольтсвием.

Я благодарен всем комментаторам, но пока ни кто не убедил.
Дал коллеге попробовать, так сказать для наглядности.. К слову все фреймы вьюшки наследуются от обобщающей, где вся эта движуха происходит, сокращение трудоемкости да же он оценил, впервые увидев и сначала ни чего не понимая.. просто сказал ему - отнаследуйся от класса и реализуй интерфейс .. все.. 90% работы ушло . Всякие кошмарные FieldByName на каждый чих ушли в прошлое.

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

Может, что пока и упускаю, выслушаю с удовольтсвием.

Ты многое упрощаешь.

Идентифицировать надо именно сущность, а не её аттрибуты.
Допустим, Иванова/Петрова в 5-й раз вышла замуж за Сидорова, развелась и взяла девичью фамилию Попандопуло, а потом и пол сменила.

Привязаться к паспорту? Он меняется много раз. К свидетельству ПФР? Кто даст гарантии его постоянства?
Веди свой ключ. А остальные бумажки/пластик считай привязанными аттрибутами. Тут тебе будет и история и актуальная информация на заданный период.

привязка идет по ID юзера!!!
Живет ее Фамилия исключительно в рамках запуска программы, если она 10 раз сменит да же фамилию в течении ОДНОГО дня, это не критично, я лишь буду видеть ее старую фамилию, пока не перезапущу прогу, которая в свою очередь при запуске не перезапросит данные.
к примеру
Users
id=125
Name= Иванова
Pasport_Serias = 4202
.....


Интерисующая_меня_таблица
Интерисующее_меня_поле = 'что -то'
User_id =125

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

что мне это дает

1. Фрейм вьюшка
я лишь добавляю связки, к примеру справочник стран

TframeCountry = class(TModel, IModel)

реализую интерфейс в ней
//передам модели форму редактор, которая в свою очередь назначит все движения фрему ToPPanel где кнопки, удалить, редактировать //и т.д.



2. Модель

тут куча всего, в основном инициализируется форма вызванная , например, из меню как



это схавает модель, которая проверит все фреймы на форме, относящиеся к TModel и вскроет их данные, а так же перехватит фомру редактор и назначит действие
3. пока кривенько но что то типа - на присланной форме ищется модель и инициализируется в пункте 4


4. ищю вьюшку (ну у меня девэкспресс , но можно и на любом гриде отловить его источник)



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

kill_zdm,

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

Gatorkill_zdm2. Вьюшка ни чем не лучше того же запроса с точки зрения производительности, лишь меньший код в QueryОшибаешься.
Это уже однажды скомпилированный запрос, со статистикой, готовым планом исполнения, хинтами и индексами и прочими внусностями.
А в кверике - просто запрос среди других запросов, как правило, новьё для СУБД
Да, согласен, погорячился.

kill_zdmGatorпропущено...
Ошибаешься.
Это уже однажды скомпилированный запрос, со статистикой, готовым планом исполнения, хинтами и индексами и прочими внусностями.
А в кверике - просто запрос среди других запросов, как правило, новьё для СУБД
Да, согласен, погорячился.

Но и плодить вьюшки то же желание особо нет. На мой взгляд они хороши для различных отчетов и т.д., это все то же остается в силе, как и различные триггеры и ХП, я просто заморчоился именно отображением и минимизацией нагрузки ну и плюс мне очень понравилось как лукапы можно юзать в форме радакторе ограничаваясь не сложными INSERT а одним лишь POST