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

EXO>Сервер приложений должен обрабатывать не запросы на "поставку данных", а логику приложения. То есть то самое: "разбираться каким образом ему эти данные в каком ракурсе он будет обрабатывать".

Боюсь, что подобного формального определения что такое сервер приложений не существует. Впрочем, если поделишься ссылочкой, буду премного благодарен.

Здравствуйте, IT, Вы писали:
IT>Боюсь, что подобного формального определения что такое сервер приложений не существует. Впрочем, если поделишься ссылочкой, буду премного благодарен.

Боюсь, что нет.
Но на кой он иначе "сервером приложений" называется?

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


M>Тогда в объектном хранилище ты еще и переписываешь данные, вместе со своим кодом, они же у тебя оборудованы методами доступа от которых их не оторвать.

Это заблуждение. Возьмем к примеру тот же Cerebrum. Текущая его версия на .NET 2.0 совершенно спокойно читает бинарный файл версии от 0403 расчитаной только на .NET 1.1 и спокойно инстанциирует вместо экземпляров .NET 1.1 экземпляры .NET 2.0

Мало того, объектная модель последней версии была кардинально пересмотрена и переписана. А БД таже — в том же бинарном формате. Если это даже я умею, то остальным ОБД не уметь такого просто странно. Тоесть вы в данном вопросе заблуждаетесь

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


AVK>Можешь продемонстрировать. Потому как как обойтись без наследования реализаций мне понятно, а вот без наследования интерфейсов ...

С этим тезисом согласен полностью. Хотя можно было бы продискутировать на тему, является ли наследование интерфейса именно наследованием, или его можно считать полиморфизмом. (тот же VB).

Ну мне от этого вопроса ни холодно ни жарко. Я в своей СУБД поддерживаю одиночное наследование классов и множественное интерфейсов как в ядре (plain-C) так и на application уровне (С#).

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

EXO>Почему?
EXO>Меня только обработка исключений слегка достает. Но не так чтобы уж очень...

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

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

IT>>Удивительнее то, что мне пришлось это повторять так много раз.

Д>я просто никак не мог понять, почему ты упорно связывал наличие состояния и ООП.

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

Д>Наличие состояния у узлов системы — это вещь, от которой никуда не деться. Состояние всегда будет у узлов распределенной системы, равно как и у отдельных частей этого узла. Можешь писать хоть на ООП, хоть структурно, хоть квадратно-гнездовым способом — от этого ничего не изменится.

В stateless системах проблема состояния более менее решаема. Все те допущения о которых я говорил ранее в stateless обычное дело.

Д>только давай не будем играться с терминами? Авторы называют свою реализацию ООП — и там действительно есть те вещи, которые обычно связывают с ООП. Значит, это и есть ООП. Если твое понимание ООП отличается от общепринятого, то хотя бы не надо пытаться делать это аргументом в споре.

К счастью я не одинок.

CLOS is a dynamic object system which differs radically from the OOP facilities found in static languages such as C++ or Java.

Вика — свободная страна, можешь зарегестрироваться там и дать своё поределение OO в CLOS. Может быть тогда я приму твою версию

Д>а где про это написано? Вот прямо такими словами? Я еще не видел ни в одной книге "писать объекты без изменяемого состояния запрещено третьей сурой Корана, и все нарушители этого принципа будут гореть в аду"

А что это тогда за объекты? Можешь привести пример?

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

Д>почему это — не могу? кто мне запретит? ООП — это надможество структурного программирования, и позволяет использовать все те же самые приёмы и методы.

Я же говорю, что ты не понимаешь. Честно говоря у меня уже и желания-то никакого нет объяснять. Ну попробую ещё раз начать сначала.

Речь идёт не просто об ООП. Его мы все любим, все используем и радуемся вместе с ним жизни. Использовать его можно во многих местах. Даже в сетевых протоколах можно выделить отдельно объект коннекшин и использовать его вместо хендлеров. С этим никто не спорит и спорить не собирается. Этот ООП у нас никто не отнимет.

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

Д>динамическая и слабая типизация — одно и то же? Ну это ты уже совсем через край хватил.... Почитай литературу, там много интересного....

Проблемы одни и теже.

IT>>Это всё нетрадиционные формы ориентации ООП.
Д>кто сказал, что они нетрадиционные?

Я же говорю, нетрадиционная ориентация сегодня в моде. Так что традиционное может вполне стать нетрадиционным

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

Д>Мне так показалось, что мы обсуждали задачу как таковую, а не твою роль в ней.

Предположим, что я непосредственно отвечаю за данную задачу.

Д>В рамках задачи, если эти данные есть, то их надо экспортировать, чтобы их мог прочитать получатель. А твоя это задача или нет — меня не волнует.

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

В общем, боюсь что ты опять спутал курицу с яйцом

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

S>Это заблуждение.
Это твоя Cerebrum сплошное заблуждение..

S> Возьмем к примеру тот же Cerebrum.
Нельзя твой Cerebrum брать в качестве примера, потому как не объектная она, по причине отсутствия в ней инкапсуляции, из-за которой в этой подветке весь сыр-бор и разгорелся...

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

Д>на вопрос ты опять не ответил
Ответил, а то что он тебя не устроил, так я не виноват.

Д>Если другие проблемы можно решить, то проблемы с удобством тем более можно решить.
Ну и где это решение? Их уже второй десяток лет решают и все что-то ни как...

Д>то есть первая полноценная реализация РБД появилась в 1974 году? И что это за программа была, можешь точнее рассказать?
Нет, в конце семидесятых, первые доступные широкой общественности публикации были не в 70м, а позже.

Д>Я рад за тебя, если тебя и так всё устраивает. Честно Меня — нет.
Меня тоже не устраивает, но из двух решений я выбираю то, где проблем меньше...

Д>сколько там прошло времени с начала развития ООБД, не напомнишь?
Более чем достаточно. Тому же Gemstone/S, с так полюбившейся тебе динамической типизацией, уже больше пятнадцати лет.

Д>потому что появилось, что замечать.
Да нет, просто появилось, видимо, к чему придраться...

Д>нет. Вообще довольно редко возникает, независимо ни от чего.


Д>не обертки. Расширение интерфейса существующих объектов.
По кругу поехали?

Д>Угу. Старый код этих данных не заметит и будет работать старым образом. Неправильным образом.
Почему неправильным? Правильным, по старым правилам.

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

Д>Как видишь, здесь мы имеем как инкапсуляцию, так и доступ ко всем данным.
Нет у нас здесь доступа ко всем данным. Что делать, если зависимость изменилась? И даже если не изменилась, ты предлагаешь делать геттеры в обязательном порядке, на всякий случай? Да уж, ОО-подход.

Д>что значит — не такой объект? Ты хотел получить клиента, а тебе вместо него подсунули документ?
Не прикидывайся. Вспомни, почему отчеты в ОО делать неудобно...

Д>две части системы — это код и данные, что ли?
Объекты и данные.

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

Д>Тотальное господство РБД в 1985 году?
Вот такое вот тотальное господство.

Д>Ты просто сравниваешь существующие сейчас незрелые ООБД и современные РБД, которые прошли очень большой путь и ассимилировали много идей из других концепций.
Ну сравни развитие реляционки, от первой коммерческой версии за помежуток времени в развитии ООБД, от первой же версии до наших дней.

Здравствуйте, AndrewVK, Вы писали:
AVK>Потому что грамотная организация процесса взаимодействия пользователя это очень непростая задача, зачастую превышающая по объемности разработку сервера приложений.

Согласен полностью.
Тебя смутило слово "только"? Оно не про сложность/простоту, а про обработку данных.

Здравствуйте, shuklin, Вы писали:
ет опережать ОБД. И это мы говорим о тупом поиске в глубь на основании индексов.

S>Еще меня смущает JOIN за log(Ш')+log(У')
Да, конечно косяк. Join будет сделан за Ш'+У'. Там на самом деле обе оценки гонимые.
1. С чего ты взял, что школы удастся отобрать за log(Ш)? Это годится только в том случае, если школа ровно одна. В противном случае стоимость складывается из стоимости поиска и стоимости сканирования. Т.е. log(Ш)+Ш'. К тому же, надо помнить о коэффициентах. В данном случае логарифмом можно пренебречь — в реальных СУБД у него очень большие основания.
Поэтому на самом деле итоговая стоимость будет порядка O(Ш') + O(У').
Такая же стоимость и у запроса в RDBMS, с точностью до констант при Ш' и У'.

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

S>Ездят куда?
См. http://tpc.org
S>Если в гриды или отчеты — это одно. А если в объекты бизнес логики — это другое.
Поясняю: RDBMS ни в каких объектах бизнес логики не нуждается. Речь идет об OLTP приложениях, типа продаж товара. Ты готов на своей настольной ОБД выписывать 10000 заказов в минуту? С учетом того, что параллельно проходят подтверждения платежей, а кто-то еще смотрит отчеты.
S>По любому на ORM будут затраты. Их можно избежать. А в гриды и отчеты данные как и раньше отправлять мимо методов.
Гриды и отчеты ездят поверх OLAP. Там ОДБ никогда не догонит специализированные базы.

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

S>>Еще меня смущает JOIN за log(Ш')+log(У')
S>Да, конечно косяк.

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

Однко для разных задач разные модели данных более предпочтительны. ИМХО для построения ОБД наиболее близкой будет сетевая модель.

Если так, то РБД пора на пенсию.

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

S>Поясняю: RDBMS ни в каких объектах бизнес логики не нуждается. Речь идет об OLTP приложениях, типа продаж товара. Ты готов на своей настольной ОБД выписывать 10000 заказов в минуту? С учетом того, что параллельно проходят подтверждения платежей, а кто-то еще смотрит отчеты.

После реализации клиент-сервера 10000 — готов. Писал уже, в декабрьской версии без транзакций можно получить 80000. В текущей с транзакциями будет около 25000 — 40000. Это пока чистый функционал. Надеюсь довести после оптимизации до 100000 объектов в секунду. А ведь объект это вещь сложная, по объекту на заказ + необходимые накладные расходы — получим те же 10000. Ну и тачка моя текущая не фонтан для сервака. Так что ИМХО скоростные показатели моего поделия хоть и не в переди планеты всей, но для решения насущных задач более чем достаточны.

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

S>> Возьмем к примеру тот же Cerebrum.
M>Нельзя твой Cerebrum брать в качестве примера, потому как не объектная она, по причине отсутствия в ней инкапсуляции, из-за которой в этой подветке весь сыр-бор и разгорелся...

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

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

S>Для тех кто в танке, в Cerebrum инкапсуляция присутствует, но с возможностью от нее отказаться при желании (на этапе разработки БД). В Cerebrum присутствует свобода выбора.
Тяжело же вам, в танке... Если мы вибираем инкапсуляцию, значит доступа к самим данным напрямую нет, значит я прав. Если мы выбираем не инкапсуляцию, значит это не ООБД и, следовательно, я опять прав.

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

S>>Для тех кто в танке, в Cerebrum инкапсуляция присутствует, но с возможностью от нее отказаться при желании (на этапе разработки БД). В Cerebrum присутствует свобода выбора.
M>Тяжело же вам, в танке... Если мы вибираем инкапсуляцию, значит доступа к самим данным напрямую нет, значит я прав. Если мы выбираем не инкапсуляцию, значит это не ООБД и, следовательно, я опять прав.

Вы если и правы, так только в дефенициях. Мне глубоко пофиг как что назвать. От названия суть не меняется. Не зависимо от того что "правы" вы в обоих случаях, функциональность от этого не страдает. Если нам важны вопросы секурити и мы согласны забить на перформанс — вуаля, мы идем по первой веточке где вы "правы". Если нам нужно получить перформанс — идем по второй, а секурити обеспечиваем уровнем выше. Мало того, не забываем, что полиморфизм от обоих веточек не страдает. Как в одном так и в другом сценарии сохраняется возможность подставлять вместо одной структуры объектов другую структуру. Так что за исключением секурности поимели все выгоды и от ООП и открытости данных. Мало того, секурность во второй веточке тоже в ядро ОБД можно встроить, и раздавать права на чтение отдельных аттрибутов ... Так несмотря на то что вы типа правы, по любому ОБД на основе сетевой модели рулят.

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

S>Если я правильно понял ваш тезис, то получаецца что при грамотной реализации что иерархической модели что реляционной что сетевой затраты при решении одинаковых задач будут примерно одинаковыми (т.е. чудес не будет). С этим я согласен.
Нет, неправильно. В более сложных случаях сетевая модель будет сливать. Просто потому, что в какой-то момент join предикат окажется более селективным, чем примененный к экстенту. Ну вот как представь себе, что школ, в которых есть школьники нужного возраста, мало. Тогда РДБ выберет школьников, получит список школ, в которых они учатся, и проверит, какие из них попадают в нужный диапазон. Сетевая БД будет вынуждена сканировать все школы просто на всякий случай.
S>Однко для разных задач разные модели данных более предпочтительны. ИМХО для построения ОБД наиболее близкой будет сетевая модель.

S>Если так, то РБД пора на пенсию.
Далеко еще до пора.

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

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

S>>Поясняю: RDBMS ни в каких объектах бизнес логики не нуждается. Речь идет об OLTP приложениях, типа продаж товара. Ты готов на своей настольной ОБД выписывать 10000 заказов в минуту? С учетом того, что параллельно проходят подтверждения платежей, а кто-то еще смотрит отчеты.

S>После реализации клиент-сервера 10000 — готов. Писал уже, в декабрьской версии без транзакций можно получить 80000. В текущей с транзакциями будет около 25000 — 40000. Это пока чистый функционал. Надеюсь довести после оптимизации до 100000 объектов в секунду. А ведь объект это вещь сложная, по объекту на заказ + необходимые накладные расходы — получим те же 10000. Ну и тачка моя текущая не фонтан для сервака. Так что ИМХО скоростные показатели моего поделия хоть и не в переди планеты всей, но для решения насущных задач более чем достаточны.
Ты, наверное, не понял. Надо не загружать в память 10000 объектов. Надо делать следующее:
— создавать объект заказа
— добавлять в него в среднем примерно 10 позиций-
— сохранять объект заказа
— выполнять отгрузку заказа:
-- находить товары, перечисленные в заказе, на складе
-- уменьшать остатки на складе в соответствии с количеством в заказе (при этом надо еще и откатывать транзакцию, если товара не хватило)
и в это же время проводить платежи (т.е. находить заказ, соответствующий оплате, сравнивать суммы, и помечать заказ как оплаченный), а также время от времени выдавать отчеты типа текущих остатков.
При этом 10000 — это количество отгруженных заказов в минуту. При этом, ессно, без транзакций нельзя — иначе у тебя нарушится целостность данных.

Здравствуйте, Sinclair, Вы писали:
S>>Если я правильно понял ваш тезис, то получаецца что при грамотной реализации что иерархической модели что реляционной что сетевой затраты при решении одинаковых задач будут примерно одинаковыми (т.е. чудес не будет). С этим я согласен.
S>Нет, неправильно. В более сложных случаях сетевая модель будет сливать. Просто потому, что в какой-то момент join предикат окажется более селективным, чем примененный к экстенту. Ну вот как представь себе, что школ, в которых есть школьники нужного возраста, мало. Тогда РДБ выберет школьников, получит список школ, в которых они учатся, и проверит, какие из них попадают в нужный диапазон. Сетевая БД будет вынуждена сканировать все школы просто на всякий случай.
S>>Однко для разных задач разные модели данных более предпочтительны. ИМХО для построения ОБД наиболее близкой будет сетевая модель.

Это если модель не сетевая, а иерархическая — полностью согласен. В сетевой тот же запрос на основании статистики можно раскручивать с другого конца — со стороны учеников. На то она и сеть, что корня у нее нет. ИМХО РМД есть частный случай сетевой модели. А вот иерархии (дерево) действительно во многих случаях проигрывают.