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

Блок А.Н.
Правда пока это не кажется удобным, тот же SQL делает это изящнее.

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

SELECT *
FROM значение переменной, в которой идентификатор объекта
WHERE id=значение переменной, в которой ид. экземпляра

нужно еще связать с переменными другого языка программирования?:)

Блок А.Н.Вы что-то противоестественное делаете, либо я вас не понял.
в каше взять характиристики объекта будет так
&sql(select field1,field2 into :val1,:val2 from table where id=:id)
Что противоестественное?:)
select я написал и Вы написали;
from тоже;
where тоже;
а вот что за field1, field2, ... val1, val2?
Вы не подумайте, конечно, что я не понимаю что это у Вас такое:) Но напишите, пожалуйста, то, что договаривались. Нужно взять все характеристики объекта. Кажется не принципиальным, но давайте будем точны:) Все-таки, покороче будет выражение, наверное.
И после этого объясните, все-таки в чем изящество. И зачем запускается оптимизатор запросов.

Блок А.Н.Я не понял, что вам не понравилось в моем запросе. Вы этого не сказали, а я предсказывать мысли других не люблю. Еще ошибусь и буду спорить и доказывать то чего вы не думали. Такая потеха мне не нужна.
Тем более запрос вы поняли, я не сомневаюсь. И даже не сомневаюсь, что вы знали о таких запросах до того, как я его написал. Но почему-то делаете по другому, а тут уже непонятно почему.

Очень типично для этого форума. Так долго просили конкретики, и, как только она появилась (причем довольно простая, первопопавшаяся:)), тут же отказались обсуждать по существу.
Что значит читать мысли?
Что же непонятного в функции получения ВСЕХ характеристик объекта ?
Я должен интерпретировать таким образом, что на SQL в Cache это не реализуемо?
Нужно написать сто (например) field и сто val?
И десять-то неприятно писать и сверять порядок:)
Блок А.Н.
Изящество в том, что можно взять запрос по нескольким таблицам/сущностям в одной формуле.
Оптимизатор запроса запускается для выбора оптимальных индексов и в целом плана запроса.
Мы до этого дойдем (хотя про статистику "запросов" я, в том числе и Вам лично, уже писал). Когда рассмотрим один из более простых примеров, который мы сейчас обсуждаем. Что я должен уточнить, если Вам, действительно, не понятен пример?

Блок А.Н.Мне непонятен смысл получения всех характеристик.
В одну корзину ложим рост, вес, состояние в браке, число детей, образование.
В чем смысл? Это разные параметры, в чем необходимость их мешать в одну кучу переменных?

:) Удивительно, учитывая последнее (правда мне опять придется его уточнить, чтобы не отклоняться от сути) предложение в этом Вашем сообщении.
Я же ничего не говорил о росте и детях. Я привел пример ПЕРВОЙ ПОПАВШЕЙСЯ функции в КОСУБД, которая, конечно же, нередко используется. Если в объекте всего десять характеристик и все они могут быть нужны. Не нужно за меня ничего додумывать сутками:) Напишите этот несчастный код:)
Блок А.Н.
Тогда это хреновое проектирование. Докажите конкретными примерами, зачем это нужно?
Кстати, на каше это легко реализуется, но смысла этого я не вижу.
Ну в том, что проектирование хреновое, я даже не сомневался. Сделайте это легко, только не "на каше", а на SQL в Cache.

doublefintАндрей Леонидович, возможно получение всех характеристик одного объекта по его id, действительно неудобный пример для демонстрации возможностей SQL. Все таки он скорее для обработки множеств. И вот тогда Sum, Where и Order ....
Я уже много раз говорил о СТАТИСТИКЕ "ЗАПРОСОВ" в сложных системах. Можно ведь так и сказать: да это мы пишем НЕ НА SQL, и продолжить что-то еще обсуждать. Правильно?
Но тогда сразу возникнет вопрос: а что это? "Огласите весь список, пожалуйста":)
Получение всех, нескольких, одной характеристики экземпляра.
Создание экземпляра.
Обновление экземпляра.
Получение всех экземпляров объекта B, связанных с конкретным экземпляром объекта A и их обработка.
И др.
Для всего это не нужен SQL. А это до 80%:) Вот когда с ними закончим, перейдем к оставшимся 20-ти:)

Блок А.Н.На самом деле у каше SQL все прекрасно и в этом вопросе, и этот же пример реализуется очень красиво.

Так это же замечательно!
Блок А.Н.
Но есть два но:
1.Если сама такая постановка задачи является типичной, то возникает вопрос, а правильно ли проведено проектирование? Правильна ли архитектура системы? Оптимальна ли схема хранения в такой системе?

Отличный вопрос! В РМД (на отношениях без связей между объектами) проектировать безошибочней, чем в КОМД (на объектах и связях)? Интересная идея давайте ее обсудим:) Но получать характеристики объекта (атрибуты отношения), и выполнять другие операции такого рода все равно ведь нужно...
Блок А.Н.
2. Андрей Леонидович очень легко, при малейшей зацепке переходит в атаку.

В какую атаку? При какой зацепке? Я сижу работаю, мне не до атак и выискивания зацепок.
Блок А.Н.
При этом очень туманно обрисовывая свою позицию и свои методы (да, он на это ответит что сто раз уже говорил, но я не заметил). Мне хотелось бы развернуть ситуацию. А.Л. предлагает - мы это оцениваем и обсуждаем. По крайней мере мы уже сдвинулась от абстрактного обличительства к каким-то конкретным альтернативам.

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

doublefint
Но в том же, уже упоминавшемся КОМД продукте, это можно делать уже сейчас. Вместо ссылки всегда использовать связь, а связь с характеристиками это просто скрытый (не выделенный разработчиком, то ли из лени, то ли по другим причинам) объект?

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

Блок А.Н.У вас это, похоже, вопрос религиозный: пусть сложно, неудобно, трудоемко, провоцирует ошибки, но зато ПРАВИЛЬНО!

Оригинальный код на SQL, ничего не скажешь:) Но я примерно так себе это и представлял:)
Блок А.Н.
А на мой взгляд правильно то что просто, удобно, гибко, быстро пишется и быстро выполняется, легко отлаживается, дает большие возможности (не зажато конкретным фреймворком) и другие плюшки.

Это, как я понимаю про сто field, и сто val с контролем правильности порядка с помощью органов зрения:) Я так и знал.
Блок А.Н.
Так вот, с этой точки зрения, у вас все ОЧЕНЬ плохо. И вы не торопитесь доказывать, что это не так, предпочитая вместо этого доказывать, что у всех все плохо.
То я что-то у Вас рекламирую, то доказываю:) Мне этого ничего не нужно, так как Вы даже не представляете насколько у меня все хорошо:) И мне хорошо знакома природа Вашего нежелания обсуждать что-то по существу...

Alexey MaslovТак и не понял, каким образом модель, о которой шла речь, является "классической". Термина "КОМД" не нашел не только на sql.ru, но и в И-нете в целом.

А зачем мы отвлеклись от сути обсуждаемых вопросов?
Да, я ввел этот термин. Нормальный термин, отражающий суть. Чтобы, с одной стороны, не путать с моделями, корни которых в ООП, а, с другой, проследить определенную связь с объекто-ориентированными сетевой и иерархической моделями (которые достаточно классические:))
Alexey Maslov
Если брать известные классы моделей:
- ER. Это, правда, концептуальный уровень, но Бредятина как раз постулирует сближение концептуального и логического уровней. ER-модель богаче "КОМД", в частности, допустимы связи "многие ко многим и ко многим", а также связи могут иметь свойства.

Связи "многие ко многим и ко многим" - никакие не связи, а у связей в КОМД тоже есть характеристики ("свойство" - неудачный термин, так как это объективная особенность объекта, которая не может непосредственно наблюдаться). И я, как раз объясняю, что это не корректно.
Alexey Maslov
- ООБД, ODMG ~ хранимость объектов ОО-языков программирования. Тоже не то. Между прочим, в списке ООСУБД на первом месте значится Cache' (удачно имя придумали :)
- ОРБД - объектные расширения РМД (пользовательские типы данных, наследование, etc) - тоже не то.

Да, я и объяснял что ООП к теории БД никакого отношения не имеет.
Alexey Maslov
Хотелось бы увидеть ссылочку на любые материалы по "КОМД", коль скоро ведутся работы по ее формализации и развитию.
Ссылочки мне неизвестны. А материалы свои при случае вышлю:) Кстати на медсофте говорил сотрудникам СП АРМ о планируемом большом проекте, визитку свою оставил... Так что где-то у Вас должны быть контакты:)

Блок А.Н.
Если у вас есть чудесный "чистый", "правильный" план дома, в котором после реализации невозможно будет жить - в топку таких "архитекторов". Модель не нужна ни для чего, кроме реализации, она должна помогать, защищать от ошибок, а не мешать.
Значит план не чудесный и не правильный. Вы окончательно себя запутали:) Лучше бы код на SQL написали, который по Вашим словам, очень красиво получает характеристики экземпляра:)