Структура vs класс

> Здравствуйте, Кэп, не узнал Вас на этом логине
У меня вроде один логин :)

Просто вместо общего чтения всего

объекта через ORM будут грузиться поля при обращении.

Похоже, что Вы мало работали с СУБД. Или
производительность Вам вообще не нужна.
Если за каждым полем лазить отдельно на сервер,
производительность умрёт.

Почти всегда один JOIN'овый запрос работает дольше двух простых

select person.name, department.name
from person left join
department on person.departmentId=department.Id
where person.birthday=current_date

Во многих клиентских приложениях попытка замены
состоит в том, что department подтягивается
отдельно для каждого person. И запросов
становится не 2, а N+1, где N - число
подходящих по условию person. Будет работать,
скорее всего, намного медленнее, чем join. Другой
вариант - закачать все department-ы в память.
Три затруднения: память может закончиться,
нужно воспроизвести на клиенте структуру
первичного ключа по полю id, нужно
специальным образом отслеживать изменения
в department'ах, сделанные другими пользователями.

Уж в скольких чужих проектах я

ускорял систему, избавляясь от JOIN'ов...

Приведите хотя бы один пример. Какой запрос
был, как Вы его улучшили, какая СУБД, сколько
пользователей в базе одновременно, сколько
записей, были ли индексы для
этого JOIN, как меряли ускорение?

>Другой вариант - закачать все department-ы в память.
Три затруднения: память может закончиться,
нужно воспроизвести на клиенте структуру
первичного ключа по полю id, нужно
специальным образом отслеживать изменения
в department'ах, сделанные другими пользователями.

Вопрос"[не] в тему": неужели до сих пор во всяких там «ормах» нет функционала для вышеизложенной работы с подобными (небольшими и редко изменяемыми) «справочниками» - дабы при первом обращении «кэшировался» весь справочник, а при обращении просто проверялось время последнего обновления?

> неужели до сих пор во всяких там «ормах»
Не знаю. Я не пользуюсь ормами. С моей точки зрения,
вообще, реляционная парадигма мощнее объектной.
Что такое ООП в смысле С++? Это VMT и некоторый
синтаксический сахар, позволяющий делать определённые
преобразования типов. Как-то в переписке я набросал
ООП для С на макросах примерно за два часа.
А что такое SQL сервер? Это декларативный язык
с автоматической оптимизацией запросов (идея,
вообще-то, более глубокая, чем у Пролога, который
тупо пытается решать все задачи перебором в глубину,
другое дело, что сам набор задач получается ограничен,
а Пролог может решать что угодно). Это - автоматические
и полу-декларативные средства обезпечения параллельного
доступа (чего стоит хотя бы механизм автоматического разрешения
клинчей, который есть в любом захудалом SQL сервере).
Это - динамическая среда разработки (alter table =
change-class, а другие языки курят в сторонке, исключая
может быть, Питон) с интроспекцией (например, граф
перекрестных ссылок доступен как реляционная таблица).
Это - какой-никакой, но всё же контроль доступа.
Это - клиент-серверная технология сразу.
Зачем делать слабый интерфейс для мощного средства?
Это то же самое, что найти на свалке выброшенную
дверь, нести её перед собой и смотреть на мир в
замочную скважину, вместо того, чтобы смотреть на него непосредственно. Но, чтобы это понять, я тоже
переболел ORM-ом. Хотя я не пытался писать никакого
кода - достаточно было просто представить себе,
как это могло бы выглядеть, и вопрос сразу отпал
сам собой.

С тех пор я придерживаюсь серверо-центричной модели
написания приложений СУБД и пишу всё, что можно,
на языках хранимых процедур.

Але, Лектор Графоманович, ты хочешь сказать, что, кроме непосредственного обращения к БД, не пользуешься никакими «прослойками»? :)

> Але, Лектор Графоманович
Денис Валерьевич

кроме непосредственного обращения к БД, не пользуешься никакими «прослойками»

Я пишу на Дельфи, там есть компоненты, которые минимально «прослаивают». Писал на Qt - идея была примерно такая же. В целом, согласен, что справочники зачастую имеет смысл кешировать. Но это требует изменений в самой БД. Поэтому, на самом деле, нужен некий генератор кода, основанный на модели БД, который генерит код и для серверной, и для клиентской части. Генерация кода для серверной части органична и я ей пользуюсь. Для клиентской части по большей части использую data driven calculations подход, т.е., генерю не клиентский код, а только лишь метаданные, которые им управляют. Хотя можно было бы генерить и клиентский код. В случае С++ это геморойно, потому что объём сгенерированного кода большой и, даже если аккуратно отслеживать изменения и генерировать только тот код, который действительно изменился, часто будешь попадать на полную пересборку проекта. А пересборка идёт долго, поэтому я от этого быстро отказался. В Дельфи компилятор достаточно быстрый и можно было бы спокойно генерить и клиентский код. Но вообще, кодогенерация - это вещь не лишённая недостатков (сложнее становится само редактирование, т.к. нужно от сгенерённого кода вернуться к исходному). Если бы писал не лиспе - генерировал бы и клиентский код.

>> Але, Лектор Графоманович

Денис Валерьевич

Ну шутка же - чего ты такой серьёзный? =)

По остальному - вопросов нет :)

> Ну шутка же - чего ты такой серьёзный? =)
Ой, и сам не знаю )