To Vyacheslav

Предупреждаю, что это в этом письме будет больше философии, чем программирования.

Вы верно заметили, что я в ходе объяснений использовал две разные схемы данных для "сложного" веса. Сначала я изложил ту, которая однозначно отображается на ОО язык, чтобы облегчить понимание, в последних же письмах я в табличном виде привел схему, которой сейчас предпочитаю пользоваться сам (ее же можно проследить в скриншотах). Как же так получилось с отображением? А очень просто. Есть бесконечное количество языков, при помощи которых мы можем отобразить предметную область. И это ничего не значит. (Поэтому, кстати, являются пустым звуком заявления типа "при помощи этой модели можно выразить ту модель". Ту модель можно выразить и палочкой на глиняной дощечке, но что это нам дает? Доказывает полноту этой модели? Но у нас нет недостатка в полных моделях.) А значащим является то, как много усилий мы потратим на описание нашего кусочка мира, и на поддержание его в адекватном состоянии. И значащим для конкретно этой заморочки (отображения первой схемы на ООП язык) является тот факт, что два разных языка вовсе не обязательно могут однозначно переводиться друг в друга, даже если они оба прекрасно описывают нужное нам множестно предметных областей.
И вовсе необязательно эффективное в одном языке решение будет таковым и в другом.
Теперь ближе к примеру. Вы утверждаете, что "Вес" как объект не отображает предметную область и не является объектом (или не обязательно является объектом) в ООП языке программирования. По крайней мере я так понял это: совсем необязательно чтобы по каждому классу предполагалось создание объекта
Теперь посмотрим на пример... Нет, теперь я не премину похвастаться, так как это позволит проиллюстрировать разницу в мышлении, ведущую к расхождениям. Итак, хвастовство: одно время в институте у меня была кличка "компилятор", потому что я мог, взяв Сишный текст, с ходу расставить на нем предупреждения и ошибки, которые выдаст компилятор, и для небольшой процедуры - написать ассемблер, в который она откомпилируется.  А вот теперь к примеру.
Я использую класс Вес не для создания объктов, а для наследования от него.
Но позвольте - как только мы начинаем думать о хранении информации, а не о проверке на корректность кода, эта разница превращается в абстракцию. Частью каждого объекта Яблоко является объект Вес, с которым мы работаем именно как с объектом, независимо от места расположения. Таким образом, тот пример, который "я бы поступил по другому", полностью аналогичен первой данной мною модели для сложного веса. Там тоже в каждом объекте яблоко вложен объект вес, и доступ к значению и единице измерения производится через этот вложенный объект. Заметьте, я Вас за язык не тянул. Вы сами предпочли завести класс "Вес", тем самым реализовав наличие объектов "Вес" и согласившись с моим утверждением, что "Вес есть объект". А что до "наследования" vs "агрегатирования", так в и базе можно реализовать совершенно аналогичные механизмы видимости и размещения, хотя это не будет оптимальным решением (все-таки модель это другая, и решения тут другие). При чем тут мое хвастовство? Для иллюстрации одной фразы, (с) К.П.: "Зри в корень!". Увлекаясь жонглированием "агрегатированием", "доменами" и т.д., легко забыть их физический смысл и потерять общность явлений, а то и прийти к неправильным выводам.
Вернемся к необязательности наличия объекта при наличии класса. Увы, и тут Вы неправы! Создатели Явы, которые вознамерились довести ООП концепцию до конца, и преуспели в этом больше, чем кто-либо другой, давно уткнулись в такую необходимость. Результат: java.lang.Class. Каждый класс есть объект, вот так. У меня ведь этот вывод тоже не по щучьему велению появился - как я уже писал, я реализовал сайт с промежуточной моделью, и трудности, которые там были, и обдумывание путей решения привели меня к тому, что есть.
Вот еще один пример пагубных последствий отсутствия привычки смотреть в корень. Мне пишут:

Цитата

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

 Человек сказал последнее слово и довольно улыбается, но он забыл посмотреть в корень. Он думает, что пять операций INSERT - это в пять раз неэффективнее, чем одна операция INSERT. А мы посмотрим в корень и сделаем выводы. Итак, что у нас существует реально? То есть физически. У нас существует таблица, являющаяся набором полей, и ряд индексов, с которыми, собственно, и производится основная работа. Настолько основная, что при выборке данных в случае наличия индексов для всех выбираемых полей к собственно таблице доступ не производится вообще. Независимых, кстати, индексов, по одному независимому индексу для каждого поля (или группы полей). Доступ к таблице - самая быстрая операция, особенно в случае строк с фиксированной длиной (А в моем варианте базы все свойства, не требующие поля с переменной длиной строки, хранятся именно в фиксированных строках, чего нельзя сказать о варианте со неатомарными свойствами - там достаточно одного varchar на свойство, чтобы загнать все соседние INT в таблицу с переменной длиной строки). Более интеллектуальной и длительной операцией является обновление индекса, потому что именно при этой операции проверяется корректность данных и, возможно, балансировка дерева. Кроме того, когда мы рассматриваем пакетные вставки, разница растет катастрофически, потому что вставки в таблицу обычно (зависит от фрагментации) идут одна за другой (последовательно в файле, имеется в виду) и пишутся в конце транзакции в один-два приема, а вот шарясь по индексным файлам, приходится читать и изменять случайные их блоки, что предотвращает кеширование индексов.
Итак, посмотрим на ситуацию на более низком уровне. INSERT с пятью полями: интерпретация SQL, пять вставок индексов, вставка записи в таблицу.
Пять INSERT по одному полю - пять интерпретаций SQL, пять вставок индексов, пять вставок полей в таблицу. В случае наличия прекомпилированных запросов - одна интерпретация SQL, пять индексов, пять записей.
В чем разница? Четыре вставки в таблицу, самые быстрые операции. Самая сложная операция - обработка индексов - производится одинаковое количество раз.
 Конечно, я тут чуть схитрил в подсчете. В случае атомарных полей операций с индексами получается больше, хотя самих индексов - меньше. Но теперь вспомним еще одно обстоятельство, на которое я уже обращал внимание. В правильной реализации объектной базы нет места SQL. Нам незачем компилировать один язык в другой язык, потом разбирать другой язык и только после этого его выполнять. Получая проигрыш в быстродействии и ограниченную функциональность к тому же (ведь применение SQL сильно нас ограничивает - мы не можем получить recordset с объектами разного типа). Правильное решение - делать разборку своего языка в алгоритмы работы с данными через низкоуровневые библиотеки, используя разные варианты BTREE. В результате будет быстрее и с возможностью получения коллекций любых объектов без снижения скорости. При этом все предыдущие рассуждения насчет эффективности вообще теряют силу, и выясняется, что реализация на этой основе атомарных свойств проще по коду при одинаковом быстродействии.

 На этом откланяюсь - пора домой.

to Vyacheslav

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

В самом деле, в информационной системе переменная, содержащая значение веса, может существовать как объект. Более того, чем больше используемая система является "объектной", тем вероятнее, что именно так и будет. И все это потому, что следуя объектной парадигме (ОП)  любая переменная будет является объектом того или иного класса. С другой стороны эта же ОП утверждает, что объекты служат для описания "сущностей". И наконец (это очень важно) ОП, определяя понятие объенкт, утверждает, что объекты уникальны, и, следовательно, любому объекту в системе будет соответсвовать некий идентификатор - фактический некое уникальное значение, тем или иным образом генерируемое системой.

Теперь можно и мне пофилосовствовать? Это касается понятия "сущность". Вообше то крайне сложно определить, что же это такое. Что-то типа "нечто обзываемое, чем оперирует человеческое сознание". И вот существует кучка сущностей - "яблоко", "вес", "дом", "адрес". Да, философия... есть в ней что-то о субъективном восприятии объектного мира. Здесь восприятие делится на две части: с  одной стороны есть объекты, а с другой субъект, воспринимающий, получающий информацию (выражаемую определёнными ЗНАЧЕНИЯМИ) об этих объектах. То есть до того, как начать описывать объекты окружающего мира, мы должны определить, а как же мы будем его описывать, определить термины описания. В соответсвии с этим сущности, которыми оперирует человеческое сознание, можно разделить на две большие группы - "объективные сущности" и "субъективные сущности". Между ними существует большое отличие - объективные сущности могут описываться бесконечно продробно (яблоко может описываться весом, цветом, формой, кожура, семечки, удельная плотность, содержание сахара,  дата созревания. числом клеток, каждая клетка в отдельности  и т.д. и т.п.) то есть с информационной точки зрения "объективные сущности" бесконечны. Субъективные же сущности однозначно описываются вполне конкретным значением (значением веса, например) и с информационной точки зрения конечны.

Следующий этап возникает когда мы запихиваем информацию в компютер. Эта железяка так устроена, что понимает только числа. Поэтому перед тем, как засунуть значение сущности в компютер, мы должны закодировать его. Кстати наш мозг устроен слега также, и ("0.1", "кг") в принципе является кодом, а коды ("0.1","кг") и ("100"."гр") образно говоря представляют одно и то же значение... по крайней мере для обученного человеческого мозга.

Изходя из вышесказанного, модель данных должна позволять описывать данные с трех сторон - 1) объекты 2) субъективное восприятие 3) железо.

Вернемся к объектной парадигме, утверждающей, что объекты уникальны, вследствии чего каждому объекту ставится в соответсвии уникальный идентификатор OID (который в  языках часто идентичен понятию "адрес", значение которго используется для инициализации ссылок или указателей). Совершенно очевидно, что OID необходим при моделировании информационно бесконечных объективных сущностей, поскольку конечная модель (например, мы абстагируемся от устройства яблока и описываем его только через вес и цвет) допускает вариант, что два объекта описываются абсолютно одинаковыми значениями (поскольку может существовать два яблока с одинаковым весом и цветом).

Но вот когда заходит речь о субъективных сущностях то наблюдается прямо противоположная картина. Если мы описываем ее как объект, то что мы имеем? Вместо того, что бы идентифицировать сущность по ее явно заданному изначально конечному значению ("0.1","кг"), мы берем и присобачиваем к ней еще одно значение - значение OID. В этом отсутсвует какой-либо смысл, более того - если это называть моделью, то это неправильная модель. А единственая причина, по которой мы это делаем заключается в том, что чистая объектная парадигма и языки которые ей следуют, не дают нам другой альтернативы. "Любая переменная является объектом", "любой объект имеет OID" и точка.

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

К чему я это? Собствено к тому, что Вы сказали "реалиях не  может существовать отдельно объекта "Вес". Согласен полностью - "вес" существует только в людских головах. Почему вы его описываете как класс? Да потому, что нет альтернативы.  А по поводу
[QUOTE]Частью каждого объекта Яблоко является объект Вес, с которым мы работаем именно как с объектом, независимо от места расположения. /QUOTE]
ИМХО это неверно, т.к. в данном случае OID есть только у объекта "яблоко", а то, как это храниться в системе, так это к модели ни имеет никакого отношения. Пусть "вес" храниться как объект, но это не значит, что мы должны оипсывать его как объект.

ИМХО надо отличать модель от системы, реализующей эту модель. Попробую пояснить на примере. Вот взять тот же ... хотя бы MS SQL Server. Без сомнения он реализует (более-менее полно ) реляционную модель и ничего объектного в SQL-е нет. Но сама то система фактически является объектной: каждая таблица (в том числе и таблицы каталога), или вид, или что-то еще  - это уникальный объект, имеющий состояние, интерфейс, класс, и тп. Но все эти объекты системы не делают  реализуемую системой модель объектой. Случай с Java интереснее - это объекная система реализующая объекную модель, т.е. объекты системы(в тч классы) могут быть описаны моделью реализуемой этой системой....ну и слава богу (на самом деле идея, что класс можно рассмаривать как объект, лет на 20-30 старше чем Java) Дело в том. что когда я создаю некую схему данных, мне условно говоря по-барабану, будет ли информация об описываемом классе храниться в системе как объект или не будет (конечно если в схему данных не входит сущность "класс"). Для схемы данных важно только то, что такой класс есть. И мне гораздо интересней,как я могу описать сущность входящую в схему данных сущность "вес". В общем, утверждать "храниться как объект - значит является объектом", ИМХО неверно.

5)
...и наконец а буду ли я делать все пять полей в записе "адрес" индексируемыми?

Цитата(Guest @ 31.7.2002, 22:35)

To Vyacheslav Вы верно заметили, что я в ходе объяснений использовал две разные схемы данных для "сложного" веса.

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

Цитата

Теперь ближе к примеру. Вы утверждаете, что "Вес" как объект не отображает предметную область и не является объектом (или не обязательно является объектом) в ООП языке программирования. По крайней мере я так понял это: совсем необязательно чтобы по каждому классу предполагалось создание объекта Теперь посмотрим на пример... Нет, теперь я не премину похвастаться, так как это позволит проиллюстрировать разницу в мышлении, ведущую к расхождениям. Итак, хвастовство: одно время в институте у меня была кличка "компилятор", потому что я мог, взяв Сишный текст, с ходу расставить на нем предупреждения и ошибки, которые выдаст компилятор, и для небольшой процедуры - написать ассемблер, в который она откомпилируется.  А вот теперь к примеру. Я использую класс Вес не для создания объктов, а для наследования от него. Но позвольте - как только мы начинаем думать о хранении информации, а не о проверке на корректность кода, эта разница превращается в абстракцию. Частью каждого объекта Яблоко является объект Вес, с которым мы работаем именно как с объектом, независимо от места расположения. Таким образом, тот пример, который "я бы поступил по другому", полностью аналогичен первой данной мною модели для сложного веса. Там тоже в каждом объекте яблоко вложен объект вес, и доступ к значению и единице измерения производится через этот вложенный объект. Заметьте, я Вас за язык не тянул. Вы сами предпочли завести класс "Вес", тем самым реализовав наличие объектов "Вес" и согласившись с моим утверждением, что "Вес есть объект".

Да, но при этом я указал, что чистых  объектов "Вес" не существует. Вы тут  ссылаетесь на способ хранения. Хранение является способом фиксации текущего состояния объекта и не обязано отражать реальную структуру объекта, поскольку правила восстановления и сохранения  объекта закладывается в ядре системы.  Произносимый текст может быть записан как текст или как магнитная запись. Причем не факт, последний вариант для понимания будет лучше. Поэтому нужно систему нужно рассматривать в совокупности.    И если Вы пройдетесь по моему примеру и запросите имя класса, Вы никогда не получите Вес. Это не значит что, я любой производный объект не могу рассматривать как объект Вес. У меня все могут быть приведены к объекту "Вес". Но не существует чистого объекта "Вес" - т.е не может существовать в принципе. И в моем примере "Вес" не является частью чего то(это вариант агрегатирования). Точно также, как нельзя сказать что Вес является частью Яблока. Хотя справедливо обратное Яблоко имеет Вес. Кстати не цепляйтесь особо к примерам.Я делал их как продолжение Ваших. Если бы я составлял пример  я бы, может быть, заложил Вес как атрибут в более объемный класс.

Цитата

Вернемся к необязательности наличия объекта при наличии класса. Увы, и тут Вы неправы! Создатели Явы, которые вознамерились довести ООП концепцию до конца, и преуспели в этом больше, чем кто-либо другой, давно уткнулись в такую необходимость. Результат: java.lang.Class. Каждый класс есть объект, вот так.

Я как то привык смотреть на классиков, а не на конкретные реализации.Тем более что java я не знаю. А в ООП  тоже допускается рассматривание класса как объекта. Данная концепция реализована Smalltalk и CLOS. Но в этой концепции класс рассматривается как объекта Метакласса - класса классов. В чистом С++ такого понятия нет но  в Builder & VCL реализована подобная конструкция конструкция
TMetaClass* Class = classid(TMyClass);
но это не имеет никакого отношения к объекту данного класса
TMyClass* MyClass = new TMyClass;
Думаю, что в java то же самое. Так что сославшись на java, Вы слукавили.   Поэтому мысль класс - это объект не нова. Но к данному вопросу отношения не имеет. У меня это факт нашел отражение в наличии системной таблицы Classes. Я утверждал, что не создаю объектов данного класса.  Возможности наложения  данного ограничения заложены в ООП : клиентами класса могут быть объекты и субклассы, но но не предусмотрен обязательное присутствие того и другого.  В С++ я могу наложить такое ограничение средствами языка.Предполагаю, что такие возможности имееются и в других языках ООП  

Цитата

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

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

Цитата

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

"Может ли ветер в голове испортить прическу?" Еще раз с самого начала. Я приводил в качестве примера схему, где вес является атомарным атрибутом, и это выглядело так:
[Яблоко1] ----<210>---> [Вес] <----<260>---- [Яблоко2]

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

По второму абзацу - я про Фому, а мне про Ерему. Если внимательно почитать этот тред, станет понятно, что тут разногласия именно по способу хранения. Чтобы не повторяться, только замечу, что я могуполучить "Вес" как имя класса. Не во всех языках, естественно.

Насчет явы - наверное, правильнее было написать "Например, создатели Ява...". Я не собирался провозглашать их первооткрывателями этого подхода и взял их как ближайший пример.

Цитата

Не думаете же Вы, что  я влез в эту беседу из теоретического интереса.

Почему бы и нет?

Цитата

К принятию такого подхода я никакого отношения не имел . Оно было принято на основе многомесячного исследования группы аналитиков.

Ужас какой!! Еще и денег, наверное, много взяли?

Напоследок еще один пример, который подскажет, зачем нужно то, что сделал я. Типичная ситуация изменения схемы данных: Вот у нас уже есть база с одним миллионом яблок с атомарным весом. И "вдруг" потребовалось добавить единицу измерения. (Чтобы сделать ситуацию более реальной, поменяйте "единицу измерения" на "валюту", и остальное соответствующе). Что мы будем делать в случае реляционной таблицы? Правильно, Alter table по миллиону записей. Что мы будем делать в варианте моего оппонента? Правильно, опять Alter table по миллиону записей. Правда, его, видимо, будет делать система (см. конструктор MS Access).
И только в моем варианте нам надо добавить один объект. Гибкость, ребята, гибкость! XML абсолютно неэффективен и дико избыточен, однако под него сейчас перетаскивают все подряд. По той же причине.

Реплика...

ALTER TABLE по миллиону записей - это конечно ужасно. Но и в Вашем случае, уважаемый Crimaniak, добавлением одного объекта ИМХО ну никак не обойдется. Поскольку мы меняем единицу измерения для миллиона УЖЕ существующих значений, то Вам по-крйней мере потребуется вставить в таблицу связей миллион записей со значением единицы измерения (например "кг."). Кроме того, поскольку Вы меняете схему Вам придется обновить по крайней мере еще миллион записей со значением веса в той же таблице. Тоже нехило;). Или я опять ошибаюсь?

Цитата

Напоследок еще один пример, который подскажет, зачем нужно то, что сделал я. Типичная ситуация изменения схемы данных: Вот у нас уже есть база с одним миллионом яблок с атомарным весом. И "вдруг" потребовалось добавить единицу измерения.

Я таких примеров не понимаю. Т.к это глупый подход.При правильном подходе  добавление единицы измерения никак не может повлиять на класс Яблоко. Вес не может меняться в зависимости от единицы измерения.  1000г =1 кг
Добавляется не поле, а экземпляр класса Единца Измерения. То же самое и с валютой. Не будете же Вы  бездумно создавать систему.
Вы так ничего и не поняли.  При нормальном  подходе таблицу перебивать не потребуется,, так как   таблица предназначена для хранения ДЕЛЬТЫ - то есть тех полей, которые отсутствуют в предыдущем базовом классе.    
Теперь мой пример было 1 миллион заказов(класс Заказ).  С некоторого момента ввели еще одну графу  (например налог с продаж). Сами понимаете, что все для предыдущих заказов НСП  не нужен. Я создаю класс Заказ1, производный от Заказ. Это выглядит: к первой создается еще одна таблица с одним полем, которого не хватает
Заказ    Заказ1
ID         ID
....        НПС
           ЗаказID

Причем в первой таблице так и осталось 1000000 записей, во второй ноль, пока не начнем  создавать Заказы1.
Как объединяются поля двух таблиц - объяснять надеюсь не надо  или  на всякий случай надо
select * from Заказ з, Заказ1 з1  where ЗаказID=з.ID  
А в программе  у меня это выглядит так - просматриваем старые заказы - ядро системы берет только одну таблицу - поля НПС нет, натолкнулись  на Заказ1 - сразу появится поле НПС.

Цитата

Ужас какой!! Еще и денег, наверное, много взяли?

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

Цитата

Я таких примеров не понимаю. Т.к это глупый подход.

Наоборот, очень хороший пример оказался, показательный. Вы ошиблись насчет модели Евгения, он ошибся насчет моей модели.

Цитата

Вы так ничего и не поняли.  При нормальном  подходе таблицу перебивать не потребуется,, так как   таблица предназначена для хранения ДЕЛЬТЫ - то есть тех полей, которые отсутствуют в предыдущем базовом классе.     Теперь мой пример было 1 миллион заказов(класс Заказ).  С некоторого момента ввели еще одну графу  (например налог с продаж). Сами понимаете, что все для предыдущих заказов НСП  не нужен. Я создаю класс Заказ1, производный от Заказ.

 Я-то понял, а вот Вы - нет. Я совершенно согласен насчет нормального подхода, но вот модель Евгения этого не предусматривает, так как он продолжает в упор не понимать смысл идеи и пугает нас необходимостью alter table, да еще и миллионом insert into. А вот мой вариант реализации - это и есть "нормальный подход" с вашей точки зрения, так как у меня все так и происходит. Мы Делаем новый объект сложносочиненного веса, делаем бывший вес его потомком и добавляем объект для единицы измерения. При этом старые объекты не имеют единицы измерения, что код, который нам в любом сдучае надо учить новый реалиям, воспринимает это как единицу изменения по умолчанию, а новые создаются уже с единицей.
Причем заметьте - реализация остается гибче, чем объектное представление. У Вас происходит такое неприятное явление, как накопление мусора. Так как в результате получается два класса там, где нам нужен один. А потом три... и так далее. Структура конечного класса отличается от того, что было бы создано, будь вес изначально сложным. (Это означает, что рано или поздно придется производить сборку мусора - переписывать код с нуля). И у нас возникают некоторые проблемы. Теперь нам нужен + для старого веса и нового, или приведение старого у новому. А что надо сделать, если мы хотим старый_вес+=новый_вес? Отвечать не надо. Я знаю, что эти все проблемы решаемы. Но! На физическом плане их не существует. Они - лишь следствие решения бороться с изменчивостью схемы данных путем наследования, которое изначально было придумано не для того.

Слегка дурацкий разговр получается. Я через пост пишу о том, что модель не имеет ничего общего с реализацией и с вопросами производительности, а уважаемый Crimaniak точно с такой же частотой начинает вещать, что де его система будет работать быстрее.  Так вот - я со всей ответсвенностью заявляю, что в моей  МОДЕЛИ  ALTER TABLE для таблицы с миллионом записей делается мгновенно . А SQL и реляционная модель - это совсем не одно и тоже.

И все же... раз уж зашла такая пъянка про производительность.... Ну ведусь я у своего уважаемого оппонента.  То что некоторые мои вопросы остаются неотвеченными... или например рассуждения о том, что вставка одной записи это более сложно, чем вставки пяти записей...ГЫ-ГЫ...  а что если там нет varchar'ов и не таблица не индексируется по всем полям?...но это благололучно проехали. ИМХО и так ясно.

Далее... ну предположим, что система часть информации о весах описывается старой схемой, а часть  - новой. Теперь мы хотим получить объект с весом "20","кг". Вы попробуйте изобразить такой запрос к системе хранения, что бы он обновременно брал и те и другие значенния. ИМХО - если получиться, то очень хитро. Дело в том, что стрелочки в схемах идут по-разному и, соотвественно JOIN'ы в запросах обращающихся к данным должны также идти по другому. Но насколько я понял, это тоже фигня. Там еще оказывается код есть .

(у меня на кухне ИИ есть. В холодильнике. Он мне анекдоты на ночь рассказывает)

А как же быть со следующим? (из Вашего раннего)

Цитата

Сделал такой программист базу, у товара есть цена, все работает. А потом потребовалось посмотреть статистику за три месяца, для которой накопительного счетчика не было. Ну, к примеру, коэффициент использования полок на складе, выраженный в рублях на погонный метр. И наступает большой Ёк. Почему? Потому что цена товара поменялась. А в базе цена - полем. И сидит программист и репу чешет, что делать. А делов-то всего - признать, что цена - это объект, сделать для цен таблицу и дать туда поля - значение, валюта, дата от и дата до.

Ну здесь то уж точно придется переделывать старые "объекты"  (Пусть их даже МИЛЛИОН!) в новую схему? Иди нет? Что то там "по-умолчанию будет?

Вооот!....и наконец мы добрались до JOIN'ов (я просто уверен, что эта тема будет опущена ). Перестройки схемы данных - это явление сравнительно редкое, но вот JOIN'ны встречаются спошь и рядом. Любая более-менее сложная опреация поиска или выборки скорее всего не обойдется без JOIN'нов. Но в том, что предлагается Вами, уважаемый Crimaniak, это просто чума. Я прикинул ...возмем тот же вес...  для того, что бы найти "20", "кг"
потребуется сделать не менее трех...даже четырех... нехилых JOIN'ов с предварительной выборкой из двух горячо любимых Вами таблиц... А что будет если надо найти адрес по пяти полям (причем использующих в условии оператор OR)? ИМХО именно поэтому вы и не любите сложные значения и предпочитаете все веса выражать строго в килограммах.

Сославшись на Дейта и на Конноли, могу утверждать, что JOIN является самой трудоемкой и доргостоящей операцией. Затраты на выполнения запроса зависят от числа JOIN'ов приблизительно по экспоненте. А у вас любая выборка без него (причем в больших количествах) не обходиться.

Во-первых, насчет индексирования. Не знаю, как у других, но моя практика показывает, что никогда нельзя заранее точно сказать, для каких полей индексы потребуются, а для каких - нет. А рассмотрение моих текущих проектов показывает, что подавляющее число полей - индексированы. Отсюда мы приходим к очень простой практической рекомендации: индексировать все поля, кроме разве что blob/text, потому что снижение производительности в результате наличия лишних индексов не идет ни в какое сравнение со случаем их отсутствия там, где надо. А если сделать только необходимые индексы, то по мере развития модели такая ситуация возникает. Причем, как правило, сначала эти тормоза незаметны, но с ростом базы начинают оказывать все большее влияние, пока программист не вынужден садиться за лог медленных запросов и смотреть, где какой индекс он забыл добавить. Таким образом, решение с полностью индексированной базой просто экономически выгоднее.
Во-вторых, насчет joins. Вопросы насчет реализации снимутся, если внимательно прочитать предыдущие письма - я там давал конкретные примеры, на которых видно, как все работает. В данном случае это будет выглядеть так.
Первый элементарный случай:
SELECT яблоки->\свойства\вес FROM \яблоки\%
Второй сложный случай:
SELECT яблоки->\свойства\вес\значение, яблоки->\свойства\вес\единица_измерения FROM \яблоки\%
Мы даже можем сделать так:
SELECT яблоки->\свойства\вес, яблоки->\свойства\вес\единица_измерения FROM \яблоки\%
(если захотим обеспечить толерантность старых запросов. но это неправильно.)

Цитата

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

 Этот фрагмент я заквотил, так как он иллюстрирует Ваше продолжающееся непонимание моей схемы. Объясняю на пальцах: у нас нет ситуации, когда часть данных хранится по старой схеме, а часть - по новой. Эта ситуация возникает только у Вас, и избавиться от нее Вы можете только при помощи ALTER TABLE. Мне же достаточно произвести изменения в паре объектов - и все яблоки приобретают вес по новой схеме. Единственное отличие от случая, когда мы создали бы сложную схему сразу - у нововведенных атрибутов есть значение по умолчанию (второй запрос выдаст NULL в единице_измерения для старых яблок), но такую схему часто имеет смысл предусмотреть еще при проектировании, так как это экономит место в базе за счет очень малого изменения кода.

Насчет быстродействия же - советую читать не только классиков, но и что-нибудь поновее, чтобы не говорить ерунды насчет экспоненты. Очень рекомендую посмотреть сайт http://www.innodb.com/ Я проверял - дело обстоит именно так, как там написано. И это правильно. Попробую и тут заранее пояснить на пальцах: про поиске по нескольким индексированным полям поиск происходит по индексам, и базе совершенно безразлично, к одной таблице относятся эти индексы или к разным, потому что все индексы независимы. У нас добавляется поиск еще в UNIQUE(INT) индексе на join, но и тут экспоненты никак не получается - штука, которая у нас получается, называется логарифм.

Цитата

Таким образом, решение с полностью индексированной базой просто экономически выгоднее.

Угу - это ваше сугубо личное мнение, которое не разделяют авторы руководств по разным севрерным и настольным рел. СУБД.

Далее. В своем последнем сообщении я говорил, не про то, как вы пишите запрос в СВОЕЙ системе, а про то, во что он преобразуется СИСТЕМОЙ при обращении к используемой (в нашем случае реляционной, что-то другое я обсуждать не буду) СУБД. Цитата (из вашего раннего)

Цитата

Получилось достаточно удобно, типа $recordset=$shop->executeOQL('SELECT parcels.*,parcels->\\shop\\parms\\products\\price as Price FROM \\shop\\orders\\%\\% as parcels ORDER BY parcels.Name'); Тут есть ветка \shop\orders, в ней лежит куча заказов, из каждого заказа растут посылки, вот они-то и выбираются с их ценами. Сначала все это транслируется в соответствующий SQL [SELECT parcels.*, lnk0.Value AS Price FROM o as o0,o as o1,o as parcels LEFT JOIN l_FLOAT AS lnk0 ON lnk0.FID=parcels.ID AND lnk0.TID=80 WHERE (o0.ParentID=25 AND o0.Name LIKE "orders" AND o1.ParentID=o0.ID AND parcels.ParentID=o1.ID) ORDER BY parcels.Name], а потом выполняется.

В последнем, ОТТРАНСЛИРОВАННОМ запросе связываение по JOIN'у выполняется два раза. Навсидку для каждого поля "сложного своства" связывание по JOIN'у будет выполняться два раза, т.е при поиске по пяти полям эта операция будет выполняться десять раз.Индексы-индексами, но связывать все-равно то придется.

Наконец. Предположим, произошло так, что в процессе использования системы вы прешли с элементарного веса на сложный. И что же для того, что бы получить значение нескольких весов (например НАЙТИ СУММАРНЫЙ ВЕС ВСЕХ ЯБЛОК) мне придется помнить, какие у яблок бывают разные схемы описания веса - одна для элементарной схемы, а другая для сложной?

Цитата

Первый элементарный случай: SELECT яблоки->\свойства\вес FROM \яблоки\% Второй сложный случай: SELECT яблоки->\свойства\вес\значение, яблоки->\свойства\вес\единица_измерения FROM \яблоки\% Мы даже можем сделать так: SELECT яблоки->\свойства\вес, яблоки->\свойства\вес\единица_измерения FROM \яблоки\% (если захотим обеспечить толерантность старых запросов. но это неправильно.)

Последний запрос меня не убеждает - 1) там явно используется две разные схемы хранения веса (это мне совсем не нравиться..... я уж ALTER tABLE один раз воспользуюсь, что бы потом мозги не парить насчет "а как там" ) и 2)  интересно во что он  оттранслируется?

Наконец- повторяю вопрос
А как же быть со следующим? (из Вашего раннего)

Цитата

Сделал такой программист базу, у товара есть цена, все работает. А потом потребовалось посмотреть статистику за три месяца, для которой накопительного счетчика не было. Ну, к примеру, коэффициент использования полок на складе, выраженный в рублях на погонный метр. И наступает большой Ёк. Почему? Потому что цена товара поменялась. А в базе цена - полем. И сидит программист и репу чешет, что делать. А делов-то всего - признать, что цена - это объект, сделать для цен таблицу и дать туда поля - значение, валюта, дата от и дата до.

То есть программисту что-то не нравится в уже существующих данных и он должен их поменять. Другими словами ему таки придется менять схему с элементарной на сложную для существующих значений. То есть "одной вставкой объекта" не обойтись - этот "объект" в СИСТЕМЕ ХРАНИЕНИЯ придется связывать с уже существующими значениями а так же добавлять в таблицу значений необходимую информацию о валюте и датах, также связывая ее с таблицой идентификаторов (и это все при тотальной индексации). Только не надо аргументировать фразами типа "таких случаев надо избегать" или "у меня такого бы не было". Предположим что такой случай произошел - надо производит все эти действия или нет?

1. Подсчет "навскидку" количества joins - неправильный. В том конкретном примере есть такая конструкция, как ...\\%\\% - подумайте над этим. (Да, процент означает именно то, что он означает в LIKE).
2. Я потерял надежду объяснить конкретно Вам, как это все работает. Если интересно понять, а не спорить со мной - возьмите листочек бумаги и опять же начните думать. За исходние данные можно такой факт, как то, что в моей схеме и в случае с яблоками, и в случае с ценами за период схема данных для всех объектов аналогично меняется изменением одной-двух записей в базе, при этом ничего перелинковывать не надо - тот же объект-цель меняет адрес.

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

Ээээхххх
а мне предстоит реализовать эту самую объектную прослойку для РСУБД.
......

Ну что, достаточно напугали автора топика?
Там где - то В НАЧАЛЕ статья какая-то прозвучала. По моему полный порожняк. Я вот на Cache пробовал что-то делать, мне не понравилось. Вся его хваленая (в 200 раз быстрее) производительность оказывается чисто внутренней и нафюг срезается при интеграции (может не совсем то слово) с чем-то реляционным. ИМХО: может быть, когда нибудь, но только не сегодня и уж тем более не сейчас.

Цитата(Oleg @ 26.7.2003, 10:13)

Вся его хваленая (в 200 раз быстрее) производительность оказывается чисто внутренней и нафюг срезается при интеграции (может не совсем то слово) с чем-то реляционным. ИМХО: может быть, когда нибудь, но только не сегодня и уж тем более не сейчас.

Нельзя ли поподробнее?
Как проводилась интеграция?
А то уж слишком категорично звучит.
Любая вещь, если сделана неправильно, будет плохо работать...

Цитата(Oleg @ 26.7.2003, 10:13)

Я вот на Cache пробовал что-то делать, мне не понравилось. Вся его хваленая (в 200 раз быстрее) производительность оказывается чисто внутренней и нафюг срезается при интеграции (может не совсем то слово) с чем-то реляционным. ИМХО: может быть, когда нибудь, но только не сегодня и уж тем более не сейчас.

А я вот попробовал на ObjectHaven (ObjectHaven на сайте компании Миратек): что примечательно - нет никаких проблем с интеграцией, т.к. вся СУБД оперирует COM объектами, включая и само ядро. При этом потерь производительности не наблюдается.
Плюс ко всему, нет собственного языка - пиши себе объекты базы данных на каком хочешь языке, лишь бы COM поддерживал.
Правда, является ли она "объектной" - разработчики что-то про "компонентную" СУБД говорят?