http://groups.google.com/groups?q=metelitsa+gemstone&hl=ru&lr=&group=fido7.su.dbms.*&selm=980777602%40f13.n5077.z2.ftn&rnum=1

vadiminfo
Все-таки с Вашего позволения, за объектностью некоторые намерены обратиться к Ораклу. Он ОРСУБД, как впрочем и DB2 IBM и Скуль. К MySQL возможно и не надо обращаться не тока за объектностью, но и по некоторым другим вопросам.

Пьёте тухлую грязную воду из лужи и называете ее ключевой родниковой водой.

GemStone несомненно ООСУБД,

Да

как и версант, онтос и др, к которым можно обращаться.

Нет

Тем более у них другие стратегии разработкии у ООСУБД, чем у GemStone. Про Cache и их владельцев, пока до конца не ясно.
Однако, раз в 1989-1991 ведущие производители СУБД не перешли на ООМД, а вместо этого на ОРСУД, то и придется пока к ним обращаться и за объектностью и за всеми последними другими веяниями. Нам же реально надо задачи решать, а не просто теоретизировать.

Ну вот и мне приходится иметь место с DB2, Oracle, Firebird. Но не по техническим причинам, а по организационным и лицензионным.

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

Вот этот самый его авторитет принес вред. Чем больше авторитета, тем больше может быть нанесено вреда. И некому оказалось поправить.

Вы этот url видели? (http://groups.google.com/groups?q=metelitsa+gemstone&hl=ru&lr=&group=fido7.su.dbms.*&selm=980777602%40f13.n5077.z2.ftn&rnum=1)

Для кого же я его тогда приводил?

Могу и так оформить, лично для вас:
http://groups.google.com/groups?q=metelitsa+gemstone&hl=ru&lr=&group=fido7.su.dbms.*&selm=980777602%40f13.n5077.z2.ftn&rnum=1

И в последнем издании ничего не поменялось - разве что номера страниц наверняка другие. Дело в том, что, чтобы въехать в тему, желательно поработать со Smalltalk'ом хотя бы годик.

Ну что за чушь - в GemStone/S нет ad-hoc запросов??? Любой Smalltalk это может, а для GemStone/S даже command line interface сделали.

Декларативный vs процедурный - несколько более сложный вопрос, но для тех, кто понимает механику работы Glorp и TOPLink, вопрос очевиден.

table select: [:each | each name = 'Smith']

ничем не хуже

select * from table where name = 'Smith'

и можно проводить аналогичные оптимизации. А джойны просто не нужны.

К сожалению, восьмого издания у меня нет. Я даже не знал, что оно вышло. Поищу. Однако, судя по написанию DEPT, HIRE_EMP, FIRE_EMP и CUT_BUDGET, ничего не изменилось.

Андрей Леонидович
"До сих пор мы намеренно не подчеркивали, что если для манипулирования объектами заданы только заранее определенные методы, то произвольные запросы (не предусмотренные этими методами) просто невозможны. Например, если для объекта класса DEPT определены только методы HIRE_EMP (нанять сотрудника), FIRE_EMP (уволить сотрудника) и CUT_BUDGET (урезать бюджет) (как описано в разделе 25.2), то невозможно будет выполнить даже такой простой запрос: "Кто является руководителем отдела программирования ?"."


А если не предусмотреть в таблице поле f1, нельзя будет посчитать такой простой запрос, как "посчитать сумму по полю f1". Точно также получается: формально правильно, а по существу бесполезно.

Ввиду инкапсуляции прямого доступа к переменным экземпляра нет, и вы не можете обращаться к ним иначе, чем через посылку сообщения владельцу (что приводит к вызову какого-то метода, не обязательно одноимённого с переменной или селектором сообщения). Но методы-accessors (присвоить переменной; вернуть значение переменной) создаются почти автоматически (надо просто попросить), и потому вы их можете считать почти же такой же частью создания класса, как и в РСУБД создание индекса при определении primary key. Для меня само собой разумеется, что accessors ко всем переменным уже есть (если же нет, то это очень особая причина и очень редкий случай). Если у меня есть класс Employee с переменными firstName, secondName, lastName, department, то я считаю, что accessors у меня тоже есть, появились при создании класса. Ну, а коли они есть, то я могу сделать любой запрос.

Вот коллекция начальников всех Ивановых:

(employeeCollection select: [:each |each lastName='Иванов']) collect: [:eachEmployee | eachEmployee department manager].

здесь lastName, department, manager - это accessors.

Методы, которые тов. Дейт назвал HIRE_EMP, FIRE_EMP и CUT_BUDGET - это нечто дополнительное (не на уровне Smalltalk, а на уровне модели), наподобие того (но не в точности совпадает), как хранимые процедуры и триггеры являются неким дополнением к таблицам.

ModelR[quot Victor Metelitsa]
Про ненужность джойнов плз подробнее. Пример

Таблиц нет, есть коллекции объектов (тоже объекты). Объекты предметной области "знают" о других. Чтобы узнать подразделение сотрудника, на SQL вы напишете
На Smalltalk'е это

vadiminfo
Во-первых, мне кажется, Дейт не говорил про GemStone в том разделе ни слова? Или Вы по прежнему считаете это единственной ООСУБД? Т.е. ООСУБД = GemStone?
В частности, вот появился Ваш коллега по ООСУБД от версанта.
Уточните, Вы версант не считаете ООСУБД? Вроде Вы сказали нет, на мое утверждение, что он ООСУБД.
Иначе мы никада не разберемся кто ООСУБД, а кто нет.

Дейт рассматривал именно GemStone/S. ООСУБД или нет, зависит от определения. Если впомнить, кто придумал определение объектной ориентированности и в чём оно заключалось, C++, Java, Delphi и их духовные родственники идут лесом. ;-). Остаток очень мал. Objectivity, VOSS, MineStore и пару других я исключил по "моральным" соображением (наличие file sharing), осталось только GemStone/S (на самом деле там тоже есть некая проблемка, но я закрываю на неё глаза).

Да, я в курсе, что "некоторые люди" типа Страуструпа определение извратили.

Как-то я переформулировал определение Кея, заменив "объектно-ориентированный" на "серверно-ориентированный" (заменил "объект" на "сервер" и "сообщение" на "запрос" => 1. есть сервера и ничего кроме серверов; 2. сервера общаются между собой запросами).

Тем более Дейт подчеркивает, что ad-hoc возможны, если следовать чему-то там.

Cовершенно не помню этого момента.

Что вообще в ООСУБД есть проблемы с ad-hoc - наверное вообще впервые не Дейтом выяснено, такое мнение распространено.

В GemStone/S я могу всё сделать в command line, во время работы сервера. Как можно говорить о проблемах с adhoc?

Потому, Ваша критика Дейта в ошибках, мне все еще кажется излишне смелой.
Victor Metelitsa
Декларативный vs процедурный - несколько более сложный вопрос, но для тех, кто понимает механику работы Glorp и TOPLink, вопрос очевиден.

Вы думаете здесь так много механиков? Так что проясните про декларативнсть.
В принципе грят про OQL. Но все-таки основным способом доступа к данным называю навигационный способ, который как язык БД не похож на декларативный.

Выборка по условию:
table select: [:each |each name = 'Smith']
чем не декларативная запись?
Или второй пример:
(employeeCollection select: [:each |each lastName='Иванов']) collect: [:eachEmployee | eachEmployee department manager].
Де-факто это всё-таки вызовы методов. Но сама запись декларативна - "дайте мне то-то", а не "сделайте так-то".

GLORP и TOPLink я приплёл из-за оптимизаций запросов. Они транслируют похожие запросы прямо на SQL, "дизассемблируя" условия в квадратных скобках, предоставляя разбираться с оптимизациями серверу БД. Очевидно, нично не мешает транслировать Smalltalk на Smalltalk (GemStone/S - это большой конструктор).

Андрей Леонидович"...почти автоматически (надо просто попросить)..."
"...можете считать почти же такой же частью создания класса, как..."
"...если нет, то это очень особая причина и очень редкий случай)."
"...наподобие того (но не в точности совпадает),..."

Верно подметили. Но была ещё фраза - "формально правильно, а по существу бесполезно.". Для меня создание accessors при создании класса такая же естественная и неотделимая вещь, как, по-видимому, для вас указание типа поля (VARCHAR etc) при определении таблицы. Есть (модельный) класс - есть и accessors, и с ad-hoc запросами никаких проблем нет; противное верно лишь в особых случаях.

Все-таки, пока у меня остается ощущение, что Дейт, как минимум, не хуже Вас понимает ООСУБД...

Замечательно при этом было бы, если бы Вы не хуже меня понимали ООСУБД.

Давайте по-конкретнее... Как, например, в "вашей" ООСУБД представляются связи между сущностями многие-ко-многим, когда у них (связей) есть свои свойства (характеристики)? Как в РСУБД ?

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

Объект принадлежит классу, имеет методы, может (но не обязан) иметь переменные. Объект X связан с некими объектами Y (я обозначил несколько объектов одной буквой Y - значит, скорее всего, Y это коллекция, которая их содержит) соотношением 1:N - это означает, что объект X имеет метод (обычно это accessor к переменной объекта X), возвращающий Y.

employee department - посылка сообщения #department объекту employee класса Employee, и предполагаю, что вернётся экземпляр Department. Это связь 1:1.

department employees - (не помню, как здесь правильно пишется множественное число) - это связь 1:N, и по предположению вернуться должна коллекция экземпляров Employee.

"Предполагаю", потому что в реальности возможны совершенно головокружительные варианты.

Хочу еще раз сказать про accessors. В РСУБД мы определяем поле как

xxx VARCHAR(100) NOT NULL CHECK (xxx = uppercase(xxx))....

в Smalltalk этому (обычно!) соответствует instVar по имени xxx и пара accessor-методов - xxx (getter, узнать значение переменной xxx) и xxx: (setter, присвоить значение переменной xxx), а check constraint, если надо, опишете в setter'е. Определяя модельный (принадлежащий модели предметной области) класс, вы наверняка будете следовать этой схеме (хотя и не обязаны), и если модельный класс есть, то и accessor'ы у него есть, и adhoc-запросы с его участием очевидны.

U-gene 2 Victor Metelitsa
авторВвиду инкапсуляции прямого доступа к переменным экземпляра нет, и вы не можете обращаться к ним иначе, чем через посылку сообщения владельцу (что приводит к вызову какого-то метода, не обязательно одноимённого с переменной или селектором сообщения). Но методы-accessors (присвоить переменной; вернуть значение переменной) создаются почти автоматически (надо просто попросить), и потому вы их можете считать почти же такой же частью создания класса, как и в РСУБД создание индекса при определении primary key .

ИМХО выделенное - Ваш прокол. Индекс не есть термин РМД. То есть из того что Вы написали, следует, в РСУБД возможность ad-hoc следует из модели , а в GemStone/S она определяется реализацией. Может Дейт это и имел в виду?

Кстати, этот бы Ваш креатив на англицкий перевести и Дейту на DBDEBUNK.COM послать. ИМХО он Вам ответит - на ответ было бы очень любопытно взглянуть.

Почему прокол? Я говорю о практике. На практике вам едва ли нужна РСУБД без индексов, пусть теория их и не упоминает, и на практике у вас не будет проблем с adhoc-запросами в GemStone/S, что бы вам ни сказала теория.

Я бы не постеснялся написать Дейту и давно бы это сделал, будь у меня лучший английский.

Кстати, ни у кого нет знакомого хакера-крякера? Есть у GemStone/S одна "проблема", которая меня страшно расстраивает. Сам он весьма дорог (что не удивительно), моя контора персонально для меня его не купит, а сам я тем более. Но они выдают некоммерческую лицензию на четырёх юзеров. Меня бы устроило и это, но лицензия длится всего полгода. Да, они переобновляют ее по запросу, но меня это всё равно расстраивает (а ну как перестанут?), поэтому что-либо полезное делать с ним психологически весьма трудно.