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

ГВ>>Какой штиль! А всего-то — человек посмел адекватно оценить действия MS.

IT>Оценка обычно подразумевает аргументы, без аргументов это просто наезд. К тому же, ты видимо не читал его других статей, почитай, очень занимательно

Читал, понравилось. В частности, в статье Fire & Motion, о которой мы говорим — ИМХО, очень здраво сказано, что MS ведёт "огонь прикрытия". А аргументы, так там с полстатьи — сплошняком аргументы "за". В том-то и дело, что он рассматривает как раз те самые микровзаимодйствия в коллективах, которыми можно объяснить "успех" той или иной технологии или смену стратегии компании. ИМХО — очень даже жизненные оценки поведения людей и побуждающих их на то причин.

А почему у тебя такая резко отрицательная оценка?

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

ГВ>А почему у тебя такая резко отрицательная оценка?

Не люблю необоснованных наездов, только и всего. Где-то у него есть статейка целиком и полностью этому посвящённая, тому что MS это мировое зло и не имеет права на существование. Хотя мужик, надо признать грамотный, но видимо на что-то обиженный.

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

ГВ>Ну, скажем так — подобное описание к постановке задачи на объектное проектирование никакого отношения не имеет.

Т.е. ты хочешь сказать, что объекты первичны, а задача которую они решают вторична

ГВ>Что это за "таблицы"? Знать не знаю такого зверя! Есть классы, объекты и отношения объектов.

Есть задача, которую надо решить

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

Само собой

ГВ>1. MessagePlacement связан как минимум с экземпляром одного из двух классов: Reply или TopicHeader.

Ok.

ГВ>2. Текст заголовка топика может отличаться от subject-а сообщения.

Не вопрос.

ГВ>3. Структура БД и операций с ней выводится из этой схемы (информации для этого достаточно).

Структура БД уже определена условиями задачи. Но предложи свой вариант, интересно будет посмотреть.

ГВ>4. Во время эксплуатации App-сервер собирает статистику по работе с БД и по необходимости выполняется её оптимизация (это — почти как как всегда) с донастройкой маппинга.

Вот это самое интересное. Жуть как хочется посмотреть на реализацию.

ГВ>5. Да, чуть не забыл! все классы — persistable.

Тоже не вопрос.

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

Пока не понятно как, давай развивать мысль.

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

ГВ>>Ну, скажем так — подобное описание к постановке задачи на объектное проектирование никакого отношения не имеет.
IT>Т.е. ты хочешь сказать, что объекты первичны, а задача которую они решают вторична

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

ГВ>>Что это за "таблицы"? Знать не знаю такого зверя! Есть классы, объекты и отношения объектов.
IT>Есть задача, которую надо решить

Истинно так, и к таблицам она до поры до времени не имеет никакого отношения.

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

ГВ>>1. MessagePlacement связан как минимум с экземпляром одного из двух классов: Reply или TopicHeader.
IT>Ok.


ГВ>>2. Текст заголовка топика может отличаться от subject-а сообщения.
IT>Не вопрос.
OK

ГВ>>3. Структура БД и операций с ней выводится из этой схемы (информации для этого достаточно).
IT>Структура БД уже определена условиями задачи. Но предложи свой вариант, интересно будет посмотреть.

А вот ничего подобного — структуру БД будем определять после объектной декомпозиции. Повторяю — сначала объектная декомпозиция задачи, потом реализация хранилища в виде реляционной БД. Another way — is a wrong way! Maybe.

ГВ>>4. Во время эксплуатации App-сервер собирает статистику по работе с БД и по необходимости выполняется её оптимизация (это — почти как как всегда) с донастройкой маппинга.
IT>Вот это самое интересное. Жуть как хочется посмотреть на реализацию.

Ты себе представляешь объём подобного описания? Нет уж, IT, извини. Я тут и напостил достаточно много, почти приблизившись к раскрытию своих (и не только) know-how. Желающие могут додумать дальше, пуcть ищут свои пути. Заодно — это очень помогает в интеллектуальном развитии и переоценке некоторых ценностей. А посмотреть на реализцию... ну, следите за прессой.

ГВ>>5. Да, чуть не забыл! все классы — persistable.
IT>Тоже не вопрос.
OK

IT>Пока не понятно как, давай развивать мысль.
Только не сейчас и уж тем более — не в форуме.

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

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

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

Понимаю, объектная модель для тебя первична. Ok, посмотрим что из этого получится.

ГВ>>>3. Структура БД и операций с ней выводится из этой схемы (информации для этого достаточно).
IT>>Структура БД уже определена условиями задачи. Но предложи свой вариант, интересно будет посмотреть.
ГВ>А вот ничего подобного — структуру БД будем определять после объектной декомпозиции. Повторяю — сначала объектная декомпозиция задачи, потом реализация хранилища в виде реляционной БД. Another way — is a wrong way! Maybe.

Это хорошо что ты поставил смайлики и употребил наречие, означающее сомнение

ГВ>>>4. Во время эксплуатации App-сервер собирает статистику по работе с БД и по необходимости выполняется её оптимизация (это — почти как как всегда) с донастройкой маппинга.
IT>>Вот это самое интересное. Жуть как хочется посмотреть на реализацию.
ГВ>Ты себе представляешь объём подобного описания?

Естественно, исходные тексты этой задачи (без формирования html) помещаются на одну печатную страницу Могу показать. Причём моя реализация ни чуть не менее объектна твоей.

ГВ>Нет уж, IT, извини. Я тут и напостил достаточно много, почти приблизившись к раскрытию своих (и не только) know-how.

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

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

Спасовал, короче. В приципе, правильно. Ты наверное уже понял к чему я клоню

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

В общем, если спустится с облачков Буча на землю, то система окажется не живая.

В дополнение. Есть две ошибки, которые допускают начинающие проектировщики. Первая, попытка сделать всё максимально универсальным и очень объектным. Вторая, игнорирование при проектировании вопросов организации структуры базы данных, с которых в общем-то нужно всегда начинать. Непонимание этого — это big mistake, просто huge.

При этом, не пойми меня правильно, я совсем не против ООП, я всеми конечностями за. Но я пытаюсь поставить этот подход на службу моим задачам, а не бездумно служить ему самому.

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

Мой ответ, в основном, предназначен для mvg_first.

ГВ>>>>3. Структура БД и операций с ней выводится из этой схемы (информации для этого достаточно).
IT>>>Структура БД уже определена условиями задачи. Но предложи свой вариант, интересно будет посмотреть.
ГВ>>А вот ничего подобного — структуру БД будем определять после объектной декомпозиции. Повторяю — сначала объектная декомпозиция задачи, потом реализация хранилища в виде реляционной БД. Another way — is a wrong way! Maybe.

IT>Это хорошо что ты поставил смайлики и употребил наречие, означающее сомнение
Ну, не сомневаются только сумасшедшие и те кто не потеет.

ГВ>>>>4. Во время эксплуатации App-сервер собирает статистику по работе с БД и по необходимости выполняется её оптимизация (это — почти как как всегда) с донастройкой маппинга.
IT>>>Вот это самое интересное. Жуть как хочется посмотреть на реализацию.
ГВ>>Ты себе представляешь объём подобного описания?

IT>Естественно, исходные тексты этой задачи (без формирования html) помещаются на одну печатную страницу Могу показать. Причём моя реализация ни чуть не менее объектна твоей.

Да, значит, ты не представляешь о чём речь... досадно.

ГВ>>Нет уж, IT, извини. Я тут и напостил достаточно много, почти приблизившись к раскрытию своих (и не только) know-how.
IT>Правильно, думаю, что это лучше никому не показывать и вообще об этом не рассказывать

До чего же нравится мне твоя самоуверенность. Ну просто достойно упоминания в анналах.

ГВ>>Резюмируя, могу тебе немного подсказать, где искать — начни с того, что я написал в первой части этого постинга относительно постановки задачи. Да, кстати, можешь считать, что я вышел из спора некорректным образом.
IT>Спасовал, короче. В приципе, правильно. Ты наверное уже понял к чему я клоню

Естественно. Только не спасовал — мы с тобой играли на разных полях. Или ты думал что я на "слабо" поведусь? Скажу больше — я и с самого начала догадывался о такой развязке. Оставалась небольшая вероятность того, что ты или кто-нибудь другой начнёт задавать интересные вопросы, касающеся "зачем" и "почему" но этого не случилось... а жаль.

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

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

IT>что затрудняет её применение совместно с лоудбалансерами, либо в ней будет необходимо реализовать неслабую систему синхронизации, что заметно всё усложнит. Кроме того реализация подобной схемы потребует нескольких человеко-месяцев, вместо нескольких часов работы, включая оптимизацию запроса.

Ну что же, частично ты прав. Только есть одна недоработка — App-серверы ради организации форумов и одного запроса обычно не пишут. Хотя, мне было бы очень интересно узнать, каким образом обобщается твой подход на случай, ну, скажем, системы управления складом? Или для простоты возьмём более абстрактно: 170 таблиц, 600 запросов, из них, ну, скажем, 55 — групповые обновления, а ещё 80 — просто обновления для 2-3 таблиц. Да, ещё добавим к этому, что на 10 таблицах организованы древовидные классификаторы, которые участвуют в 50 запросах из указанных шестисот. Прикинешь цифру в человеко-годах? Да, ещё учтём, что в среднем в системе добавляется 5 новых запросов в месяц, 2 запроса трансформируется также ежемесячно, ещё 4 таблицы + 10 запросов появляются каждый квартал, а прогнозируемый жизненный цикл до полной замены — 7 лет. Как там насчёт сопровождения?

IT>В общем, если спустится с облачков Буча на землю, то система окажется не живая.

У Буча не такие уж и далёкие облачка. Всё зависит от высоты полёта.

IT>В дополнение. Есть две ошибки, которые допускают начинающие проектировщики. Первая, попытка сделать всё максимально универсальным и очень объектным. Вторая, игнорирование при проектировании вопросов организации структуры базы данных, с которых в общем-то нужно всегда начинать. Непонимание этого — это big mistake, просто huge.

Не спорю. Про структуру БД забывать вредно для здоровья системы. И разработчиков — нередко тоже.

[Внутренний голос: Скоро термин "не пойми меня правильно" войдёт в десятку наиболее многотрактуемых на RSDN. ]
IT>При этом, не пойми меня правильно, я совсем не против ООП, я всеми конечностями за. Но я пытаюсь поставить этот подход на службу моим задачам, а не бездумно служить ему самому.

Я в этом и не сомневался, IT. Кстати, представь себе — текстуально я того же мнения об ООП что и ты. Весь прикол этой ветки в том, что я отвечал тебе несколько не в том ключе, который ты от меня ожидал. Но ключ был задан исходной темой топика. Не находишь, что логичным было бы ожидать что любая тема, возникающая здесь, будет развиваться в контексте App-серверов?

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

При этом ты с ходу был готов контраргументировать любые мои построения тем, что эта узкая задача решается более компактно без App-сервера, нежели App-сервер под задачу (кастрированный, кстати) + решение задачи. Кто бы спорил! Из пушки-то по воробьям... Но App-серверы делают-то далеко не ради простейших задач. От твоего внимания ускользнуло, что задача выбрана ошибочно, и кстати я обратил твоё внимание на этот прокол. Улавливаешь? Для перемещения на большие расстояния нужны самолёты, а "через дорогу" можно пройти и пешком. Но это не означает, что нужно на десять тысяч км топать ногами. Это весьма софистичный (и демагогичный, кстати) метод доказательства своей правоты (специально обращаю внимание mvg_first на это место). А силлогизм, лежащий в его основе не имеет решения, да и силлогизмом, вобщем-то не является. Силлогизм таков. Посылка А: данную маленькую задачу можно решить простым способом за час. Посылка Б: App-сервер делается для сложных задач. Что из этого следует? Да то, что посылка А попросту неуместна в контексте данного топика.

Мне, в свою очередь, оставалось сказать только то, что я уже сказал — выкатить объектную модель и посмотреть на реакцию аудитории, коя оказалась по сути — нулевой. Ну, было бы странно ожидать чего-то иного на 15-м уровне вложенности. Ещё попытался сместить дискуссию в конструктивное русло, тоже, увы, не вышло...

Кстати (снова для mvg_first), следующий шаг "разгромщика" (домашнее задание 1. придумайте для него логичный эпитет, 2. откажитесь от этого эпитета, как от характеристики личности, эпитеты — только для характеристики доводов!) после такого "показательного" разгрома соперника — требование делать всё так, как он говорит. Без всяких там App-серверов и прочих изысков... Впрочем это возможно только если "жертва" не успевает вовремя сориентироваться в пространстве.

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

IT>>Естественно, исходные тексты этой задачи (без формирования html) помещаются на одну печатную страницу Могу показать. Причём моя реализация ни чуть не менее объектна твоей.

ГВ>Да, значит, ты не представляешь о чём речь... досадно.

Да куда нам деревенским

ГВ>>>Нет уж, IT, извини. Я тут и напостил достаточно много, почти приблизившись к раскрытию своих (и не только) know-how.
IT>>Правильно, думаю, что это лучше никому не показывать и вообще об этом не рассказывать
ГВ> До чего же нравится мне твоя самоуверенность. Ну просто достойно упоминания в анналах.

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

ГВ>Естественно. Только не спасовал — мы с тобой играли на разных полях. Или ты думал что я на "слабо" поведусь? Скажу больше — я и с самого начала догадывался о такой развязке. Оставалась небольшая вероятность того, что ты или кто-нибудь другой начнёт задавать интересные вопросы, касающеся "зачем" и "почему" но этого не случилось... а жаль.

Я у тебя конкретно спросил как. Ты сказал, что мол долго объяснять, ноу-хау и пр. Разве не так.

ГВ>Кстати, коль не секрет, а синглетоны ты откуда взял? Я вроде о них даже не упоминал? Попрошу тебя ответить в форуме хотя бы на этот пункт, на остальную часть поста можешь не отвечать.

Разве нет? Значит я что-то попутал. В любом случае твоя модель стейтфул, без пары синглетонов там не обойтись.

ГВ>Ну что же, частично ты прав. Только есть одна недоработка — App-серверы ради организации форумов и одного запроса обычно не пишут.

Это скорее зависит от нагрузки на этот самый форум.

ГВ>Хотя, мне было бы очень интересно узнать, каким образом обобщается твой подход на случай, ну, скажем, системы управления складом?

Сколько наименований номенклатуры? Примерный приход, расход в день? Выписка? Сколько поставщиков, потребителей? Осуществляется ли электронный обмен данными с поставщиками потребителями или всё ручками? Территориальная распределённость системы, синхронизация данных? Импорт/экспорт данных из/в бухгалтерию или всё в реальном времени? И т.п. Это всё гораздо интереснее чем:

ГВ>Или для простоты возьмём более абстрактно: 170 таблиц, 600 запросов, из них, ну, скажем, 55 — групповые обновления, а ещё 80 — просто обновления для 2-3 таблиц. Да, ещё добавим к этому, что на 10 таблицах организованы древовидные классификаторы, которые участвуют в 50 запросах из указанных шестисот. Прикинешь цифру в человеко-годах? Да, ещё учтём, что в среднем в системе добавляется 5 новых запросов в месяц, 2 запроса трансформируется также ежемесячно, ещё 4 таблицы + 10 запросов появляются каждый квартал, а прогнозируемый жизненный цикл до полной замены — 7 лет. Как там насчёт сопровождения?

Всё это совсем не показатель крутизны системы. Поверь мне Я делал склад, который держал (может и сейчас держит) несколько крупных предприятий. Всё нормально, такого количества таблиц мне не надо было. Сейчас я работаю над системой, которая покруче описанной тобой и моя задача сделать её проще, гораздо проще чем то что описал ты. Там где есть 10 таблиц оставить 3, там где есть древовидные структуры попытаться от них избавиться, по-крайней мере это нужно сделать в рабочих таблицах, и т.д. Т.е. сделать систему проще, компактнее, быстрее, надёжнее и одновременно гибче.

ГВ>[Внутренний голос: Скоро термин "не пойми меня правильно" войдёт в десятку наиболее многотрактуемых на RSDN. ]

Это старый прикол, копирайт не мой

ГВ>Я в этом и не сомневался, IT. Кстати, представь себе — текстуально я того же мнения об ООП что и ты. Весь прикол этой ветки в том, что я отвечал тебе несколько не в том ключе, который ты от меня ожидал. Но ключ был задан исходной темой топика. Не находишь, что логичным было бы ожидать что любая тема, возникающая здесь, будет развиваться в контексте App-серверов?

Мы о них и говорим.

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

1. Ты в праве предложить свою.
2. Это задача которую нужно решать. Наверняка подобных задач в твоём складе вагон и маленькая тележка.

ГВ>При этом ты с ходу был готов контраргументировать любые мои построения тем, что эта узкая задача решается более компактно без App-сервера, нежели App-сервер под задачу (кастрированный, кстати) + решение задачи.

Естественно, задача была подобрана специально что-бы показать, что ОО подход иногда не рулит. А апп-сервер здесь совсем не причём. Объектная модель и апп-сервер не одно и тоже и мой пример как раз и демонстрирует, что часто они не очень-то и совместимы.

ГВ>Кто бы спорил! Из пушки-то по воробьям... Но App-серверы делают-то далеко не ради простейших задач. От твоего внимания ускользнуло, что задача выбрана ошибочно, и кстати я обратил твоё внимание на этот прокол. Улавливаешь?

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

ГВ>Для перемещения на большие расстояния нужны самолёты, а "через дорогу" можно пройти и пешком. Но это не означает, что нужно на десять тысяч км топать ногами. Это весьма софистичный (и демагогичный, кстати) метод доказательства своей правоты (специально обращаю внимание mvg_first на это место). А силлогизм, лежащий в его основе не имеет решения, да и силлогизмом, вобщем-то не является. Силлогизм таков.

Всё это отмазки. Методы проектирования не сильно отличаются для больших и маленьких задач. Тем более что большую задачу всегда можно и нужно делить на несколько поменьше, которые в свою очередь тоже нужно делить и т.д. К тому же большие, сложные, монстроидальные системы чаще говорят о плохом дизайне или вообще о его полном отсутствии.

ГВ>Посылка А: данную маленькую задачу можно решить простым способом за час. Посылка Б: App-сервер делается для сложных задач. Что из этого следует? Да то, что посылка А попросту неуместна в контексте данного топика.

Т.е. в маленькой системе такую задачу можно сделать за час, в большой нужен месяц?

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

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

IT, ты просто неутомим.

IT>>>Естественно, исходные тексты этой задачи (без формирования html) помещаются на одну печатную страницу Могу показать. Причём моя реализация ни чуть не менее объектна твоей.
ГВ>>Да, значит, ты не представляешь о чём речь... досадно.
IT>Да куда нам деревенским

Хм. Тебе видней, но эмоции, наверное, лучше при себе оставить.

ГВ>>>>Нет уж, IT, извини. Я тут и напостил достаточно много, почти приблизившись к раскрытию своих (и не только) know-how.
IT>>>Правильно, думаю, что это лучше никому не показывать и вообще об этом не рассказывать
ГВ>> До чего же нравится мне твоя самоуверенность. Ну просто достойно упоминания в анналах.
IT>Ну тогда покажи, а то ноу-хау. Я понимаю, что этим очень удобно прикрываться.

Угу, удобно. Давай пока рассмотрим декомпозицию.

ГВ>>Естественно. Только не спасовал — мы с тобой играли на разных полях. Или ты думал что я на "слабо" поведусь? Скажу больше — я и с самого начала догадывался о такой развязке. Оставалась небольшая вероятность того, что ты или кто-нибудь другой начнёт задавать интересные вопросы, касающеся "зачем" и "почему" но этого не случилось... а жаль.
IT>Я у тебя конкретно спросил как. Ты сказал, что мол долго объяснять, ноу-хау и пр. Разве не так.

Точно так. И большого ряда конкретных деталей я обсуждать здесь не буду, извини. Тем не менее, есть ещё ряд вопросов, которые можно обсудить, касающиеся подходов, взглядов и т.п.

ГВ>>Кстати, коль не секрет, а синглетоны ты откуда взял? Я вроде о них даже не упоминал? Попрошу тебя ответить в форуме хотя бы на этот пункт, на остальную часть поста можешь не отвечать.
IT>Разве нет? Значит я что-то попутал. В любом случае твоя модель стейтфул, без пары синглетонов там не обойтись.

Вопрос 1. Где эти singletons по твоему мнению должны быть?
Вопрос 2. Почему их присутствие должно влиять на load balancing?

Второй вопрос на самом деле — основной.

ГВ>>Ну что же, частично ты прав. Только есть одна недоработка — App-серверы ради организации форумов и одного запроса обычно не пишут.
IT>Это скорее зависит от нагрузки на этот самый форум.

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

ГВ>>Хотя, мне было бы очень интересно узнать, каким образом обобщается твой подход на случай, ну, скажем, системы управления складом?
IT>Сколько наименований номенклатуры? Примерный приход, расход в день? Выписка? Сколько поставщиков, потребителей? Осуществляется ли электронный обмен данными с поставщиками потребителями или всё ручками? Территориальная распределённость системы, синхронизация данных? Импорт/экспорт данных из/в бухгалтерию или всё в реальном времени? И т.п. Это всё гораздо интереснее чем:

Наверное интереснее, но вот в форуме меряться... эээ... силой не хочется. Речь, напоминаю, была о том, как обобщается твой подход (сначала разобраться с базой данных, оптимизировать её и т.п.) на достаточно сложную систему.

ГВ>>Или для простоты возьмём более абстрактно: 170 таблиц [bla-bla-bla]

IT>Всё это совсем не показатель крутизны системы. Поверь мне Я делал склад, который держал (может и сейчас держит) несколько крупных предприятий. Всё нормально, такого количества таблиц мне не надо было. Сейчас я работаю над системой, которая покруче описанной тобой и моя задача сделать её проще, гораздо проще чем то что описал ты.

Это всё понятно, только непонятно, к чему это (в контексте топика)? Ну да, делал "крутую" систему и делаешь сейчас ещё более крутую. А причём тут задачи App-серверов? Хотя я тоже неправ — нельзя сравнивать системы, полученные "реляционным" дизайном с системами, спроецированными на РСУБД из объекной декомпозиции.

IT>Там где есть 10 таблиц оставить 3, там где есть древовидные структуры попытаться от них избавиться, по-крайней мере это нужно сделать в рабочих таблицах, и т.д. Т.е. сделать систему проще, компактнее, быстрее, надёжнее и одновременно гибче.

Угу, занимаешься реинжинирингом системы. Сия фаза присутствует в ЖЦ любого живого софта. И что теперь? Реинжниринг сложной и бестолковой БД сопряжён с такими же геморроями, как и реинжиниринг корявой ОО-системы с размазанными и чёрт-те как выстроенными абстракциями.

ГВ>>Я в этом и не сомневался, IT. Кстати, представь себе — текстуально я того же мнения об ООП что и ты. Весь прикол этой ветки в том, что я отвечал тебе несколько не в том ключе, который ты от меня ожидал. Но ключ был задан исходной темой топика. Не находишь, что логичным было бы ожидать что любая тема, возникающая здесь, будет развиваться в контексте App-серверов?

IT>Мы о них и говорим.

Да, но как ты верно подметил ниже, похоже, что мы понимаем под этим очень разные вещи. Давай уточним, что ты понимаешь под App-сервером.

IT>1. Ты в праве предложить свою. [задачу, которая "катит"]
Не в кокнретных задачах дело, IT, а в подходе к их решению, который и приводит к необходимости решения в виде целостного App-сервера.

IT>2. Это задача которую нужно решать. Наверняка подобных задач в твоём складе вагон и маленькая тележка.
Какая разница — склад, бухгалтерия и т.п. Дело в другом — в точке зрения на реализацию.

IT>Естественно, задача была подобрана специально что-бы показать, что ОО подход иногда не рулит. А апп-сервер здесь совсем не причём. Объектная модель и апп-сервер не одно и тоже и мой пример как раз и демонстрирует, что часто они не очень-то и совместимы.

Тогда зачем она здесь нужна? Это и так все отлично понимают, не дети, чай. Знаешь, есть задачи, вполне жизненные, в которых Java не рулит, или C++ не рулит, или CLR не рулит, даже Asm и тот не рулит. А мы подразумеваем здесь те задачи, в которых App-серер рулит. Если тебе удалось реализовать отдельные такие задачи без App-сервера — очень хорошо, но в целом это не имеет никакого значения.

Да, объектные модели бывают разными — есть объектные модели таблиц, и есть объектные модели приложений и что с того? Ответ — ничего.

IT>Она выбрана не ошибочно, это сделано специально. Это реальная задача из реальной жизни, задача, которую каждый может пощупать сам.

Никто с этим не спорит. Что же теперь? Проблема в том, что не всегда исходные "привычные" методы декомпозиции, адекватные маленьким задачам достаточно адекватны большим.

ГВ>>Для перемещения на большие расстояния нужны самолёты, а "через дорогу" можно пройти и пешком. Но это не означает, что нужно на десять тысяч км топать ногами. Это весьма софистичный (и демагогичный, кстати) метод доказательства своей правоты (специально обращаю внимание mvg_first на это место). А силлогизм, лежащий в его основе не имеет решения, да и силлогизмом, вобщем-то не является. Силлогизм таков.

IT>Всё это отмазки. Методы проектирования не сильно отличаются для больших и маленьких задач. Тем более что большую задачу всегда можно и нужно делить на несколько поменьше, которые в свою очередь тоже нужно делить и т.д.

Вопрос в том — как делить, какие функции где оставлять и вот тут для больших и маленьких задач всё может очень сильно отличаться. Ну как отличаются enum currency {USD, RUR}; от классификатора валют в БД. Мне попадались и такие проекты, где классификаторы валют enum-ом делают. Тоже — живые в своём роде. Что же теперь? Говорить, что всё и вся нужно сводить к enum-ам?

IT>К тому же большие, сложные, монстроидальные системы чаще говорят о плохом дизайне или вообще о его полном отсутствии.

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

ГВ>>Посылка А: данную маленькую задачу можно решить простым способом за час. Посылка Б: App-сервер делается для сложных задач. Что из этого следует? Да то, что посылка А попросту неуместна в контексте данного топика.

IT>Т.е. в маленькой системе такую задачу можно сделать за час, в большой нужен месяц?

Странный вывод. Я же ясно сказал, что этот силлогизм не имеет решения. Кроме того, что неуместно подсовывать задачку, подразумевая при этом заведомо некорректное с твоей точки зрения решение.

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

Что представляешь ты?

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

ГВ>Kreek как раз и предлагал. ИМХО, удалять App-сервер от БД имеет смысл только ради приближения его к пользователям, но приближать в этом случае нужно и базу данных тоже (см. ниже). А если не приближать ничего, то пользователям нужны тонкие клиенты.

ГВ>А зачем держать 15 удалённых App-серверов, если узел с базой данных один?

Из-за географичеких расположений (допустим всего 1500 пользователей системы по 100 в каждом подразделении). Протокол работы с БД более оптимизированный чем что-либо придуманное мной или даже бинарный формат Remoting, поэтому предполагается разнести назгрузку на канал по нескольким серверам приложений.

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

Я здесь предполагаю отсутствия кэширования как стандартного средства, хотя не полностью. После перезагрузки для более-менее рабочего состояния серверу приложения достаточно 2-3 тыс. записей из БД, так что это не будет узким местом.

В такой картине целесообразно применять кэширование для бизнес объектов?

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

K>Из-за географичеких расположений (допустим всего 1500 пользователей системы по 100 в каждом подразделении). Протокол работы с БД более оптимизированный чем что-либо придуманное мной или даже бинарный формат Remoting,

Интересно, исходя из чего ты сделал такой вывод?

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

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

K>>Из-за географичеких расположений (допустим всего 1500 пользователей системы по 100 в каждом подразделении). Протокол работы с БД более оптимизированный чем что-либо придуманное мной или даже бинарный формат Remoting,

AVK>Интересно, исходя из чего ты сделал такой вывод?

Прозвучало как вывод, хотя это только предположение. Если это так, то сегмент БД <-> Апп. сервер можно сделать длиннее, чем сегмент Апп. сервер <-> клиент.

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

AVK>>Интересно, исходя из чего ты сделал такой вывод?

K>Прозвучало как вывод, хотя это только предположение. Если это так, то сегмент БД <-> Апп. сервер можно сделать длиннее, чем сегмент Апп. сервер <-> клиент.

Далеко не факт. При разумном проектировании на клиента надо гонять только то что человек может визуально воспринять, а это очень и очень немного. А вот апп сервер может сделать в БД очень большие выборки. Так что куда предпочтительнее сокращать именно БД — АппСервер.

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

ГВ>>А зачем держать 15 удалённых App-серверов, если узел с базой данных один?

K>Из-за географичеких расположений (допустим всего 1500 пользователей системы по 100 в каждом подразделении). Протокол работы с БД более оптимизированный чем что-либо придуманное мной или даже бинарный формат Remoting, поэтому предполагается разнести назгрузку на канал по нескольким серверам приложений.

Хммм... ну, если пользователи у тебя не устраивают выборок по сотне тысяч записей, чтобы полазить по ним PgUp/PgDn, то... ну ладно.

K>Я здесь предполагаю отсутствия кэширования как стандартного средства, хотя не полностью. После перезагрузки для более-менее рабочего состояния серверу приложения достаточно 2-3 тыс. записей из БД, так что это не будет узким местом.

При условии, что серверу на самом деле хватит 2-3 тыс. записей, что сомнительно при ста пользователях.

K>В такой картине целесообразно применять кэширование для бизнес объектов?

В такой, в принципе, да. Кстати, и оповещение тоже будет прекрасно работать, т.к., как я понимаю, между узлом и сервером БД — постоянная и качественная. Просто оповещение будет проводиться через центральный сервер, на котором будет работать App-сервер.

Только одно смущает — сочетание условий какое-то... фантастическое... немного.

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

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

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

Мир Вам господа! И не ссорьтесь

P.S. Геннадий по состоянию на 17-02-2003 10-20 (GMT+2) обещанного письма я не получил. Просто напоминаю

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

K>>Я здесь предполагаю отсутствия кэширования как стандартного средства, хотя не полностью. После перезагрузки для более-менее рабочего состояния серверу приложения достаточно 2-3 тыс. записей из БД, так что это не будет узким местом.

ГВ>При условии, что серверу на самом деле хватит 2-3 тыс. записей, что сомнительно при ста пользователях.

По метаданным этого достаточно.

K>>В такой картине целесообразно применять кэширование для бизнес объектов?

ГВ>В такой, в принципе, да. Кстати, и оповещение тоже будет прекрасно работать, т.к., как я понимаю, между узлом и сервером БД — постоянная и качественная. Просто оповещение будет проводиться через центральный сервер, на котором будет работать App-сервер.

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

ГВ>Только одно смущает — сочетание условий какое-то... фантастическое... немного.

То, что смог придумать.

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

MF>P.S. Геннадий по состоянию на 17-02-2003 10-20 (GMT+2) обещанного письма я не получил. Просто напоминаю

Хммм... проверь почту ещё раз.

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

MF>А уж потом можно будет смотреть и определять, какому пути следовать, и что делать. Ведь Вы такую полемику развели, что я даже некоторых слов уже не понимаю
MF>А ведь топик создавался для чего? Что бы помочь мне, и таким же как я начинателям "великого" дела.

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

От себя замечу что для замены 1С на предприятиях с небольшим документооборотом (до 10000 документов в день) имхо предпочтительней все же критерии ГВ.

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

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

MF>>P.S. Геннадий по состоянию на 17-02-2003 10-20 (GMT+2) обещанного письма я не получил. Просто напоминаю

ГВ>Хммм... проверь почту ещё раз.
Все есть Три письма Буду изучать — сенкс.

Прошу прощения у Всех за личную переписку

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

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

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

ГВ>Что представляешь ты?

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

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

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

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

AVK>От себя замечу что для замены 1С на предприятиях с небольшим документооборотом (до 10000 документов в день) имхо предпочтительней все же критерии ГВ.

Естественно ему будет нужна объектная, т.к. он хочет сделать систему отчуждаемую от разработчика. Но только хорошо бы с самого начала понимать во что это выльется и предпринимать сразу соответствующие меры. В частности, я убеждён, что проектирование подобной системы от объектной модели, как это рекомендует ГВ, большая ошибка.