Здравствуйте, Геннадий Васильев, Вы писали:

AVK>>>>>10) Алгоритмы кеширования.
AVK>>>Без этого производительность твоего сервера будет плачевной. А если еще и OO-Relational меппинг наличествует, то производительность без кеша объектов будет просто никакая.
MF>>кеширование? — это ведь использование памяти? или например использование временных таблиц где хранятся уменьшенные выборки для работы с объектами? Все таким мне будет проще об этом думать когда я буду знать как работает мой сервер и что представляют из себя его объекты.

ГВ>Вот тут AVK тоже совершенно прав. Кеширование служит для того, чтобы можно было в каких-то случаях избежать обращений к БД (так что, про временные таблицы — забудь).

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

ГВ>Ключ вот в чём — если обработка объектов выполняется только в памяти, то в худшем случае при групповой операции каждый объект последовательно "поднимается" в память (а это каждый раз — select) и потом отправляется в БД.

А одним селектом для всей группы обойтись нельзя? И притом insert/update в пакетном режиме невозможен, все равно каждый раз процедуру вызывать придется.

ГВ>Производительность усвистит вниз до непотребных величин. Поэтому нужно продумать схему кэширования. Возможно — предварительное чтение объектов, возможно — групповое чтение обрабатываемого набора и такая же групповая запись. Можно найти другие варианты.

ГВ>Кстати, ты прав тоже — это действительно использование памяти. Вопрос в организации этой памяти и взаимодействиях с окружающим контекстом. Чаще всего для этого пользуются пулом (набором) ранее созданных объектов и здесь сразу появляется проблема в поддержке соответствия "кэш==БД", особенно при групповых операциях обновления.

Под пулом, наверное, подразумеваешь объекты не заполненные данными?

Здравствуйте, IT, Вы писали:

IT>Я пока обхожусь там где надо доморощенными средствами, но пока у меня таких место не много это не проблема. А вообще хорошую систему кеширования можно сделать как отдельный компонент даже и вне привязки к апп-серверу, да только вот как всегда времени не хватает

Тогда и начать не с сервера приложений, а независимой компоненты кэша БД<->OO со своими правилами, зависимостями и т.д.

Здравствуйте, kreek, Вы писали:

K>Здравствуйте, mvg_first, Вы писали:

MF>>>>Если честно, то хочу завязаться с SECURITY по самые помидоры, но переживаю как бы не загубило оно мне проект, по скоростным показателям. А какой компромис выбрать — не знаю, ибо не знаю механизмов реализации различных спобов обсуждавшихся ранее. Одно точно, не хочу делать это средствами SQL вернее полностью (частично все таки придется)

K>Генерить запросы к БД на основе метаданных.

ГВ>>>На самом деле, лучше полностью избавиться от необходимости работы с SQL-сервером

K>Наверное, имел ввиду: не делать разграничения доступа средствами БД.

MF>>Да , но как тогда например выбирать перечень объектов видимых клиенту?

K>На основе его метаданных формировать предикат.

Я конечно дико извиняюсь за свою необразованность — но что такое предикат? Особенно в контексте заданного мною вопроса, объясните пожалуйста елси Вас не затруднит

Здравствуйте, mvg_first, Вы писали:

K>>На основе его метаданных формировать предикат.

MF>Я конечно дико извиняюсь за свою необразованность — но что такое предикат? Особенно в контексте заданного мною вопроса, объясните пожалуйста елси Вас не затруднит

Обычный блок WHERE.
По научному:
ПРЕДИКАТ (от лат. praedicatum сказуемое), в узком смысле то же, что свойство; в широком смысле отношение, т. е. свойство нескольких предметов. В логике пропозициональная функция, т. е. выражение с неопределенными терминами (переменными), при выборе конкретных значений для этих терминов преобразующееся в осмысленное (истинное или ложное) высказывание.

Здравствуйте, kreek, Вы писали:

K>Здравствуйте, mvg_first, Вы писали:

K>>>На основе его метаданных формировать предикат.

MF>>Я конечно дико извиняюсь за свою необразованность — но что такое предикат? Особенно в контексте заданного мною вопроса, объясните пожалуйста елси Вас не затруднит

K>Обычный блок WHERE.
K>По научному:
K>ПРЕДИКАТ (от лат. praedicatum сказуемое), в узком смысле то же, что свойство; в широком смысле отношение, т. е. свойство нескольких предметов. В логике пропозициональная функция, т. е. выражение с неопределенными терминами (переменными), при выборе конкретных значений для этих терминов преобразующееся в осмысленное (истинное или ложное) высказывание.
А можно еще и с примером "на пальцах" — относительно формирования предиката для конкретного пользователя. Общий смысл слова я понял — уложить в голове относительно задачи секюрити — немогу

Здравствуйте, mvg_first, Вы писали:

MF>А можно еще и с примером "на пальцах" — относительно формирования предиката для конкретного пользователя. Общий смысл слова я понял — уложить в голове относительно задачи секюрити — немогу

В простом виде абстрагируясь от механизмов авторизации с использованием ролей будет примерно так (хотя все зависит от твоей политики безопасности):
Задача: сотрудник хочет просмотреть журнал счет-фактур.
Ограничения на просмотр (описаны в его метаданных или в роли, в которую он входит):
1. Он имеет доступ на счета только с определенным статусом.
2. .. входящие в его подразделение и дочерние ему.
3. .. исходящие только из его подразделения.
4. и т.д.
На основе этих метаданных и можно сгнерить запрос к БД.

K>Тогда и начать не с сервера приложений, а независимой компоненты кэша БД<->OO со своими правилами, зависимостями и т.д.
Да вот по-моему не надо вообще этого кеша.
Get in — get out, и все.
Сильно сомневаюсь, что этот кеш на масштабируемости хорошо скажется.

K>Только вот как явно задекларировать эти случаи. Имхо, подходит только для метаданных, для реальных бизнес объектов очень тяжело поддерживать кэш. А если будет несколько серверов приложений, и не как элементы кластера, а как полноценные сервера (допустим на каждую географическую точку по серверу), то, что, при изменении кэшируемого объекта в одном — оповещать другие?

Согласен, создание своего кеша — занятие трудное и бессмысленное.
Во всяком случае в MS COM+ предлагается делать все stateless.

Здравствуйте, DMVB, Вы писали:

K>>Тогда и начать не с сервера приложений, а независимой компоненты кэша БД<->OO со своими правилами, зависимостями и т.д.
DMV>Да вот по-моему не надо вообще этого кеша.
DMV>Get in — get out, и все.
DMV>Сильно сомневаюсь, что этот кеш на масштабируемости хорошо скажется.

Для метаданных — он самый раз подходит, проверено. Ну еще некоторые вещи я кэширую на клиенте.

Здравствуйте, kreek, Вы писали:

K>Здравствуйте, mvg_first, Вы писали:

MF>>А можно еще и с примером "на пальцах" — относительно формирования предиката для конкретного пользователя. Общий смысл слова я понял — уложить в голове относительно задачи секюрити — немогу

K>В простом виде абстрагируясь от механизмов авторизации с использованием ролей будет примерно так (хотя все зависит от твоей политики безопасности):
K>Задача: сотрудник хочет просмотреть журнал счет-фактур.
K>Ограничения на просмотр (описаны в его метаданных или в роли, в которую он входит):
K>1. Он имеет доступ на счета только с определенным статусом.
K>2. .. входящие в его подразделение и дочерние ему.
K>3. .. исходящие только из его подразделения.
K>4. и т.д.
K>На основе этих метаданных и можно сгнерить запрос к БД.
Аааа! ну если это и есть предикат, то я именно об этом и думал.

Здравствуйте, Геннадий Васильев, Вы писали:

IT>>Я хочу её дизайнить как максимально производительную.

ГВ>А я — как максимально удобную для дизайна и дальнейшего развития. И одновременно — как максимально производительную.

Я слабо верю в одновременность удобной объектной модели и производительности

Давай попробуем на живом примере. Есть вот такая страница http://www.rsdn.ru/forum/main.aspx. Все данные на ней запрашиваются в реальном времени.

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

Вопрос, какой должна быть модель объектов и как она будет запрашивать данные из базы, чтобы это было максимально удобно и эффективно?

Здравствуйте, IT, Вы писали:

IT>Вопрос, какой должна быть модель объектов и как она будет запрашивать
IT>данные из базы, чтобы это было максимально удобно и эффективно?

Извиняюсь, что вмешиваюсь.
ИМХО объектная модель должна быть удобной для программера.
Запрашиваться данные из БД будут через некоторый класс служебных объектов
и(или) хранимых процедур, позволяющих нам изолировать объекты сервера от
структуры БД. Во время разработки можно будет реализовать все элементарными
запросами — главное, чтобы быстрее сдвинуться с места. Когда (если(а это без
сомнения произойдет)) изделие начнет тормозить преобразуем объекты и(или)
процедуры доступа к БД (наймем крутого запросописателя или обратимся в форумы
RSDN ), а может даже введем дополнительные таблицы с некоторой
избыточной информацией.

Здравствуйте, МихаилС, Вы писали:

МС>ИМХО объектная модель должна быть удобной для программера.

Несомненно.

МС>Запрашиваться данные из БД будут через некоторый класс служебных объектов и(или) хранимых процедур, позволяющих нам изолировать объекты сервера от структуры БД. Во время разработки можно будет реализовать все элементарными запросами — главное, чтобы быстрее сдвинуться с места.

А где объектная модель? Покажите мне объектную модель.

МС>Когда (если(а это без сомнения произойдет)) изделие начнет тормозить преобразуем объекты и(или) процедуры доступа к БД (наймем крутого запросописателя или обратимся в форумы RSDN ), а может даже введем дополнительные таблицы с некоторой избыточной информацией.

Со 100% уверенностью могу сказать, что с таким подходом это начнёт тормозить только у заказчика, когда система будет под нагрузкой, не раньше.

Здравствуйте, IT, Вы писали:

IT>Здравствуйте, МихаилС, Вы писали:

МС>>Запрашиваться данные из БД будут через некоторый класс служебных объектов и(или) хранимых процедур, позволяющих нам изолировать объекты сервера от структуры БД. Во время разработки можно будет реализовать все элементарными запросами — главное, чтобы быстрее сдвинуться с места.

IT>А где объектная модель? Покажите мне объектную модель.

не раздумывая долго об именах что-то вроде

class ForumsManager
{
 ...........
 ForumsInfo GetForumsInfo( LevelOfDetails, ... )
 (или)
 List(любой) GetForumsInfo( LevelOfDetails, ... )
 ...........
}
class ForumsInfo (отсутствует в случае если используется список)
{
   ForumInfoData[]
}
class ForumInfoData
{
  // поля, которые должны быть отображены
}

IT>Со 100% уверенностью могу сказать, что с таким подходом это
IT>начнёт тормозить только у заказчика, когда система будет под
IT>нагрузкой, не раньше.

Да. Я больше писал о системе, которая всегда "под рукой", а не
о платформе, на которой создаются решения для стороннего заказчика.

Здравствуйте, МихаилС, Вы писали:

IT>>А где объектная модель? Покажите мне объектную модель.

МС>не раздумывая долго об именах что-то вроде

Так что всё-таки лучше отдельные объекты или список?

IT>>Со 100% уверенностью могу сказать, что с таким подходом это начнёт тормозить только у заказчика, когда система будет под нагрузкой, не раньше.

МС>Да. Я больше писал о системе, которая всегда "под рукой", а не о платформе, на которой создаются решения для стороннего заказчика.

В этом случае такое допущение можно допустить Но мы в этой теме вроде как обсуждаем универсальное решение на продажу

Здравствуйте, IT, Вы писали:

IT>Так что всё-таки лучше отдельные объекты или список?

В любом случае на каждый форум понадобится отдельный объект, содержащий информацию о нем.
Но это будет объект, который служит _только_ для передачи информации по форуму в рамках
запроса GetForumsInfoList и для него в базе нет соответствия 1:1. Он формируется из двух
таблиц (Forum(s) — Message(s)). Возможно, что где-то кэшируется (но только, если в этом
есть потребность).

IT>В этом случае такое допущение можно допустить Но мы в этой теме вроде как обсуждаем
IT>универсальное решение на продажу

Да. Это я не по теме "вклинился".

Здравствуйте, IT, Вы писали:

МС>>не раздумывая долго об именах что-то вроде
IT>Так что всё-таки лучше отдельные объекты или список?

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

Здравствуйте, МихаилС, Вы писали:

IT>>Так что всё-таки лучше отдельные объекты или список?

МС>В любом случае на каждый форум понадобится отдельный объект, содержащий информацию о нем.
МС>Но это будет объект, который служит _только_ для передачи информации по форуму в рамках запроса GetForumsInfoList и для него в базе нет соответствия 1:1. Он формируется из двух таблиц (Forum(s) — Message(s)).

Т.е. это просто структурка?

МС>Возможно, что где-то кэшируется (но только, если в этом есть потребность).

Вот это тоже интересно, как организовать кешь в данном примере.

Здравствуйте, IT, Вы писали:

IT>Я слабо верю в одновременность удобной объектной модели и производительности

Идеалы — они только в снах встречаются

IT>Давай попробуем на живом примере. Есть вот такая страница http://www.rsdn.ru/forum/main.aspx. Все данные на ней запрашиваются в реальном времени.

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

Ну, скажем так — подобное описание к постановке задачи на объектное проектирование никакого отношения не имеет. Что это за "таблицы"? Знать не знаю такого зверя! Есть классы, объекты и отношения объектов.

IT>Вопрос, какой должна быть модель объектов и как она будет запрашивать данные из базы, чтобы это было максимально удобно и эффективно?

Не максимально, но мне нравится:



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

Значит так, кое-какие пояснения.
1. MessagePlacement связан как минимум с экземпляром одного из двух классов: Reply или TopicHeader.
2. Текст заголовка топика может отличаться от subject-а сообщения.
3. Структура БД и операций с ней выводится из этой схемы (информации для этого достаточно).
4. Во время эксплуатации App-сервер собирает статистику по работе с БД и по необходимости выполняется её оптимизация (это — почти как как всегда) с донастройкой маппинга.
5. Да, чуть не забыл! все классы — persistable.

Вот так или примерно так.

Здравствуйте, kreek, Вы писали:

K>Только вот как явно задекларировать эти случаи. Имхо, подходит только для метаданных, для реальных бизнес объектов очень тяжело поддерживать кэш.

Что ты имеешь ввиду под "задекларировать" и "поддерживать"?

K>А если будет несколько серверов приложений, и не как элементы кластера, а как полноценные сервера (допустим на каждую географическую точку по серверу), то, что,
при изменении кэшируемого объекта в одном — оповещать другие?

Можно и так, если очень хочется. Хотя лучше, наверное, пользоваться репликацией.

K>А одним селектом для всей группы обойтись нельзя? И притом insert/update в пакетном режиме невозможен, все равно каждый раз процедуру вызывать придется.

Зато insert/update возможны в фоновом режиме.

K>Под пулом, наверное, подразумеваешь объекты не заполненные данными?

Не совсем. Под пулом я подразумеваю наборы неиспользуемых объектов.