Немного уточню.
M>Стандарт ODMG (если не ошибаюсь в написании) как раз и предлагает такую работу. Связи между объектами задаются т.н. объектными ссылками,
точно
M>практически вся работа с данными происходит в кэше на клиенте (естественно толстом).
Этого в стандарте ни явно ни неявно нет. Наоборот возможна реализация (надо сказать наиболее концептуально чистая), когда обьекты "живут" на сервере и соответственно сервер выполняет их методы. Вроде даже кто-то из производителей такое уже предлагал. В идеале же нужен (и опять же возможен) смешанный вариант, для обеспечения максимальной эффективности.
M>Есть таже язык запросов OQL, в котором, правда есть возможность только читать данные. Все же изменения реализуются процедурно.
Процедурно следует здесь понимать как "не иначе, как отправкой сообщения обьекту (вызовом его метода)". Но это, надо сказать, один из краеугольных камней ООП'а, поэтому вряд ли может считаться концептуальным недостатком.
M>Какое-то распространение такие БД получили, но не сказать, чтобы очень уж заметное.
К сожалению так. Но для определенных задач (множество разнородных данных со сложными связями) еще не все потеряно.
M>По-видимому из-за ряда причин: M>- стандарт ODMG опирается исключительно на язык С++.
Это неверно. Непосредственно в стандарте ODMG 3.0 определены C++ binding, Smalltalk binding и Java binding. Субьективно заметно больше реализаций как раз таки с Java интерфейсом, а не с C++.
M>- отсутствие в языке OQL средств модификации данных.
Неверно. Отсутствует явная конструкция типа update. Но модификация данных возможна (и предполагается) через вызовы методов у обьектов. Сделано именно так для того чтобы не нарушалась семантика обьектной модели.
M>- базы данных разных производителей чаще всего несовместимы друг с другом.
Есть такое. Несовместимы из-за либо неполного (недостаточного) соответствия стандарту ODMG или отсутствием всякой поддержки ODMG. Похожая несовместимость есть и между различными РСУБД в области расширений к SQL'ю.
Здравствуйте, WeCom, Вы писали: M>>- отсутствие в языке OQL средств модификации данных. WC>Неверно. Отсутствует явная конструкция типа update. Но модификация данных возможна (и предполагается) через вызовы методов у обьектов. Сделано именно так для того чтобы не нарушалась семантика обьектной модели.
К сожалению, ODMG отказывается иметь дело с семантикой методов. Поскольку неизвестно даже, имеет ли метод побочные эффекты, а если имеет, то какие, пока что не удалось получить эффективной реализации. Модификация данных через select — это выстрел себе в ногу.
... << RSDN@Home 1.1.0 stable >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Да кто бы спорил. Еще 10 лет назад стало ясно, что честное динамическое программирование не рулит для поиска оптималього плана.
Эээ. Кому 10. А кто и до сих пор оптимизаторы влоб пишет.
S>Просто сам факт существования пространства планов для фиксированного запроса обеспечивается математикой. Точно так же, как оптимизатор С++ пользуется коммутативностью, дистрибутивностью и прочими алгебраическими свойствами целых операций для переделки кода. То, что у тебя написано a = b*c+d*c+e*c вовсе не означает, что действительно будут выполняться три умножения.
В оптимизаторах компиляторов перестановка выражений мало что дает. Самые действенные оптимзиации — это автоинлайнинг, назначение регистров часто используемым переменным и вынесение статических выражений за пределы циклов. А эти оптимизации с точки зрения математики приметивны и в сущьности оной не трубуют.
S>Без знаний о математике компилятор никогда не сможет сделать ничего полезного с выражением Add(Add(Mul(b, c), Mul(d, c)), Mul(c, e)).
Самое что полезное он может тут сделатьвынести Mul за пределы. Для этого сложный мат-аппарат не нужен. Достаточно знать, что Mul не изменяет параметры.
S> (В плюсах есть небольшой шанс выполнить таки оптимизацию благодаря инлайнингу, который собственно переводит все эти абстрактные размышления архитектора на язык низкоуровневой математики)).
Поверь. Математикой тем и не пахнет. А там где она встречается компиляторы тормозят как черт знает что. Умное, что есть в компиляторах — это ДКА при разборе и применение шаблонов. Эдакие матиматики выпускаются нашей начальной школой.
S>Кроме того, помимо всяких прикладывания пальцев к носу (т.е. эвристик), оптимизатор RDBMS использует непреложные математические факты, собирая статистику, при оценке стоимости вариантов плана.
Это да. Только вот там сплошная арифметика. В общем, все примитивно, но в больших объемах и скучей хаков.
S> Эвристики всего лишь позволяют сузить пространство до разумных пределов
Она позволяет во многих ситуациях вообще не пользоваться ресурсоемкими рассчетами. Просто если мы угодали, что джоин идет по схеме звезда, то нифиги чего-то вычислять. Находим таблицу с макимальным количеством данных и клеим остальные по упрощенной схеме, ну, или что-то вроде того.
S>И то, я совершенно не уверен, что эти эвристики — это набор "хаков" и к ним неприменима математическая теория.
Чистейшей воды хаки. Вычленение шаблонов и применение ничем не обоснованных (но провернных на практике) подходов.
... << RSDN@Home 1.1.2 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>В оптимизаторах компиляторов перестановка выражений мало что дает. Самые действенные оптимзиации — это автоинлайнинг, назначение регистров часто используемым переменным и вынесение статических выражений за пределы циклов. А эти оптимизации с точки зрения математики приметивны и в сущьности оной не трубуют.
С оговоркой — для процессоров x86 like архитектуры. А вот уже для IA64 интелям над оптимизаторам пришлось очень серьезно попотеть, именно оптимизатором занимался центр в НН.
Здравствуйте, Sinclair, Вы писали:
S>Без знаний о математике компилятор никогда не сможет сделать ничего полезного с выражением Add(Add(Mul(b, c), Mul(d, c)), Mul(c, e)). (В плюсах есть небольшой шанс выполнить таки оптимизацию благодаря инлайнингу, который собственно переводит все эти абстрактные размышления архитектора на язык низкоуровневой математики)).
Ты наверное не так Влада понял — он имеет ввиду что математика конечно важна и полезна, но всем известна. Ничего нового именно в математике придумать пока не получается. Однако ж на рынке не все оптимизаторы одинаковы, и заслуга в этом не математики а именно тех самых эвристик.
Здравствуйте, AndrewVK, Вы писали:
AVK>Ты наверное не так Влада понял — он имеет ввиду что математика конечно важна и полезна, но всем известна. Ничего нового именно в математике придумать пока не получается. Однако ж на рынке не все оптимизаторы одинаковы, и заслуга в этом не математики а именно тех самых эвристик.
Позволю с Вами несколько не согласится. Математика математикой а алгоритмы и структуры это всего лишь одно из подразделений той же математики (физики). И к задаче приведенной Владом математика не имеет никакого отношение, а только к реализации решений данной задачи в конкретной СУБД . Т.К. ручками это делается очень легко, но СУБД ведь умные с оптимизаторами запросов и должны обыгрывать по алгоритмам живого программиста. Хе-хе.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, AndrewVK, Вы писали:
AVK>С оговоркой — для процессоров x86 like архитектуры. А вот уже для IA64 интелям над оптимизаторам пришлось очень серьезно попотеть, именно оптимизатором занимался центр в НН.
Там в архитиктуру процессора была вынесена идеология по которой ему кмпилятор должне выдвать хинты. Это уже даже не оптимизация в компиляторе, а целая архитектура. Вот тольео не ясно выживет ли это направление или его забьет тупой и простой как 3 копейки AMD64.
... << RSDN@Home 1.1.2 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, AndrewVK, Вы писали:
AVK>С оговоркой — для процессоров x86 like архитектуры. А вот уже для IA64 интелям над оптимизаторам пришлось очень серьезно попотеть, именно оптимизатором занимался центр в НН.
Там в архитиктуру процессора была вынесена идеология по которой ему кмпилятор должне выдвать хинты. Это уже даже не оптимизация в компиляторе, а целая архитектура. Вот тольео не ясно выживет ли это направление или его забьет тупой и простой как 3 копейки AMD64.
... << RSDN@Home 1.1.2 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, AndrewVK, Вы писали:
AVK>С оговоркой — для процессоров x86 like архитектуры. А вот уже для IA64 интелям над оптимизаторам пришлось очень серьезно попотеть, именно оптимизатором занимался центр в НН.
Там в архитиктуру процессора была вынесена идеология по которой ему кмпилятор должне выдвать хинты. Это уже даже не оптимизация в компиляторе, а целая архитектура. Вот тольео не ясно выживет ли это направление или его забьет тупой и простой как 3 копейки AMD64.
... << RSDN@Home 1.1.2 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VD> Вот тольео не ясно выживет ли это направление или его забьет тупой и простой как 3 копейки AMD64.
Наверное, забьёт. IA64 вон сколько разрабатывали, и времени и людей. Архитектура полностью новая, отдельная.
А в AMD64 сплошная совместимость. Шутка ли, 32-битный код на AMD64 выполняется быстрее, чем на Pentium4. Ну не могли они и тут и там всё как следует оптимизировать. Пороху не хватит.
