Пока интересуют общие вопросы, обзорные статьи и т.п.
Т.е. уже не "это такие штучки, которые вам позволяют представлять..." (т.е. для полных ламеров), но и не глобально-углубленные научные труды.
Дело в том, что требуется создать нечто, очень по своим принципам похожее на ООБД и не хочется инветить байсикл
Гуглю, естественно, интенсивно, но, может, кто поделится из личных запасов.
... << RSDN@Home 1.1.3 stable >>
--
К вашим услугам,
Re: Объектно-ориентированные БД: основные принципы, организа
Spaider -> "Объектно-ориентированные БД: основные принципы, организация," :
S> Ищутся материалы по %subj%.
S> Пока интересуют общие вопросы, обзорные статьи и т.п. S> Т.е. уже не "это такие штучки, которые вам позволяют представлять..." S> (т.е. для полных ламеров), но и не глобально-углубленные научные S> труды.
S> Дело в том, что требуется создать нечто, очень по своим принципам S> похожее на ООБД и не хочется инветить байсикл
S> Гуглю, естественно, интенсивно, но, может, кто поделится из личных S> запасов.
Ага. Ты есть тот амбициозный руководитель проекта по созданию ООБД!
Spaider -> "Re[2]: Объектно-ориентированные БД: основные принципы, орган" :
S> Здравствуйте, hrg, Вы писали:
hrg>> Ага. Ты есть тот амбициозный руководитель проекта по созданию hrg>> ООБД!
S> Амбиций у меня хватает, но про какого руководителя ты говоришь, я не S> понимаю.
Здравствуйте, Spaider, Вы писали:
S>Ищутся материалы по %subj%.
1. Мне кажеться, что лучший способ --- попробовать! Меня тоже в свое время заинтересовали вопросы построения ООБД (в плане самообразования). Я ограничился тем, что скачал Cache' и документацию к нему с их сайта. Чем сразу вызвал большую заинтересованость их филиала в Москве. Меня забросали документацией, советами о том, как лучше начинатьвнедрять Cache' на больших проектах, периодически интересуются, не угас ли мой пыл. Ограничился я лишь написанием небольшой демки, которая работала с Cache' через COM. Но впечатления, в том числе и от работы группы поддержки, остались только положительные.
2. ООБД можно положить на обыкновенную реляционную структуру. Не так это и страшно. Один из способов описан в статье Анатолия Тенцера "Бд — хранилище объектов". Второй способ принят у нас --- для базовых классов, допускающих наследование вводится поле --- ID класса. Кстати, примерно такой же способ применяется и в Cache'.
Вообще, существуетопасность, что сам термин ООБД исползуется в качестве бренда, и многие производители трактуют его каждый раз по своему... Поэтому (повторяюсь) я бы просто ознакомился со всеми существующими системами...
Re[4]: Объектно-ориентированные БД: основные принципы, орган
А, нет
Это не про меня Я вообще Москву и москвичей не очень-то люблю. Живу в Минске.
Какая жалость, что мой вопрос высплыл после вышеупомянутой хрени. Не то время, не то место
Да и проект мой не является в чистом виде ООБД. Просто в процесее обдумывания модели данных накрыло: "так вот что это такое, вот куда копать-то надо...."
... << RSDN@Home 1.1.3 stable >>
--
К вашим услугам,
Re[2]: Объектно-ориентированные БД: основные принципы, орган
Здравствуйте, Mystic, Вы писали:
M>2. ООБД можно положить на обыкновенную реляционную структуру. Не так это и страшно. Один из способов описан в статье Анатолия Тенцера "Бд — хранилище объектов".
А можно ссылку поточнее
... << RSDN@Home 1.1.3 stable >>
--
К вашим услугам,
Re: Объектно-ориентированные БД: основные принципы, организа
Вообще, в свое время, в журналах "Открытые системы" и "СУБД" эта тема часто освещалась. На сайте www.osp.ru через поиск еще и другие статьи найти можно.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re: Объектно-ориентированные БД: основные принципы, организа
Здравствуйте, Spaider, Вы писали:
S>Ищутся материалы по %subj%.
S>Пока интересуют общие вопросы, обзорные статьи и т.п. S>Т.е. уже не "это такие штучки, которые вам позволяют представлять..." (т.е. для полных ламеров), но и не глобально-углубленные научные труды.
S>Дело в том, что требуется создать нечто, очень по своим принципам похожее на ООБД и не хочется инветить байсикл
S>Гуглю, естественно, интенсивно, но, может, кто поделится из личных запасов.
Гугл оно конечно, хорошо. Но будте осторожны:
В области объектно-ориентированных баз данных на протяжении последних нескольких лет наблюдается поразительное затишье, которое одни склонны воспринимать как упадок технологии, а другие — как переход технологии в зрелое и устойчивое состояние. По моим наблюдениям, подобное затишье временами ведет к возникновению заблуждений и даже мифов у людей, близких к ИТ, но не являющихся специалистами в области баз данных. Одно из таких заблуждений состоит в том, что человек принимает сложившийся у него в голове набор терминов (объект, атрибут, метод, класс, наследование и т.д.) за общепризнанную объектно-ориентированную модель данных.
Сергей Кузнецов, Открытые Системы
Вот краткая ретроспектива темы, от самого начала до конца.
Основополагающая статья. С этого начинаем:
М. Аткинсон и др., «Манифест систем объектно-ориентированных баз данных», // СУБД, № 4, 1995. http://www.osp.ru/dbms/1995/04/23.htm
Этим продолжаем:
Л.А. Калиниченко, «Стандарт систем управления объектными базами данных ODMG-93: краткий обзор и оценка состояния». // СУБД, № 1, 1996. http://www.osp.ru/dbms/1996/01/46.htm
Далее читаем это:
Арк Андреев, Дмитрий Березкин, Роман Самарев, «Внутренний мир объектно-ориентированных СУБД». // Открытые системы, № 3, 2001. http://www.osp.ru/os/2001/03/047.htm
А потом вот это, о "перспективах отрасли" и месте в ней ООБД:
С.Д. Кузнецов. «Три манифеста баз данных: ретроспектива и перспективы». Доклад на конференции «Базы данных и информационные технологии XXI века», Москва, сентябрь 2003, http://www.citforum.ru/database/articles/manifests.
Ну и, естественно, смотрим на всякие Жасмины и Каше, или про что еще в этих статьях узнаете.
Re[2]: Объектно-ориентированные БД: основные принципы, орган
Mystic -> "Re: Объектно-ориентированные БД: основные принципы, организа" :
M> объектов[/url]". Второй способ принят у нас --- для базовых классов, M> допускающих наследование вводится поле --- ID класса. Кстати, M> примерно такой же способ применяется и в Cache'.
Т.е. наследники и базовый класс в одной таблице?
Yury Kopyl aka hrg | http://id.totem.ru | Все вышесказанное является моим
личным мнением и может быть использовано против вас
Posted via RSDN NNTP Server 1.9 beta
Re[3]: Объектно-ориентированные БД: основные принципы, орган
Mystic -> "Re[3]: Объектно-ориентированные БД: основные принципы, орган" :
M> Здравствуйте, hrg, Вы писали:
hrg>> Т.е. наследники и базовый класс в одной таблице?
M> Примерно вот так:
Ага. Наследование с таблицей для каждого класса. А как потом осбираете
значения атрибутов по разным полям? Это же куча запросов чтобы создать один
объект?
Yury Kopyl aka hrg | http://id.totem.ru | Только взял боец гитару, сразу
видно — гармонист...
Posted via RSDN NNTP Server 1.9 beta
Re[5]: Объектно-ориентированные БД: основные принципы, орган
Здравствуйте, hrg, Вы писали:
hrg>Ага. Наследование с таблицей для каждого класса. А как потом осбираете hrg>значения атрибутов по разным полям? Это же куча запросов чтобы создать один hrg>объект?
А как насчет объектно-реляционного отображения? По-моему, все объектные БД на сегодняшний день являются сырыми, впрочем, как и OQL. Имхо, ORM — это хорошее решение проблемы.
Re[2]: Объектно-ориентированные БД: основные принципы, орган
M>2. ООБД можно положить на обыкновенную реляционную структуру. Не так это и страшно.
Не хочу быть догматичным, но по моему это очень страшно. Такое не может называться OODB. В реляционной структуре нет месту одному из главных плюсов ООDB, а именно прямому доступу к объекту.
С уважением, Gleb.
Re[3]: Объектно-ориентированные БД: основные принципы, орган
GlebZ пишет:
> M>2. ООБД можно положить на обыкновенную реляционную структуру. Не так > это и страшно. > Не хочу быть догматичным, но по моему это очень страшно. Такое не > может называться OODB. В реляционной структуре нет месту одному из > главных плюсов ООDB, а именно прямому доступу к объекту. >
То есть? OR-mapping позволяет представить объект как набор записей в БД
(и наоборот).
--
С уважением,
Alex Besogonov (alexy@izh.com)
Posted via RSDN NNTP Server 1.9
Sapienti sat!
Re[4]: Объектно-ориентированные БД: основные принципы, орган
Здравствуйте, Cyberax, Вы писали:
C>То есть? OR-mapping позволяет представить объект как набор записей в БД C>(и наоборот).
Абсолютно точно. Это действительно называется OR-mapping. ООDB — не является OR-mapping, именно в термине BD. То есть, это должно быть отдельное хранилище данных. И во вторых, ООDB, кроме того, что может хранить оптимизированно не записи а именно объекты, может обеспечивать прямой доступ к состоянию этих объектов (по OID). В ORM и соответвсенно РСУБД доступ осуществляется по Primary Key, что сильно тормознее. Поэтому утверждается что ООБД со сложными типами данных работает быстрее.
С уважением, Gleb.
Re[5]: Объектно-ориентированные БД: основные принципы, орган
GlebZ пишет:
> C>То есть? OR-mapping позволяет представить объект как набор записей в БД > C>(и наоборот). > Абсолютно точно. Это действительно называется OR-mapping. ООDB — не > является OR-mapping, именно в термине BD. То есть, это должно быть > отдельное хранилище данных. И во вторых, ООDB, кроме того, что может > хранить оптимизированно не записи а именно объекты, может обеспечивать > прямой доступ к состоянию этих объектов (по OID). В ORM и > соответвсенно РСУБД доступ осуществляется по Primary Key, что сильно > тормознее. Поэтому утверждается что ООБД со сложными типами данных > работает быстрее.
Далеко не факт, так как доступ к рядам в таблице RDB тоже может
производиться по быстрому идентификатору ряда, если он известен
(например, если взят из отношения). То есть при желании RDB будет
работать так же быстро, хотя для этого уже нужен нестандартный SQL.
Гораздо интереснее посмотреть другие фичи ODB, например, GC для
персистентных объектов. Потом еще интереснее посмотреть как они
реализованы в существующих продуктах, и сделать соответствующие выводы.
--
С уважением,
Alex Besogonov (alexy@izh.com)
Posted via RSDN NNTP Server 1.9
Sapienti sat!
Re[6]: Объектно-ориентированные БД: основные принципы, орган
Здравствуйте, Cyberax, Вы писали:
C>GlebZ пишет:
>> C>То есть? OR-mapping позволяет представить объект как набор записей в БД >> C>(и наоборот). >> Абсолютно точно. Это действительно называется OR-mapping. ООDB — не >> является OR-mapping, именно в термине BD. То есть, это должно быть >> отдельное хранилище данных. И во вторых, ООDB, кроме того, что может >> хранить оптимизированно не записи а именно объекты, может обеспечивать >> прямой доступ к состоянию этих объектов (по OID). В ORM и >> соответвсенно РСУБД доступ осуществляется по Primary Key, что сильно >> тормознее. Поэтому утверждается что ООБД со сложными типами данных >> работает быстрее.
C>Далеко не факт, так как доступ к рядам в таблице RDB тоже может C>производиться по быстрому идентификатору ряда, если он известен C>(например, если взят из отношения). То есть при желании RDB будет C>работать так же быстро, хотя для этого уже нужен нестандартный SQL.
Неверно. OID должен быть инваринтным. То есть уникальным не только при жизни, но и после смерти. С идентификатором ряда (который поддерживается далеко не всеми РСУБД) такое не гарантируется. К тому же, как обеспечить быструю работу с ссылками. И объект не обязательно является кортежом. Объект многомерен.
C>Гораздо интереснее посмотреть другие фичи ODB, например, GC для C>персистентных объектов. Потом еще интереснее посмотреть как они C>реализованы в существующих продуктах, и сделать соответствующие выводы.
GC не обязательное условие OODB. Насколько я знаю, в Versant ссылочная целостность обеспечивается тем, что после удалении объекта, все ссылки на него становятся null'ом. В GemStone действительно GC.
С уважением, Gleb.
Re[2]: Объектно-ориентированные БД: основные принципы, орган
Объектная База не нуждается в таблицах и пр. т.к. она объектная!
Такой подход к проектированию обусловлен работой с РСУБД и ОРСУБД.
Объектная база данных позволяет использовать ПОЛНОСТЬЮ объектных подход к проетированию и последующей реализации баз данных.
А вообще моя коллекция ссыло лежит здесь. Там есть все реализации и много литературы.
Re[3]: Объектно-ориентированные БД: основные принципы, орган
Здравствуйте, BaZa, Вы писали:
BZ>А вообще моя коллекция ссыло лежит здесь. Там есть все реализации и много литературы.
Спасибо, однозначно в закладки. Однако ж давняя темя. Продукт, по поводу которого я затеял этот вопрос, совсем недавно зарелизился. К сожалению, ООБД там и не пахнет Тем не менее, почитать есть что.
Кстати, у меня в Опере билда 7364b на вашей страничке наблюдается баг -- выпадающие менюшки сдвинуты, и попасть в них нелегко Вот как это выглядит
--
К вашим услугам,
Re[3]: Объектно-ориентированные БД: основные принципы, орган
Здравствуйте, BaZa, Вы писали:
BZ>Объектная База не нуждается в таблицах и пр. т.к. она объектная!
Любой объект это всего навсего структура определенного размера,а хранить данные одинакового размера все же лучше в таблицах.
Так любой менеджер памяти основанный на массиве порвет любой супер пупер универсальный менеджер памяти.
Или уже есть файловый GC ?????
... << RSDN@Home 1.1.4 beta 4 rev. 303>>
и солнце б утром не вставало, когда бы не было меня
Re[4]: Объектно-ориентированные БД: основные принципы, орган
Никто и не говорит про универсальность ООСУБД"ов...
Да, при таких условиях: Любой объект это всего навсего структура определенного размера,а хранить данные одинакового размера все же лучше в таблицах, лучше использовать РСУБД. А когда размер не определен (а есои и сама структура сама не определена) и пр. то вот тогда лучше использовать ООСУБД.
Re[4]: Объектно-ориентированные БД: основные принципы, орган
Здравствуйте, Serginio1, Вы писали:
S>Здравствуйте, BaZa, Вы писали:
BZ>>Объектная База не нуждается в таблицах и пр. т.к. она объектная! S> Любой объект это всего навсего структура определенного размера,а хранить данные одинакового размера все же лучше в таблицах.
Фишка в том, что в объектных БД объекты могут очень легко изменять свой размер. А хранилище должно с этим эффективно справляться.
А могут легко изменять свой размер потому, что в одном объекте может быть масса других объектов совершенно по разному организованных. Например, объект может иметь в качестве атрибута вектор переменного размера из других объектов. Эти подчиненные объекты могут сами иметь в качестве атрибутов, скажем, множество других объектов и т.д. При отображении этого хозяйства в таблицы РСУБД требуются дополнительные усилия. А в ООСУБД объект сериализуется в двоичный блок и этот блок запихивается в файл хранилища. И, обычно, чтение/запись производится одной операцией, а не поиском нужных компонентов по разным табличкам (но и здесь возможны варианты, если ООСУБД поддерживает продвинутые ссылки между объектами).
S> Так любой менеджер памяти основанный на массиве порвет любой супер пупер универсальный менеджер памяти. S> Или уже есть файловый GC ?????
Конечно. У меня, например, хранилище реализовано так, чтобы переиспользовать место от удаленных объектов. И не нужно делать явных уплотнений файлов БД.
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[5]: Объектно-ориентированные БД: основные принципы, орган
Здравствуйте, BaZa, Вы писали:
BZ>Никто и не говорит про универсальность ООСУБД"ов...
BZ>Да, при таких условиях: Любой объект это всего навсего структура определенного размера,а хранить данные одинакового размера все же лучше в таблицах, лучше использовать РСУБД. А когда размер не определен (а есои и сама структура сама не определена) и пр. то вот тогда лучше использовать ООСУБД.
Я в данном случае говорю только об оптимальном хранении данных. Которые должна использовать ООСУБД. Любой объект имеет определенный размер по определению, но поля могут иметь неопределенный тип. Возможность динамического добавление свойств это сахар, основанный на коллекциях.
... << RSDN@Home 1.1.4 beta 4 rev. 303>>
и солнце б утром не вставало, когда бы не было меня
Re[5]: Объектно-ориентированные БД: основные принципы, орган
S>>Здравствуйте, BaZa, Вы писали:
BZ>>>Объектная База не нуждается в таблицах и пр. т.к. она объектная! S>> Любой объект это всего навсего структура определенного размера,а хранить данные одинакового размера все же лучше в таблицах.
E>Фишка в том, что в объектных БД объекты могут очень легко изменять свой размер. А хранилище должно с этим эффективно справляться. E>А могут легко изменять свой размер потому, что в одном объекте может быть масса других объектов совершенно по разному организованных.
Прежде всего объекты это ссылки и поля имеют некую структуру позволяющие определить местонахождение объекта, но сам он должен оптимально хранится, иначе можно на такую фрагментацию нарваться. Кстати изменение размера достигается очень легко, если представить объект как некоторый связный список кусков определенного размера. E> Например, объект может иметь в качестве атрибута вектор переменного размера из других объектов. Эти подчиненные объекты могут сами иметь в качестве атрибутов, скажем, множество других объектов и т.д. При отображении этого хозяйства в таблицы РСУБД требуются дополнительные усилия. А в ООСУБД объект сериализуется в двоичный блок и этот блок запихивается в файл хранилища. И, обычно, чтение/запись производится одной операцией, а не поиском нужных компонентов по разным табличкам (но и здесь возможны варианты, если ООСУБД поддерживает продвинутые ссылки между объектами).
Да уж представляю как некое дерево с миллионами вершин сериализуется и десериализуется. В данном случае я говорю лишь об оптимальном хранении объектов, а не доступе к объектам.
S>> Так любой менеджер памяти основанный на массиве порвет любой супер пупер универсальный менеджер памяти. S>> Или уже есть файловый GC ?????
E>Конечно. У меня, например, хранилище реализовано так, чтобы переиспользовать место от удаленных объектов. И не нужно делать явных уплотнений файлов БД.
Это обычная оочень старая техника, которая применяется как в Менеджерах памяти, так и в БД.
... << RSDN@Home 1.1.4 beta 4 rev. 303>>
и солнце б утром не вставало, когда бы не было меня
Re[5]: Объектно-ориентированные БД: основные принципы, орган
Зачем так усложнять себе жизнь? не нужно думать о хранении на таком низком уровне. поэтому и покупаются коммерческие СУБД, чтобы переложить такие задачи на нее. Когда к нам приезжали специалисты Versant (обучать нас , мы тоже пытались показать им на каком уровне мы работаем (это был низкий уровень), так вот они пришли от этого в ужас. Не нужно делать ручками то, что за вас делает сервер БД.
Re[6]: Объектно-ориентированные БД: основные принципы, орган
Здравствуйте, TheBeard, Вы писали:
TB>Мне случалось работать с СУБД, где это было не так. Просто Вы привыкли TB>мыслить в терминах "таблиц".
TB>Serginio1 wrote:
>> Любой объект имеет определенный размер по определению, но поля могут >> иметь неопределенный тип.
А можно помотреть на объект (класс) неопределенного размера ?????
Про динамические свойства уже писал. Я в данном случае веду разговор об оптимальном хранении данных.
Здравствуйте, Serginio1, Вы писали:
S>Здравствуйте, BaZa, Вы писали:
BZ>>Никто и не говорит про универсальность ООСУБД"ов...
BZ>>Да, при таких условиях: Любой объект это всего навсего структура определенного размера,а хранить данные одинакового размера все же лучше в таблицах, лучше использовать РСУБД. А когда размер не определен (а есои и сама структура сама не определена) и пр. то вот тогда лучше использовать ООСУБД. S> Я в данном случае говорю только об оптимальном хранении данных. Которые должна использовать ООСУБД. Любой объект имеет определенный размер по определению, но поля могут иметь неопределенный тип. Возможность динамического добавление свойств это сахар, основанный на коллекциях.
Современные СУБД могут хранить изменяющиеся по длине данные (см varchar в MS SQL, varchar2 в Oracle). Проблема не в хранилище. Проблема в инкапсуляции данных. Объект — это не просто набор полей сохраняемый в постоянном хранилище (как это описано в ORDB). Объект — обладает поведением, что не очень нравится реляционной алгебре.
С уважением, Gleb.
Re[7]: Объектно-ориентированные БД: основные принципы, орган
BZ>>>Да, при таких условиях: Любой объект это всего навсего структура определенного размера,а хранить данные одинакового размера все же лучше в таблицах, лучше использовать РСУБД. А когда размер не определен (а есои и сама структура сама не определена) и пр. то вот тогда лучше использовать ООСУБД. S>> Я в данном случае говорю только об оптимальном хранении данных. Которые должна использовать ООСУБД. Любой объект имеет определенный размер по определению, но поля могут иметь неопределенный тип. Возможность динамического добавление свойств это сахар, основанный на коллекциях. GZ>Современные СУБД могут хранить изменяющиеся по длине данные (см varchar в MS SQL, varchar2 в Oracle). Проблема не в хранилище. Проблема в инкапсуляции данных. Объект — это не просто набор полей сохраняемый в постоянном хранилище (как это описано в ORDB). Объект — обладает поведением, что не очень нравится реляционной алгебре.
Хранение изменяющихся данных это не проблема, помнишь как хранятся длинные строки в 1С, правда легче хранить их как список.
На данном этпае я поднял именно проблему хранения, а не поведения объектов.
Считай это проблема менеджера файловой памяти.
... << RSDN@Home 1.1.4 beta 4 rev. 303>>
и солнце б утром не вставало, когда бы не было меня
Re[4]: Объектно-ориентированные БД: основные принципы, орган
Здравствуйте, Serginio1, Вы писали:
S> Или уже есть файловый GC ?????
Мало того. Во многих ООБД с помощью GC обеспечивается ссылочная целостность. Объект удаляется из базы после удаления последней ссылки.
С уважением, Gleb.
Re[5]: Объектно-ориентированные БД: основные принципы, орган
Здравствуйте, GlebZ, Вы писали:
GZ>Здравствуйте, Serginio1, Вы писали:
S>> Или уже есть файловый GC ????? GZ>Мало того. Во многих ООБД с помощью GC обеспечивается ссылочная целостность. Объект удаляется из базы после удаления последней ссылки.
Основная задача GC не столько сбор мусора, сколько дефрагментация памяти, и сдвижки указателя на конец использованной кучи. И при всем этом объекты размером более 80 кб не подвергаются дефрагментации. А в БД могут существовать милларды объектов. И если идет много удалений то сочувствую пользователям данной БД
... << RSDN@Home 1.1.4 beta 4 rev. 303>>
и солнце б утром не вставало, когда бы не было меня
Re[6]: Объектно-ориентированные БД: основные принципы, орган
Здравствуйте, Serginio1, Вы писали:
S>Здравствуйте, GlebZ, Вы писали:
GZ>>Здравствуйте, Serginio1, Вы писали:
S>>> Или уже есть файловый GC ????? GZ>>Мало того. Во многих ООБД с помощью GC обеспечивается ссылочная целостность. Объект удаляется из базы после удаления последней ссылки. S> Основная задача GC не столько сбор мусора, сколько дефрагментация памяти, и сдвижки указателя на конец использованной кучи. И при всем этом объекты размером более 80 кб не подвергаются дефрагментации. А в БД могут существовать милларды объектов. И если идет много удалений то сочувствую пользователям данной БД
Можешь точно так же посочуствовать и пользователям РСУБД. Удаление миллионов строк точно такая же, тяжелая операция (к тому же логгируемая).
Вообще сравнивать GC NET и GC какой-нибудь OODB очень неблагодарное дела. Они работают в разных условиях. Я не знаю в какой момент удаляется объект физически(асинхронно, или синхронно после потери последней ссылки), но GC так и остается GC. А дефрагментироваться и многие РСУБД умеют (иногда вынужденно).
С уважением, Gleb.
Re[8]: Объектно-ориентированные БД: основные принципы, орган
Здравствуйте, Serginio1, Вы писали:
S>Здравствуйте, GlebZ, Вы писали:
BZ>>>>Да, при таких условиях: Любой объект это всего навсего структура определенного размера,а хранить данные одинакового размера все же лучше в таблицах, лучше использовать РСУБД. А когда размер не определен (а есои и сама структура сама не определена) и пр. то вот тогда лучше использовать ООСУБД. S>>> Я в данном случае говорю только об оптимальном хранении данных. Которые должна использовать ООСУБД. Любой объект имеет определенный размер по определению, но поля могут иметь неопределенный тип. Возможность динамического добавление свойств это сахар, основанный на коллекциях. GZ>>Современные СУБД могут хранить изменяющиеся по длине данные (см varchar в MS SQL, varchar2 в Oracle). Проблема не в хранилище. Проблема в инкапсуляции данных. Объект — это не просто набор полей сохраняемый в постоянном хранилище (как это описано в ORDB). Объект — обладает поведением, что не очень нравится реляционной алгебре. S> Хранение изменяющихся данных это не проблема, помнишь как хранятся длинные строки в 1С, правда легче хранить их как список. S> На данном этпае я поднял именно проблему хранения, а не поведения объектов. S> Считай это проблема менеджера файловой памяти.
Если ты говоришь о проблеме с variant. При выполнении запроса для многих операций нужна информация о типе. Ну не может быть построен план запроса, если нет точной информации о типе полей. Максимум что есть в РСУБД — LOB, с которыми практически ничего нельзя сделать. Разве что явно получить, и явно сохранить. Сейчас появились система хранения xml — но это уже отдельный механизм.
С уважением, Gleb.
Re[7]: Объектно-ориентированные БД: основные принципы, орган
GZ>Вообще сравнивать GC NET и GC какой-нибудь OODB очень неблагодарное дела. Они работают в разных условиях. Я не знаю в какой момент удаляется объект физически(асинхронно, или синхронно после потери последней ссылки), но GC так и остается GC. А дефрагментироваться и многие РСУБД умеют (иногда вынужденно).
Дефрагментация для таблиц в большинстве и не нужно, т.к. обычно организуется список удаленных записей и используются повторно при вставке новой записи, хотя все зависит от организаци, может нужна вся история изменения записей
Если у тебя есть ссылочки на файловый GC какой-нибудь OODB буду очень благодарен. Меня это интересует чисто теоретически, для повышения умственного уровня. Нам 1С программистам без этого нельзя.
... << RSDN@Home 1.1.4 beta 4 rev. 303>>
и солнце б утром не вставало, когда бы не было меня
Re[9]: Объектно-ориентированные БД: основные принципы, орган
GZ>Если ты говоришь о проблеме с variant. При выполнении запроса для многих операций нужна информация о типе. Ну не может быть построен план запроса, если нет точной информации о типе полей. Максимум что есть в РСУБД — LOB, с которыми практически ничего нельзя сделать. Разве что явно получить, и явно сохранить. Сейчас появились система хранения xml — но это уже отдельный механизм.
Глеб пойми меня интересует как организовано хранение данных в Объектно-ориентированные БД.
Меня РСУБД мало интересуют, я с локальными БД работаю в том числе и на прямую через API.
В конце концов хочу свою Объектно-ориентированные БД залудить
... << RSDN@Home 1.1.4 beta 4 rev. 303>>
и солнце б утром не вставало, когда бы не было меня
Re[8]: Объектно-ориентированные БД: основные принципы, орган
Здравствуйте, Serginio1, Вы писали:
S>Здравствуйте, GlebZ, Вы писали:
GZ>>Вообще сравнивать GC NET и GC какой-нибудь OODB очень неблагодарное дела. Они работают в разных условиях. Я не знаю в какой момент удаляется объект физически(асинхронно, или синхронно после потери последней ссылки), но GC так и остается GC. А дефрагментироваться и многие РСУБД умеют (иногда вынужденно).
S> Дефрагментация для таблиц в большинстве и не нужно, т.к. обычно организуется список удаленных записей и используются повторно при вставке новой записи, хотя все зависит от организаци, может нужна вся история изменения записей S> Если у тебя есть ссылочки на файловый GC какой-нибудь OODB буду очень благодарен. Меня это интересует чисто теоретически, для повышения умственного уровня. Нам 1С программистам без этого нельзя.
У меня сейчас с траффиком проблемы. Попробуй погуглить — ключевые слова GemStone Garbage Collector. Где то я видел такую информацию.
С уважением, Gleb.
Re[10]: Объектно-ориентированные БД: основные принципы, орга
Здравствуйте, Serginio1, Вы писали:
S>Здравствуйте, GlebZ, Вы писали:
GZ>>Если ты говоришь о проблеме с variant. При выполнении запроса для многих операций нужна информация о типе. Ну не может быть построен план запроса, если нет точной информации о типе полей. Максимум что есть в РСУБД — LOB, с которыми практически ничего нельзя сделать. Разве что явно получить, и явно сохранить. Сейчас появились система хранения xml — но это уже отдельный механизм.
S> Глеб пойми меня интересует как организовано хранение данных в Объектно-ориентированные БД. S> Меня РСУБД мало интересуют, я с локальными БД работаю в том числе и на прямую через API. S> В конце концов хочу свою Объектно-ориентированные БД залудить
Во блин, народу прибыло. Сколько народу писал, пишет и будет писать OODB.
Со своей стороны я поступил так. Рассмотрел модель хранения MS SQL (тогда еще 7.0), и Oracle (по какой версии уже не помню). Модель хранения на диске, в принципе у них нормально описаны в доках(за некоторыми для меня не важными исключениями). За основу взял MS SQL в силу простоты. После этого построил модель адресации. Чтобы один и тот же объект можно было адресовать как на диске, так и в памяти. Получил при этом два типа OID — логический OID для адресации извне, и физический OID с помощью которою получал адрес в памяти. При маршализации OID из логического в физический объект поднимался с диска (если он не был уже загружен). Менеджер памяти пользовался достаточно сложной структурой — что-то между хэш-таблицей и B+ деревом. На этом мой интерес кончился, продолжились будни.
С уважением, Gleb.
Re[11]: Объектно-ориентированные БД: основные принципы, орга
Здравствуйте, GlebZ, Вы писали:
S>> Глеб пойми меня интересует как организовано хранение данных в Объектно-ориентированные БД. S>> Меня РСУБД мало интересуют, я с локальными БД работаю в том числе и на прямую через API. S>> В конце концов хочу свою Объектно-ориентированные БД залудить GZ>Во блин, народу прибыло. Сколько народу писал, пишет и будет писать OODB. GZ>Со своей стороны я поступил так. Рассмотрел модель хранения MS SQL (тогда еще 7.0), и Oracle (по какой версии уже не помню). Модель хранения на диске, в принципе у них нормально описаны в доках(за некоторыми для меня не важными исключениями). За основу взял MS SQL в силу простоты. После этого построил модель адресации. Чтобы один и тот же объект можно было адресовать как на диске, так и в памяти. Получил при этом два типа OID — логический OID для адресации извне, и физический OID с помощью которою получал адрес в памяти. При маршализации OID из логического в физический объект поднимался с диска (если он не был уже загружен). Менеджер памяти пользовался достаточно сложной структурой — что-то между хэш-таблицей и B+ деревом. На этом мой интерес кончился, продолжились будни.
Я проще. Объекты это просто обертка над записью, привязанные к какому либо хранилищу. В записи прописывается точное место в подстриме.
Задача объекта считать данные, через свойства обратиться к полям, в том числе и ссылочным и вариантным.
Однотипные объекты хранились ввиде птаблиц (подстримов). Вся БД в едином стриме.
Для обмена хотел применить аналог твоего OID.
Связь подчинения ввиде двухнаправленных списков. Итд. Хотел транзации приделать. А потом "Да кому это нужно"
и забросил это дело. А руки чешуться
Хотя для некоторых задач применяю ее.
... << RSDN@Home 1.1.4 beta 4 rev. 303>>
и солнце б утром не вставало, когда бы не было меня
Re[12]: Объектно-ориентированные БД: основные принципы, орга
Здравствуйте, Serginio1, Вы писали:
S> Я проще. Объекты это просто обертка над записью, привязанные к какому либо хранилищу. В записи прописывается точное место в подстриме. S> Задача объекта считать данные, через свойства обратиться к полям, в том числе и ссылочным и вариантным. S> Однотипные объекты хранились ввиде птаблиц (подстримов). Вся БД в едином стриме. S> Для обмена хотел применить аналог твоего OID. S> Связь подчинения ввиде двухнаправленных списков. Итд. Хотел транзации приделать. А потом "Да кому это нужно" S> и забросил это дело. А руки чешуться S> Хотя для некоторых задач применяю ее.
У меня руки чешутся сделать подобный DTO объект.
Что касается стрима — то он сильно подвержен дефрагментации. Страничная адресация с балансировкой по B+ tree типу в данном случае значительно более устойчивее. Всегда знаешь сколько байт поднимаешь с диска, быстрый поиск свободного пространства. А если еще задвинуть экстент по размеру кластера диска, то скорость доступа увеличивается на порядок. Есть конечно некоторый недостаток в избыточности, если объекты не попадают на границу экстента, и проблема организации хранения объекта большего чем экстент. Но в первом случае — производительность значительно важней, во втором случае — решабельно.
С уважением, Gleb.
Re[6]: Объектно-ориентированные БД: основные принципы, орган
Здравствуйте, Serginio1, Вы писали:
E>>Фишка в том, что в объектных БД объекты могут очень легко изменять свой размер. А хранилище должно с этим эффективно справляться. E>>А могут легко изменять свой размер потому, что в одном объекте может быть масса других объектов совершенно по разному организованных. S> Прежде всего объекты это ссылки и поля имеют некую структуру позволяющие определить местонахождение объекта, но сам он должен оптимально хранится, иначе можно на такую фрагментацию нарваться. Кстати изменение размера достигается очень легко, если представить объект как некоторый связный список кусков определенного размера.
Объекты -- ссылки?
Атрибуты объектом могут быть ссылками.
А так же объект может агрегировать другие объекты (которые не могут рассматриваться в БД как отдельные сущности).
E>> Например, объект может иметь в качестве атрибута вектор переменного размера из других объектов. Эти подчиненные объекты могут сами иметь в качестве атрибутов, скажем, множество других объектов и т.д. При отображении этого хозяйства в таблицы РСУБД требуются дополнительные усилия. А в ООСУБД объект сериализуется в двоичный блок и этот блок запихивается в файл хранилища. И, обычно, чтение/запись производится одной операцией, а не поиском нужных компонентов по разным табличкам (но и здесь возможны варианты, если ООСУБД поддерживает продвинутые ссылки между объектами). S> Да уж представляю как некое дерево с миллионами вершин сериализуется и десериализуется. В данном случае я говорю лишь об оптимальном хранении объектов, а не доступе к объектам.
Да нормально сериализуется. Особенно, если сериализация идет непосредственно на диск. В чем проблемы-то?
S>>> Так любой менеджер памяти основанный на массиве порвет любой супер пупер универсальный менеджер памяти. S>>> Или уже есть файловый GC ?????
E>>Конечно. У меня, например, хранилище реализовано так, чтобы переиспользовать место от удаленных объектов. И не нужно делать явных уплотнений файлов БД. S> Это обычная оочень старая техника, которая применяется как в Менеджерах памяти, так и в БД.
Так а тебя что интересует? Чтобы освободившиеся блоки затем объединялись в крупные свободные фрагменты?
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[13]: Объектно-ориентированные БД: основные принципы, орга
GZ>У меня руки чешутся сделать подобный DTO объект. GZ>Что касается стрима — то он сильно подвержен дефрагментации. Страничная адресация с балансировкой по B+ tree типу в данном случае значительно более устойчивее. Всегда знаешь сколько байт поднимаешь с диска, быстрый поиск свободного пространства. А если еще задвинуть экстент по размеру кластера диска, то скорость доступа увеличивается на порядок. Есть конечно некоторый недостаток в избыточности, если объекты не попадают на границу экстента, и проблема организации хранения объекта большего чем экстент. Но в первом случае — производительность значительно важней, во втором случае — решабельно.
Чтение и запись идет страницами. Сначала хотел организовать кэширование страниц, но посмотрев на то, что система сама их кэширует отказался (пока). Для каждой таблицы свой набор страниц. Так что если запись находится на двух страницах особенно и не сказывается.
. За счет хранения подчиненных записей ввиде списков позволило отказаться от индексов на этот тип (например многострочная часть документа). Скорости на том этапе больше и не надо,Порядка 400 000 подчиненных записей за 7 сек. При кэшировании страниц и при отложенной записи можно увеличить и на порядок. Только такой цели не было.
Эх а все равно интересно помучиться
... << RSDN@Home 1.1.4 beta 4 rev. 303>>
и солнце б утром не вставало, когда бы не было меня
Re[7]: Объектно-ориентированные БД: основные принципы, орган
Здравствуйте, eao197, Вы писали:
E>Здравствуйте, Serginio1, Вы писали:
E>>>Фишка в том, что в объектных БД объекты могут очень легко изменять свой размер. А хранилище должно с этим эффективно справляться. E>>>А могут легко изменять свой размер потому, что в одном объекте может быть масса других объектов совершенно по разному организованных. S>> Прежде всего объекты это ссылки и поля имеют некую структуру позволяющие определить местонахождение объекта, но сам он должен оптимально хранится, иначе можно на такую фрагментацию нарваться. Кстати изменение размера достигается очень легко, если представить объект как некоторый связный список кусков определенного размера.
E>Объекты -- ссылки? E>Атрибуты объектом могут быть ссылками. E>А так же объект может агрегировать другие объекты (которые не могут рассматриваться в БД как отдельные сущности).
В терминологии Валуе и Ссылочных типов. Смотря в какой БД. В самопальной можно все,что угодно. E>>> Например, объект может иметь в качестве атрибута вектор переменного размера из других объектов. Эти подчиненные объекты могут сами иметь в качестве атрибутов, скажем, множество других объектов и т.д. При отображении этого хозяйства в таблицы РСУБД требуются дополнительные усилия. А в ООСУБД объект сериализуется в двоичный блок и этот блок запихивается в файл хранилища. И, обычно, чтение/запись производится одной операцией, а не поиском нужных компонентов по разным табличкам (но и здесь возможны варианты, если ООСУБД поддерживает продвинутые ссылки между объектами). S>> Да уж представляю как некое дерево с миллионами вершин сериализуется и десериализуется. В данном случае я говорю лишь об оптимальном хранении объектов, а не доступе к объектам.
E>Да нормально сериализуется. Особенно, если сериализация идет непосредственно на диск. В чем проблемы-то?
Не спорю. Только такое хранение данных не оптимально.
S>>>> Так любой менеджер памяти основанный на массиве порвет любой супер пупер универсальный менеджер памяти. S>>>> Или уже есть файловый GC ?????
E>>>Конечно. У меня, например, хранилище реализовано так, чтобы переиспользовать место от удаленных объектов. И не нужно делать явных уплотнений файлов БД. S>> Это обычная оочень старая техника, которая применяется как в Менеджерах памяти, так и в БД.
E>Так а тебя что интересует? Чтобы освободившиеся блоки затем объединялись в крупные свободные фрагменты?
Нет в данном случае разговор идет об оптимальном хранении, был выдвинут тезис что в ООБД таблицы отсутствуют, как класс
А раз так, то должен быть некий менеджер файловой памяти или что типа GC.
... << RSDN@Home 1.1.4 beta 4 rev. 303>>
и солнце б утром не вставало, когда бы не было меня
Re[8]: Объектно-ориентированные БД: основные принципы, орган
<...> E>>Да нормально сериализуется. Особенно, если сериализация идет непосредственно на диск. В чем проблемы-то?
S> Не спорю. Только такое хранение данных не оптимально.
<...> S>>> Это обычная оочень старая техника, которая применяется как в Менеджерах памяти, так и в БД.
E>>Так а тебя что интересует? Чтобы освободившиеся блоки затем объединялись в крупные свободные фрагменты? S> Нет в данном случае разговор идет об оптимальном хранении, был выдвинут тезис что в ООБД таблицы отсутствуют, как класс S> А раз так, то должен быть некий менеджер файловой памяти или что типа GC.
Тогда нужно озвучить критерий оптимальности.
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[9]: Объектно-ориентированные БД: основные принципы, орган
Здравствуйте, eao197, Вы писали:
E>Тогда нужно озвучить критерий оптимальности.
Да критерий то один. Минимизация фрагментации памяти, и быстрый поиск свободного места.
Чем в общем и занимаются менеджеры памяти. Табличная (или в связных массивах) Организация хранения записей одинакового размера оптимизируют эту задачу.
Вот в общем то и все.
... << RSDN@Home 1.1.4 beta 4 rev. 303>>
и солнце б утром не вставало, когда бы не было меня
Re[14]: Объектно-ориентированные БД: основные принципы, орга
Здравствуйте, Serginio1, Вы писали:
S> Чтение и запись идет страницами. Сначала хотел организовать кэширование страниц, но посмотрев на то, что система сама их кэширует отказался (пока). Для каждой таблицы свой набор страниц. Так что если запись находится на двух страницах особенно и не сказывается. За счет хранения подчиненных записей ввиде списков позволило отказаться от индексов на этот тип (например многострочная часть документа). Скорости на том этапе больше и не надо,Порядка 400 000 подчиненных записей за 7 сек. При кэшировании страниц и при отложенной записи можно увеличить и на порядок. Только такой цели не было.
Здоровски.
Только сразу вопрос: каким образом адресуется единичный объект?
Отложенная запись без транзакционного механизма увеличит вероятность ошибки файла за счет недописанной полностью записи. S> Эх а все равно интересно помучиться
Re[10]: Объектно-ориентированные БД: основные принципы, орга
Здравствуйте, Serginio1, Вы писали:
S>Здравствуйте, eao197, Вы писали:
E>>Тогда нужно озвучить критерий оптимальности. S> Да критерий то один. Минимизация фрагментации памяти, и быстрый поиск свободного места. S> Чем в общем и занимаются менеджеры памяти. Табличная (или в связных массивах) Организация хранения записей одинакового размера оптимизируют эту задачу. S> Вот в общем то и все.
Понятно.
Только мне кажется, что быстрый поиск свободного места и фрагментация напрямую не связаны.
Так же не считаю, что для всех задач фрагментация является проблемой. Например, есть некий маршрутизатор получает из одного канала запрос, сохраняет его ID в базу (типа BerkeleyDB) и передает в другой канал уже со своим ID. При получении ответа должен по своему ID найти исходный ID и отослать ответ в исходный канал. После этого удалить информацию из БД. При стабильной нагрузке окажется, что все изменения вносятся в один и тот же фрагмент файла данных БД (пусть и большой, если нагрузка велика). И даже если в какой-то момент этот фрагмент сильно фрагментирован, то это не будет играть роли, т.к. ОС закэширует этот фрагмент.
А как вы записями одинакового размера будете хранить атрибуты-строки, которые могут изменять свой размер?
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[14]: Объектно-ориентированные БД: основные принципы, орга
Здравствуйте, Serginio1, Вы писали:
S> . За счет хранения подчиненных записей ввиде списков позволило отказаться от индексов на этот тип (например многострочная часть документа). Скорости на том этапе больше и не надо,Порядка 400 000 подчиненных записей за 7 сек. При кэшировании страниц и при отложенной записи можно увеличить и на порядок. Только такой цели не было.
А какой размер одной записи?
S> Эх а все равно интересно помучиться
Это точно, солидарен.
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[15]: Объектно-ориентированные БД: основные принципы, орга
Здравствуйте, GlebZ, Вы писали:
GZ>Здравствуйте, Serginio1, Вы писали:
S>> Чтение и запись идет страницами. Сначала хотел организовать кэширование страниц, но посмотрев на то, что система сама их кэширует отказался (пока). Для каждой таблицы свой набор страниц. Так что если запись находится на двух страницах особенно и не сказывается. За счет хранения подчиненных записей ввиде списков позволило отказаться от индексов на этот тип (например многострочная часть документа). Скорости на том этапе больше и не надо,Порядка 400 000 подчиненных записей за 7 сек. При кэшировании страниц и при отложенной записи можно увеличить и на порядок. Только такой цели не было. GZ>Здоровски. GZ>Только сразу вопрос: каким образом адресуется единичный объект?
Есть номер записи в каждой записи. По нему находится страница на которыю (с которой) прописывается. GZ>Отложенная запись без транзакционного механизма увеличит вероятность ошибки файла за счет недописанной полностью записи.
Согласен, но чем только не пожертвуешь ради скорости. Подождем быструю энэргонезависимую память для введения быстрого транзакционного механизма.
... << RSDN@Home 1.1.4 beta 4 rev. 303>>
и солнце б утром не вставало, когда бы не было меня
Re[15]: Объектно-ориентированные БД: основные принципы, орга
Здравствуйте, eao197, Вы писали:
E>Здравствуйте, Serginio1, Вы писали:
S>> . За счет хранения подчиненных записей ввиде списков позволило отказаться от индексов на этот тип (например многострочная часть документа). Скорости на том этапе больше и не надо,Порядка 400 000 подчиненных записей за 7 сек. При кэшировании страниц и при отложенной записи можно увеличить и на порядок. Только такой цели не было.
E>А какой размер одной записи?
Там такой тест, считывается имя файла, размер и подчиненные строки которые разбиваются на связанные записи по 24 символа.
Сама запись вроде 48 байт (24 байта , номер строки, prev, next Int64 чего мелочиться то) S>> Эх а все равно интересно помучиться
E>Это точно, солидарен.
... << RSDN@Home 1.1.4 beta 4 rev. 303>>
и солнце б утром не вставало, когда бы не было меня
Re[16]: Объектно-ориентированные БД: основные принципы, орга
Здравствуйте, Serginio1, Вы писали:
GZ>>Отложенная запись без транзакционного механизма увеличит вероятность ошибки файла за счет недописанной полностью записи. S> Согласен, но чем только не пожертвуешь ради скорости. Подождем быструю энэргонезависимую память для введения быстрого транзакционного механизма.
Если БД не гарантирует надежной фиксации транзакции, то как же ее БД-то называть?
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[16]: Объектно-ориентированные БД: основные принципы, орга
Здравствуйте, Serginio1, Вы писали:
S>Здравствуйте, eao197, Вы писали:
E>>Здравствуйте, Serginio1, Вы писали:
S>>> . За счет хранения подчиненных записей ввиде списков позволило отказаться от индексов на этот тип (например многострочная часть документа). Скорости на том этапе больше и не надо,Порядка 400 000 подчиненных записей за 7 сек. При кэшировании страниц и при отложенной записи можно увеличить и на порядок. Только такой цели не было.
E>>А какой размер одной записи? S> Там такой тест, считывается имя файла, размер и подчиненные строки которые разбиваются на связанные записи по 24 символа. S> Сама запись вроде 48 байт (24 байта , номер строки, prev, next Int64 чего мелочиться то)
А результат в 7 секунд был получен на пустой БД или уже на фрагментированной?
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[11]: Объектно-ориентированные БД: основные принципы, орга
Здравствуйте, eao197, Вы писали:
E>Здравствуйте, Serginio1, Вы писали:
S>>Здравствуйте, eao197, Вы писали:
E>>>Тогда нужно озвучить критерий оптимальности. S>> Да критерий то один. Минимизация фрагментации памяти, и быстрый поиск свободного места. S>> Чем в общем и занимаются менеджеры памяти. Табличная (или в связных массивах) Организация хранения записей одинакового размера оптимизируют эту задачу. S>> Вот в общем то и все.
E>Понятно.
E>Только мне кажется, что быстрый поиск свободного места и фрагментация напрямую не связаны. E>Так же не считаю, что для всех задач фрагментация является проблемой. Например, есть некий маршрутизатор получает из одного канала запрос, сохраняет его ID в базу (типа BerkeleyDB) и передает в другой канал уже со своим ID. При получении ответа должен по своему ID найти исходный ID и отослать ответ в исходный канал. После этого удалить информацию из БД. При стабильной нагрузке окажется, что все изменения вносятся в один и тот же фрагмент файла данных БД (пусть и большой, если нагрузка велика). И даже если в какой-то момент этот фрагмент сильно фрагментирован, то это не будет играть роли, т.к. ОС закэширует этот фрагмент.
E>А как вы записями одинакового размера будете хранить атрибуты-строки, которые могут изменять свой размер?
А почему на Вы????
Вот описание. Прошу сильно не смеяться
Эта простенькая иерархическая БД позволяетхранить как струтурированные данные
так и неструктурированные. Пока без индексов и полностью не протестированная.
Основным классом для всего этого безобразия послужил TSSStream.
Суть его заключается в хранении данных в связанных страницах
одинакового размера наподобии файловой системы FAT но последовательность страниц
хранится отдельно в иерархическом массиве.
Родителем всех таблиц служит TSSCustomTable. Это виртуальный стрим взаимодействующий с
основным хранилищем (стримом) через класс TSSBD. Суть его таже, что и TSSStream.
Хранилищем цепочек последовательных страниц является класс TTableCepochki.
Это единственный класс которыйхранит ссылки на данные
в абсолютных смещениях в основном хранилище. Запись TTableCepochki имеет следующий вид
TCepochki=Record
CurrentRecord:Int64;// ссылка на смещение текущей страницы
NextCepochka:Int64;// сылка на следующую страницуend;
и должна быть обязательно кратна размеру страницы, чтобы запись не попадала на разрыв
страниц т.к. чтение идет напрямую в основном хранилище.
За информацию о таблицах отвечает класс TTableInfoOFTables структура его записи
PInfoOfTable=^TInfoOfTable;
TInfoOfTable= record
Cappacity:Int64; // Емкость таблицы
Size:Int64; // Объем записанных данных
RecordCount: Int64; // Количество записей в таблице если данные хранятся записями одинакового размера
FirstCepochka:Int64; // Абсолютный адрес первой цепочки
LastCepochka: Int64; // Абсолютный адрес последней цепочки
FirstDeleted: Int64; // Сыллка на первую удаленную запись в таблице
LastDeleted: Int64; // Сыллка на последнюю удаленную запись в таблицеend;
За запись, чтение, Открытие таблиц Отвечает класс TSSBD; Он имеет следующие поля класса
TSSBd=Class
Private
FStream:TStream; // Основное хранилище данных
CriticalSection:TCriticalSection; // На всякий случай на будущее
TableInfoOfTables:TTableInfoOFTables; // Информация о таблицах
TableCepochki:TTableCepochki; // Информация о цепчках
ArrayLocalInfo:Array of TLocalInfo; // Массив информации о таблицах
---------------------------------------------------------------------
TLocalInfo= Record
InfoOfTable:TInfoOFTable;
IndexArray:TBDArIndex;
end;
InfoOfTable:TInfoOFTable; // Это запись информации о таблице в памяти с
которой взамодействуют таблицы которая затем записывается в TTableInfoOFTables
IndexArray:TBDArIndex; // Это динамический иерархический масси (наподобии первичного индекса
таблиц Pasradox). В нем хранится последовательность страниц таблицы для быстрого поиска.
При открытии таблицы информация о страницах загружаетя из TCepochki и затем паралельно модифицируются.
Все таблицы одного типа имеют ссылки на эти данные.
Поиск страницы осуществляется следующим образом
//Const
// StranicaSize=1 shl 12;
i:=NewPosition shr 12;
CurrentStranica:=IndexArray[i];
indexInStranica:=NewPosition mod StranicaSize;
что достаточно быстро.
-------------------------------------------------------------------
На данный момент реализованы 4 таблицы для хранения данных
TSSTable
TSSChildTable
TTableStream
TSSTableBlob
TSSTable это обычная струтурированная таблица. Отличием ее является наличие в начале
записи Номер этой записи в таблице. Который является уникальным значением для данной записи.
Это поле на данный момент может являться ссылкой на следующую удаленную запись.
Методы данной таблицы достаточно понятны.
TSSChildTable это подчиненная таблица в начале записи которой обязательно должна быть структура
PChildRecord=^TChildRecord;
TChildRecord = record
RecordNumber:TRecordNumber;
NextRecordNumber:TRecordNumber; // сылка на следующую запись
PriorRecordNumber:TRecordNumber; // ссылка на предыдущую запись end;
Запись родительской таблицы должна содержать поле типа
PChildLines=^TChildLines;
TChildLines = Record
FirstLines:Int64;
LastLines:Int64;
end;
Небольшойпример записи в данные таблицы
j:=FindFirst(FileDir+'*.pas',faArchive,SearchRec);
While j=0 Do begin
MyTable2.ClearRecord; // очистка записи
// Заполнение полей записи данными
MyTable2.TableRecord.Int:=i;
MyTable2.TableRecord.Doub:=i;
MyTable2.FileName:=searchrec.Name;
//-----------------------------
StringList.LoadFromFile(FileDir+searchrec.Name);
For i:=0 to Stringlist.Count-1 Do
Begin
If Length(Stringlist[i])>0 Then
Begin
ChildTable.ClearRecord;
ChildTable.Stroka:=Stringlist[i];
ChildTable.AddRecord(MyTable2.TableRecord.Lines);// Добавление записи ChildTable и
// модификация поля записи MyTable2.TableRecord.Lines
inc(m);
end;
end;
MyTable2.AddRecord; // Добавление записи в MyTable2
J:=findNext(searchrec);
end;
//----------------------------------------------------------------------------------------
TTableStream, TSSTableBlob выполняют одну задачу хранение потока данных.
TTableStream данные всегда добавляются в конец таблицы. Сначала записывается длина потока а затем данные.
Но так как данные хранятся друг за другом запрещена модификация и удаление. Данная таблица хороша тогла
когда не нужна модификация данных.
TSSTableBlob это классическая блоб таблица. Данные хранятся в связанных записях имеющих вид
PSmallBlobRecord=^TSmallBlobRecord;
TSmallBlobRecord= record
NextRecord:Int64; // Ссылка на следующую запись с данными
Data:Array[0..LenRec-sizeOf(Int64)-1] of char;
end;
Где LenRec длина записи и должна быть кратна размеру страницы.
В начале первой записи прописывается длина данных.
Удобно работать со стримами в таком виде
TMyChildTable= class(TSSChildTable)
TableRecord:TMyChildRecord;
protected
procedure SetStroka(const Value: String);
function GetStroka: String;
public
Constructor Create(SSBd:TSSBd); Override;
Property Stroka:String read GetStroka write SetStroka;
end;
function TMyChildTable.GetStroka: String;
begin
if TableRecord.Str>0 Then
Result:=SmallBlobTable.ReadAsString(TableRecord.Str)
Else
result:='';
end;
procedure TMyChildTable.SetStroka(const Value: String);
begin
if TableRecord.Str>0 Then
SmallBlobTable.ModifyFromString(TableRecord.Str,Value)
else
TableRecord.Str:=SmallBlobTable.WriteFromString(Value);
end;
где SmallBlobTable является наследником TSSTableBlob.
Каждая таблица должна именть свой уникальный ID который является номером записи в TTableInfoOFTables
type
TTablesID=(soTableInfoOFTables,soTableCepochki,soTableStream,soSmallBlobTabble,somyTable,somyTable2,soChildTable,soChildTable2,sotableCount);
Первыедва номера зарезервированы за TableInfoOFTables,TableCepochki.
Нужно в конструкторе определить начальные данные
constructor TmyTable.Create(SSBd: TSSBd);
begin
TableId:=integer(soMyTable);
Self.CurrentRecord:=@Self.tableRecord;
Self.SizeRecord:=SizeOf(TMyRec);
inherited Create(SSBd);
end;
Для теста была выбрана слетующая структура бд.
myTable хранит название файлов;
MyChildTable хранит ссылки на строки данного файла в SmallBlobTable или TStreamTable;
То есть задействованы все виды таблиц.
У меня Athlon XP 2400+, память 750 МБ РС 3200, частота шины 133 и Винт Сигейт St3820021А (7500 оборотов),
Файловая система NTFS (FAT у меня быстрее на 10-15%)
были показаны следующие данные
------------- Проверка стрим таблы --------------------------------------------
Время записив в стрим табле=3.891
Количество записей в ChildTable =211232
Количество записей в Файлах =211232
Размер стрим табле=8259756
Время чтения и сравнения в стрим табле=1.375
------------- Проверка блоб таблы --------------------------------------------
Время записив в блоб табле=4.437
Количество записей в ChildTable =211232
Количество записей в Файлах =211232
Размер смал блоб табле=14212000
Количество записей в смал блоб табле=444125
Время чтения и сравнения в смал блоб табле=1.484
=========== Модификация Блоб таблы ===========
Время модификации в блоб табле=3.468
Количество записей в ChildTable =211232
Количество записей в Файлах =211232
Размер смал блоб табле=14242816
Количество записей в смал блоб табле=445088
Время чтения и сравнения в смал блоб табле=1.516
То же но хранеие данных в пмяти
------------- Проверка блоб таблы в TSSStream --------------------------------------------
Время записив в блоб табле=1
Количество записей в ChildTable =211232
Количество записей в Файлах =211232
Размер смал блоб табле=14212000
Количество записей в смал блоб табле=444125
Время сохранения TSSStream в файл=0.109
Время загрузки из файла в TSSStream=0.11
Время чтения и сравнения в смал блоб табле=0.625
=========== Модификация Блоб таблы ===========
Время модификации в блоб табле=1
Количество записей в ChildTable =211232
Количество записей в Файлах =211232
Размер смал блоб табле=14242816
Количество записей в смал блоб табле=445088
Время чтения и сравнения в смал блоб табле=0.641
Скорость записи и чтения в память у меня получилась всего в 4 раза быстрее чем на диск
(Чтение файлов составляет 0.2 сек). У кого диски не очень быстрые и размер БД небольшой
есть смысл хранить данные в памяти а затем скидывать на диск.
Затем был проведен тест хранение всего потока данных файлов в SmallBlobTable и TStreamTable;
------------- Проверка записи файлов стрим таблы --------------------------------------------
Время записи в стрим табле=0.282
Количество Файлов =133
Размер стрим табле=7033394
Время чтения и сравнения в стрим табле=0.203
------------- Проверка записи файлов блоб таблу --------------------------------------------
Время записив в стрим табле=1
Количество Файлов =133
Размер стрим табле=9376352
Время чтения и сравнения в стрим табле=0.687
------------- Модификации записи файлов блоб таблу --------------------------------------------
Время модификации в блоб табле=1.328
Количество Файлов =266
Размер блоб табле=9376352
Количество записей в блоб табле=293011
------------- Проверка Модификации файлов блоб таблу --------------------------------------------
Время чтения и сранения в блоб табле=0.656
Размер блоб табле=9376352
Количество записей в блоб табле=293011
Сдесь следует отметить, что размер блоб табле составляетвего 32 байта и при увеличении
размера до размера страницы скорость будет такой же как и стрим таблы.
Имеет смысл хранить полчиненные данные ввиде потоков данных. Например строчную часть
документа записывать в стрим и передавать его для записи в главную таблицу.
Также проведен тест на скорость храненияи чтения обыкновенной таблицы
=========== Запись в MyTable ===========
Время Записи=7.547
Количество записей в MyTable =1000001
=========== Чтение в MyTable ===========
Время Чтения=1.407
Количество записей в MyTable =1000001
Хотя скорости и не оправдали моих надежд (слишком много накладных расходов) но
по сравнению с 1С это самолет.
Хотя пока индексы еще не прикручены и достаточна сырая и полностью не протестированная система но
вполне работоспособна. Буду рад любым замечаниям, предложением.
... << RSDN@Home 1.1.4 beta 4 rev. 303>>
и солнце б утром не вставало, когда бы не было меня
Re[17]: Объектно-ориентированные БД: основные принципы, орга
Здравствуйте, eao197, Вы писали:
E>Если БД не гарантирует надежной фиксации транзакции, то как же ее БД-то называть?
Если подойти буквоедчески, то БД — это просто совокупность объектов. В данном случае, вы наверно хотели сказать СУБД. Но пока мы и не говорили о полноценности решения Serginio1 как современной СУБД и исполнению каких либо стандартов.
С уважением, Gleb.
Re[17]: Объектно-ориентированные БД: основные принципы, орга
Здравствуйте, eao197, Вы писали:
E>Здравствуйте, Serginio1, Вы писали:
GZ>>>Отложенная запись без транзакционного механизма увеличит вероятность ошибки файла за счет недописанной полностью записи. S>> Согласен, но чем только не пожертвуешь ради скорости. Подождем быструю энэргонезависимую память для введения быстрого транзакционного механизма.
E>Если БД не гарантирует надежной фиксации транзакции, то как же ее БД-то называть?
Ну за 2 недели это называется просто поделкой. У нее была простая задача переноса сложных иерархических данных с быстрым чтением и записью.
... << RSDN@Home 1.1.4 beta 4 rev. 303>>
и солнце б утром не вставало, когда бы не было меня
Re[17]: Объектно-ориентированные БД: основные принципы, орга
Здравствуйте, eao197, Вы писали:
E>А результат в 7 секунд был получен на пустой БД или уже на фрагментированной?
На пустой. Да смысл даже не в этом. Фрагментация роли не играет. Это просто маленький задача эффективного обмена данных сложной иерархии.
Т.К. XML, Аксессы и прочие локальные Бд были отметены из за медлительности и малопригодности.
... << RSDN@Home 1.1.4 beta 4 rev. 303>>
и солнце б утром не вставало, когда бы не было меня
Re[18]: Объектно-ориентированные БД: основные принципы, орга
Здравствуйте, GlebZ, Вы писали:
GZ>Здравствуйте, eao197, Вы писали:
E>>Если БД не гарантирует надежной фиксации транзакции, то как же ее БД-то называть? GZ>Если подойти буквоедчески, то БД — это просто совокупность объектов. В данном случае, вы наверно хотели сказать СУБД. Но пока мы и не говорили о полноценности решения Serginio1 как современной СУБД и исполнению каких либо стандартов.
Да, действительно, хотел сказать СУБД.
Я просто к тому, что в СУБД надежность хранения очень важный фактор. Не правильно, имхо, откладывать разбирательство с ним на потом. А то может оказаться, что реализованая СУБД показывает супер производительность без защиты от сбоев, а когда такая защита появляется, то:
— либо производительность падает, из-за write-ahead log-а;
— либо дисковое пространство уходит, если измененные страницы записываются в новые файлы данных БД.
А стандарты в области ООСУБД, имхо, вещь труднодостижимая. Не зря же ODMG тихо скончался. Слишком много интертрепаций ООП и подходов к хранению ОО данных. Может быть несколько различных стандартов со временем получатся.
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[18]: Объектно-ориентированные БД: основные принципы, орга
Здравствуйте, Serginio1, Вы писали:
S>Здравствуйте, eao197, Вы писали:
E>>А результат в 7 секунд был получен на пустой БД или уже на фрагментированной? S> На пустой. Да смысл даже не в этом. Фрагментация роли не играет. Это просто маленький задача эффективного обмена данных сложной иерархии. S> Т.К. XML, Аксессы и прочие локальные Бд были отметены из за медлительности и малопригодности.
О, ситуация проясняется.
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[19]: Объектно-ориентированные БД: основные принципы, орга
Здравствуйте, eao197, Вы писали:
E>Да, действительно, хотел сказать СУБД.
E>Я просто к тому, что в СУБД надежность хранения очень важный фактор. Не правильно, имхо, откладывать разбирательство с ним на потом. А то может оказаться, что реализованая СУБД показывает супер производительность без защиты от сбоев, а когда такая защита появляется, то: E>- либо производительность падает, из-за write-ahead log-а; E>- либо дисковое пространство уходит, если измененные страницы записываются в новые файлы данных БД.
Не буду флеймить на термин СУБД, это уже будет демагогия. Что касается транзакционного механизма, то вынужден согласится. Он оказывает огромнейшее влияние на архитектуру (и не только для решений БД, но и серверов приложений). Однако TDD и Refactoring здесь тоже рулит. И если автор пойдет по этому пути, с выбросом некоторого кода, то только в путь.
E>А стандарты в области ООСУБД, имхо, вещь труднодостижимая. Не зря же ODMG тихо скончался. Слишком много интертрепаций ООП и подходов к хранению ОО данных. Может быть несколько различных стандартов со временем получатся.
К сожалению, да. Что касается ODMG, то он скорее всего не скончался, а просто выродился обратно в OMG. Не понимаю причин, но к сожалению это факт.
С уважением, Gleb.
Re[12]: Объектно-ориентированные БД: основные принципы, орга
<...> S> Хотя скорости и не оправдали моих надежд (слишком много накладных расходов) но S>по сравнению с 1С это самолет.
S> Хотя пока индексы еще не прикручены и достаточна сырая и полностью не протестированная система но S> вполне работоспособна. Буду рад любым замечаниям, предложением.
Я сходу не очень понял (может у меня к вечеру глаз замылился), а ссылочную целостность нужно самому поддерживать? Например, номер родительской записи в дочерние нужно вручную вставлять?
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[12]: Объектно-ориентированные БД: основные принципы, орга
That's good. Только скажи, по каким критериям ты оцениваешь свое решение. Только на высоком уровне. То есть например:
1. Система должна предоставлять быстрый доступ к единичному объекту.
2. Система должна иметь возможность записывать объекты с различной длиной записи.
...
Просто иначе трудно оценить.
С уважением, Gleb.
Re[13]: Объектно-ориентированные БД: основные принципы, орга
Здравствуйте, eao197, Вы писали:
E>Я сходу не очень понял (может у меня к вечеру глаз замылился), а ссылочную целостность нужно самому поддерживать? Например, номер родительской записи в дочерние нужно вручную вставлять?
Здесь принцып такой как и в обычном пргограммировании, подчиненной записи не нужно знать своих родителей. Родитель сам до нее доберется.
Если обязательно нужно знать родителя, то в пользовательской структуре это можно и указать.
Цель была отойти от индексов там где они не нужны. В родительской записи есть первая и последняя запись этого достаточно.
... << RSDN@Home 1.1.4 beta 4 rev. 303>>
и солнце б утром не вставало, когда бы не было меня
Re[20]: Объектно-ориентированные БД: основные принципы, орга
Здравствуйте, GlebZ, Вы писали:
E>>А стандарты в области ООСУБД, имхо, вещь труднодостижимая. Не зря же ODMG тихо скончался. Слишком много интертрепаций ООП и подходов к хранению ОО данных. Может быть несколько различных стандартов со временем получатся. GZ>К сожалению, да. Что касается ODMG, то он скорее всего не скончался, а просто выродился обратно в OMG. Не понимаю причин, но к сожалению это факт.
ИМХО, причины в том, что ООСУБД на момент принятия ODMG были слишком разными. В POET, например, мне заполнилась работа с ссылками. У них, кажется были четыре режима работы с сылками объекта при выполнении таких операций как загрузка, блокировка и удаление (только сам объект, сам объект и все его ссылки и пара промежуточных вариантов, не помню уже каких). В ODMG этих возможностей не было. Поэтому пользователям POET нужно было решать, либо использовать уникальные возможности POET, но терять портабельность, либо обеспечивать портабильность своих приложений, но отказываться от преимуществ POET. Понятно, что POET Software эта ситуация так же не очень нравилась. Поэтому они и не спешили делать свою СУБД 100% совместимой с ODMG. И у других производителей ООСУБД были, вероятно, схожие мотивы.
А произошло это, имхо, потому, что нет стандарта на ООП (дико звучит, но может быть потом будет понятнее). Вот за SQL стоит математика. Поэтому SQL можно считать всего лишь формой записи объективной реальности -- реляционной алгебры /ох, сейчас опять в неграмотности уличат/. А под ООП можно подсунуть очень широкий диапазон понятий. Ведь нет единого ООП языка. В C++ есть что-то свое (множественное наследование классов), в Java этого нет (есть интерфейсы, но они данных не могут содержать, поэтому для БД могут быть не интересны). В Smalltalk свои заморочки, в других ООП языках свои. И на это все, в самом начале ООП бума, попытались стандарт повесить.
Лично мне не нравилось, что ООСУБД строятся на принципах неявной стабильности. Когда СУБД сама определяет, как и когда объект сохраняется, когда удаляется и т.д. Вот я, когда учился в асспирантуре, пытался построить ООСУБД, которая бы работала на принципах явной стабильности. Была ли она ООСУБД -- почти да (за исключением запросов, но зато с поддержкой миграции данных). По под стандарт ODMG ну ни как бы не вписалась.
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[13]: Объектно-ориентированные БД: основные принципы, орга
Обмен данными между конфигурациями различного типа. Данных было очень много, причем поля имели неопределенный тип итд.
И соответственно, быстрый доступ, запись к любого типа объектам.Посмотреть на скорость и тд. Да и некая разминка для пальцев
Просто под конкретную задачу можно сделать свою оптимальную простенькую БД.
... << RSDN@Home 1.1.4 beta 4 rev. 303>>
и солнце б утром не вставало, когда бы не было меня
Re[14]: Объектно-ориентированные БД: основные принципы, орга
<...> S> Просто под конкретную задачу можно сделать свою оптимальную простенькую БД.
Ох плохо это заканчивается при сопровождении. Особенно когда появляется необходимость поддержки миграции данных (при изменении схемы данных БД). Личный печальный опыт
Именно поэтому производители БД и процветают, что кустари в конце-концов свои разработки забрасывают от безысходности. Или становятся производителями БД
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[14]: Объектно-ориентированные БД: основные принципы, орга
S> Обмен данными между конфигурациями различного типа. Данных было очень много, причем поля имели неопределенный тип итд. S> И соответственно, быстрый доступ, запись к любого типа объектам.Посмотреть на скорость и тд. Да и некая разминка для пальцев S> Просто под конкретную задачу можно сделать свою оптимальную простенькую БД.
Дело в том, что для DTO нормально, но для СУБД — слишком мало и не очень эффективно.
С уважением, Gleb.
Re[15]: Объектно-ориентированные БД: основные принципы, орга
S>> Обмен данными между конфигурациями различного типа. Данных было очень много, причем поля имели неопределенный тип итд. S>> И соответственно, быстрый доступ, запись к любого типа объектам.Посмотреть на скорость и тд. Да и некая разминка для пальцев S>> Просто под конкретную задачу можно сделать свою оптимальную простенькую БД. GZ>Дело в том, что для DTO нормально, но для СУБД — слишком мало и не очень эффективно.
Так я не в коей мере и не претендую этой поделкой претендовать на что либо. Но это отход от РБД, небольшое изыскание, не более того.
А развить если бы и захотел сил нет. Нужен конфигуратор, метаданные,индексы, другой эффективной лабуды механизм транзакций итд.
Но уж сильно меня достал Этот SQL Свет клином на нем сошелся.
А насчет эффективности для конкретной задачи это ты зря.
... << RSDN@Home 1.1.4 beta 4 rev. 303>>
и солнце б утром не вставало, когда бы не было меня
Re[15]: Объектно-ориентированные БД: основные принципы, орга
Здравствуйте, eao197, Вы писали:
E>Здравствуйте, Serginio1, Вы писали:
E><...> S>> Просто под конкретную задачу можно сделать свою оптимальную простенькую БД.
E>Ох плохо это заканчивается при сопровождении. Особенно когда появляется необходимость поддержки миграции данных (при изменении схемы данных БД). Личный печальный опыт E>Именно поэтому производители БД и процветают, что кустари в конце-концов свои разработки забрасывают от безысходности. Или становятся производителями БД
Но пример 1С прежде всего убеждает, что главное ООП (псевдо ООП в данном случае) надстройка над любой БД это залог успеха.
Кстати конфигурации весят по 20 МБ, и более половины это програмный текст. Это я камень в огород о 100 000 строк.
У меня только объектное описание одной конфигурации генерится за мегабайт Дельфевого кода. Будущее отнюдь не за СУБД.
... << RSDN@Home 1.1.4 beta 4 rev. 303>>
и солнце б утром не вставало, когда бы не было меня
Re[16]: Объектно-ориентированные БД: основные принципы, орга
Здравствуйте, Serginio1, Вы писали:
S>А насчет эффективности для конкретной задачи это ты зря.
Извини, если я чем-то обидел, но eao197 прав. Может транзакционный механизм как таковой и не нужен. Но в случае сбоя диска — возможна деструкция файла. А это для БД — смертеподобно. И алгоритм сохранения становится более интересным. Я не прав?
С уважением, Gleb.
Re[16]: Объектно-ориентированные БД: основные принципы, орга
Здравствуйте, eao197, Вы писали:
E>А произошло это, имхо, потому, что нет стандарта на ООП (дико звучит, но может быть потом будет понятнее). Вот за SQL стоит математика. Поэтому SQL можно считать всего лишь формой записи объективной реальности -- реляционной алгебры /ох, сейчас опять в неграмотности уличат/. А под ООП можно подсунуть очень широкий диапазон понятий. Ведь нет единого ООП языка. В C++ есть что-то свое (множественное наследование классов), в Java этого нет (есть интерфейсы, но они данных не могут содержать, поэтому для БД могут быть не интересны). В Smalltalk свои заморочки, в других ООП языках свои. И на это все, в самом начале ООП бума, попытались стандарт повесить.
+1
E>Лично мне не нравилось, что ООСУБД строятся на принципах неявной стабильности. Когда СУБД сама определяет, как и когда объект сохраняется, когда удаляется и т.д.
Я бы так не сказал. Во многих реализациях — клиент заказывает музыку. В некоторых нет, но там это умеют использовать(как в GemStone). E>Вот я, когда учился в асспирантуре, пытался построить ООСУБД, которая бы работала на принципах явной стабильности. Была ли она ООСУБД -- почти да (за исключением запросов, но зато с поддержкой миграции данных).
Вот-вот. Слишком много продуктов в которых отсутвие запросов объявлялось как не особо нужным. Во главу угла ставился только навигационный доступ. E>По под стандарт ODMG ну ни как бы не вписалась.
Верю. Вот если бы я решил написать OODB в очередной раз(мечтательно), я бы этот стандарт послал бы на ... Реализация OODB слишком привязана к языку на котором она должна работать.
С уважением, Gleb.
Re[22]: Объектно-ориентированные БД: основные принципы, орга
Здравствуйте, GlebZ, Вы писали:
E>>Лично мне не нравилось, что ООСУБД строятся на принципах неявной стабильности. Когда СУБД сама определяет, как и когда объект сохраняется, когда удаляется и т.д. GZ>Я бы так не сказал. Во многих реализациях — клиент заказывает музыку. В некоторых нет, но там это умеют использовать(как в GemStone).
К сожелению, не могут тут ничего добавить. Когда этим плотно занимался не было доступа в Интернет, чтобы получать необходимую информацию. Теперь доступ есть, но нет времени. А то, что знал -- позабыл.
E>>Вот я, когда учился в асспирантуре, пытался построить ООСУБД, которая бы работала на принципах явной стабильности. Была ли она ООСУБД -- почти да (за исключением запросов, но зато с поддержкой миграции данных). GZ>Вот-вот. Слишком много продуктов в которых отсутвие запросов объявлялось как не особо нужным. Во главу угла ставился только навигационный доступ.
Согласен.
Хотя BerkeleyDB показывает, что может быть эффективный поиск, но нет запросов.
E>>По под стандарт ODMG ну ни как бы не вписалась. GZ>Верю. Вот если бы я решил написать OODB в очередной раз(мечтательно), я бы этот стандарт послал бы на ... Реализация OODB слишком привязана к языку на котором она должна работать.
Я так и сделал в очередной раз
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[17]: Объектно-ориентированные БД: основные принципы, орга
Здравствуйте, GlebZ, Вы писали:
GZ>Здравствуйте, Serginio1, Вы писали:
S>>А насчет эффективности для конкретной задачи это ты зря. GZ>Извини, если я чем-то обидел, но eao197 прав. Может транзакционный механизм как таковой и не нужен. Но в случае сбоя диска — возможна деструкция файла. А это для БД — смертеподобно. И алгоритм сохранения становится более интересным. Я не прав?
Глеб я все прекрасно понимаю. Но в 1С я этак лет 8 при чем с дбф. Количество пользователей до 30 (кстати самый многочисленный сегмент). Когда не было терминальных сессий была полная ж.. Файлы летели. Для увеличения скорости на критических по скорости отчетах стоял свой сервер приложений под DCOM на машине с файлами с прямым доступом к файлам в виде настоящих объектов.
При применении терминальных сессий сбоев тфу тфу не было, а востановление сбитых файлов это уже набитя руку оскомина ее не боюсь.
А в ДБФ понятия транзакционности нет как такового.
Ее можно сделать, но мне одному ради интереса ....
Пока больше осматриваюсь. Авось ....
... << RSDN@Home 1.1.4 beta 4 rev. 303>>
и солнце б утром не вставало, когда бы не было меня
Re[17]: Объектно-ориентированные БД: основные принципы, орга
Здравствуйте, eao197, Вы писали:
E>Здравствуйте, Serginio1, Вы писали:
E><...> S>>...Будущее отнюдь не за СУБД.
E>Хотелось бы верить, что за ООСУБД, особенно российского производства E>Но, имхо, у SQL еще есть шанс и нас пережить
В таком виде как сейчас навряд ли. Почитал ссылочки Глеба, все они движутся в одном направлении. ХП на манагед языках, объектная надстройка итд. По большому счету глубоко наплевать что за хранилище данных будет использовать сервер приложений. Основная задача это ООП ,быстрая разработка приложений и ее выполнение. Пока это все не ближайшее будущее. А задачи ооочень раветвленные.
... << RSDN@Home 1.1.4 beta 4 rev. 303>>
и солнце б утром не вставало, когда бы не было меня
Re[17]: Объектно-ориентированные БД: основные принципы, орга
Немного опишу примерный механизм сохранения со страничной адресацией который реализовал когда-то я. Может быть тебе интересно будет. Сразу говорю, что многие детали опущу, терминологию тоже(экстент у меня будет всегда называться страницой).
На каждый тип имеется заголовок, метаданные и список страниц в общем файле. В заголовке соответсвенно лежит информация о первой странице. В странице зарезервировано некоторое служебное пространство для адресации внутренних записей и полей. Записи могут иметь различную длину. Я, например, адресовался с помощью метаданных, приплюсовывая размер оттуда — если число, размер строки брал со страницы. При загруженной странице, пройти список — быстро. Адресация напрямую к записи осуществляется только с помощью специального указателя на индекс из спец. манагера который отвечал за загрузку и выгрузку страниц на диск. . В заголовке, в виде флагов — хранилось степень заполнения страницы — флаг пусто и менее 75%. Реальный размер лежал в служебной информации на самой странице. При добавлении записи, находилась страница в которую можно поместить объект, если таковой не находилось — то создавалась новая страница. В первую очередь, подбирались страницы с флагом менее 75%. При удалении записи — рассчитывалось так, чтобы на странице не оставалось менее 50% свободного пространства. Если меньше, то она распределялась по остальным страницам (сначало проверялись ближние). После сохранения — в заголовке — флаг пустоты страницы. Механизма для удаления страницы из списка — не было. Жалко было тратить время на сохранение соседней страницы — если она была не нужна(была мысль сделать ее в асинхронном процессе).
Эта система очень похожа на систему сохранения MS SQL. Если посмотреть на систему хранения Oracle — то вообще ужаснешся. Там у изменяемый размер экстента.
С уважением, Gleb.
Re[18]: Объектно-ориентированные БД: основные принципы, орга
Здравствуйте, Serginio1, Вы писали:
S>Здравствуйте, GlebZ, Вы писали:
GZ>>Здравствуйте, Serginio1, Вы писали:
S>>>А насчет эффективности для конкретной задачи это ты зря. GZ>>Извини, если я чем-то обидел, но eao197 прав. Может транзакционный механизм как таковой и не нужен. Но в случае сбоя диска — возможна деструкция файла. А это для БД — смертеподобно. И алгоритм сохранения становится более интересным. Я не прав? S>Глеб я все прекрасно понимаю. Но в 1С я этак лет 8 при чем с дбф. Количество пользователей до 30 (кстати самый многочисленный сегмент). Когда не было терминальных сессий была полная ж.. Файлы летели. Для увеличения скорости на критических по скорости отчетах стоял свой сервер приложений под DCOM на машине с файлами с прямым доступом к файлам в виде настоящих объектов. S> При применении терминальных сессий сбоев тфу тфу не было, а востановление сбитых файлов это уже набитя руку оскомина ее не боюсь. S> А в ДБФ понятия транзакционности нет как такового.
Сочуствую, я как-то обошел программы на dbf (когда-то чего-то непонятное делал на DBASE, в остальном лох). Когда уже начал нормально заниматься базами, сразу попал на транзакционные базы. Каждый человек субъективен, так как судит с высоты своего опыта.
С уважением, Gleb.
PS:Полностью защищенную базу от сбоев построить невозможно. Иначе бы можно было забыть про backup. Но максимально стремится, я думаю следует.
Re[18]: Объектно-ориентированные БД: основные принципы, орга
По сути механизм у меня схож с твоим, окромя того, что для каждой записи свой набор страниц. Но при твоем подходе нужны обязательно индексы , хэш таблицы (или я не прав). У меня запись всегда стоит на своем месте ( Даже если прикрутить версионность). Я хотел реализовать не типичную для БД архитектуру.
Просто захотелось выпендриться для Себя и побить кулаком в грудь.
А так как у каждого типа свой набор страниц, то удаленные записи ввиде однонаправленного списка очень бысро указывали новое место.
И прежде всего резко ограничить присутствие индексов. Кстати тоже не сделал возврата пустых страниц, все равно рано или поздно они бы использовались.
Глеб а ты кстати вроде на RSDN Group ходишь. Давай пивка попьем пообщаемся ????
... << RSDN@Home 1.1.4 beta 4 rev. 303>>
и солнце б утром не вставало, когда бы не было меня
Re[19]: Объектно-ориентированные БД: основные принципы, орга
Здравствуйте, Serginio1, Вы писали:
S>Здравствуйте, GlebZ, Вы писали:
S> По сути механизм у меня схож с твоим, окромя того, что для каждой записи свой набор страниц. Но при твоем подходе нужны обязательно индексы , хэш таблицы (или я не прав). У меня запись всегда стоит на своем месте ( Даже если прикрутить версионность). Я хотел реализовать не типичную для БД архитектуру. S> Просто захотелось выпендриться для Себя и побить кулаком в грудь. S> А так как у каждого типа свой набор страниц, то удаленные записи ввиде однонаправленного списка очень бысро указывали новое место. S>И прежде всего резко ограничить присутствие индексов. Кстати тоже не сделал возврата пустых страниц, все равно рано или поздно они бы использовались.
Я также ставил условие 64-разрядного доступа. Тут уж никак не обойдешься без косвенной адресации.
S>Глеб а ты кстати вроде на RSDN Group ходишь. Давай пивка попьем пообщаемся ????
Сейчас напишу тебе на мыло (а то offtop)
С уважением, Gleb.
Re[20]: Объектно-ориентированные БД: основные принципы, орга
GZ>Я также ставил условие 64-разрядного доступа. Тут уж никак не обойдешься без косвенной адресации.
У меня номер записи прописывался как Int64 S>>Глеб а ты кстати вроде на RSDN Group ходишь. Давай пивка попьем пообщаемся ???? GZ>Сейчас напишу тебе на мыло (а то offtop)
GZ>С уважением, Gleb.
... << RSDN@Home 1.1.4 beta 4 rev. 303>>
и солнце б утром не вставало, когда бы не было меня
Re[21]: Объектно-ориентированные БД: основные принципы, орга
Здравствуйте, Serginio1, Вы писали:
S>Здравствуйте, GlebZ, Вы писали:
GZ>>Я также ставил условие 64-разрядного доступа. Тут уж никак не обойдешься без косвенной адресации. S> У меня номер записи прописывался как Int64
Сорри, ляпнул не подумавши.
Я просто прошел немного больше, и у меня oid разыменовывался в оперативную память с объектом на странице. Соответсвенно по одному и тому же oid — адресавался объект в странице на диске, и объект на уже загруженной странице в памяти.
С уважением, Gleb.
Re[22]: Объектно-ориентированные БД: основные принципы, орга
Здравствуйте, GlebZ, Вы писали:
GZ>Здравствуйте, Serginio1, Вы писали:
S>>Здравствуйте, GlebZ, Вы писали:
GZ>>>Я также ставил условие 64-разрядного доступа. Тут уж никак не обойдешься без косвенной адресации. S>> У меня номер записи прописывался как Int64 GZ>Сорри, ляпнул не подумавши. GZ>Я просто прошел немного больше, и у меня oid разыменовывался в оперативную память с объектом на странице. Соответсвенно по одному и тому же oid — адресавался объект в странице на диске, и объект на уже загруженной странице в памяти.
Понял. Резонно. Когда хотел кэшировать страницы, хотел держать их ввиде хэш таблицы . Так как запись фиксирована, то нужно былобы найти страницу если она кэширована либо ее загрузить. А смещение в странице заранее известно, без лишней коственности.
Но нужно следить за их количеством, строить статистику итд. По сути система сама за этим следит и решил не заморачиваться.
... << RSDN@Home 1.1.4 beta 4 rev. 303>>
и солнце б утром не вставало, когда бы не было меня
Re[21]: Объектно-ориентированные БД: основные принципы, орга
Здравствуйте, eao197, Вы писали:
E>ИМХО, причины в том, что ООСУБД на момент принятия ODMG были слишком разными. В POET, например, мне заполнилась работа с ссылками. У них, кажется были четыре режима работы с сылками объекта при выполнении таких операций как загрузка, блокировка и удаление (только сам объект, сам объект и все его ссылки и пара промежуточных вариантов, не помню уже каких). В ODMG этих возможностей не было. Поэтому пользователям POET нужно было решать, либо использовать уникальные возможности POET, но терять портабельность, либо обеспечивать портабильность своих приложений, но отказываться от преимуществ POET. Понятно, что POET Software эта ситуация так же не очень нравилась. Поэтому они и не спешили делать свою СУБД 100% совместимой с ODMG. И у других производителей ООСУБД были, вероятно, схожие мотивы.
Да не в этом проблема. Просто парни, которые проектировали ODMG, слишком многого хотели. Они захотели получить продукт простым сложением SQL+OOP. Увы — очень быстро оказалось, что математика не успевает за этими хотениями. В итоге получился стандарт, буквальное следование которому приведет к:
1. Необходимости поддерживать конструкции, неиспользуемые в 99.9% случаев
2. Предоставлению программисту возможности легким движением руки породить запрос, не поддающийся оптимизации
Поэтому большинство реализаций банально игнорируют те части стандарта, которые не очень нужны, а также те, которые трудно сделать. В итоге страдает как ассоциативный доступ (реляционные черты), так и полиморфизм (объектно-ориентированные черты).
Если бы разработчики ODMG меньше думали о том, как сделать язык обратно совместимым с SQL, а больше о реализации, то мы, вполне возможно, сейчас бы считали RDBMS чем-то таким, что существовало в далеком прошлом.
... << RSDN@Home 1.1.4 beta 4 rev. 347>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[22]: Объектно-ориентированные БД: основные принципы, орга
<...> S>Да не в этом проблема. Просто парни, которые проектировали ODMG, слишком многого хотели. Они захотели получить продукт простым сложением SQL+OOP. Увы — очень быстро оказалось, что математика не успевает за этими хотениями. В итоге получился стандарт, буквальное следование которому приведет к: S>1. Необходимости поддерживать конструкции, неиспользуемые в 99.9% случаев S>2. Предоставлению программисту возможности легким движением руки породить запрос, не поддающийся оптимизации S>Поэтому большинство реализаций банально игнорируют те части стандарта, которые не очень нужны, а также те, которые трудно сделать. В итоге страдает как ассоциативный доступ (реляционные черты), так и полиморфизм (объектно-ориентированные черты). S>Если бы разработчики ODMG меньше думали о том, как сделать язык обратно совместимым с SQL, а больше о реализации, то мы, вполне возможно, сейчас бы считали RDBMS чем-то таким, что существовало в далеком прошлом.
Думаю, что проблем было не одна и не две, и даже не три. Поэтому, имхо, и я прав, и ты прав.
Только мне кажется, что ODMG не был с нуля спроектирован. А за основу была взята какая-то (сейчас уже не вспомню какая), особо продвинутая на тот момент, ООСУБД. Затем в ODMG напихали еще по мелочам. И получили мертворожденный продукт.
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[17]: Объектно-ориентированные БД: основные принципы, орга
Здравствуйте, GlebZ, Вы писали:
GZ>Здравствуйте, Serginio1, Вы писали:
S>>А насчет эффективности для конкретной задачи это ты зря. GZ>Извини, если я чем-то обидел, но eao197 прав. Может транзакционный механизм как таковой и не нужен. Но в случае сбоя диска — возможна деструкция файла. А это для БД — смертеподобно. И алгоритм сохранения становится более интересным. Я не прав?
На самом деле для таких простеньких ООДБМС есть несложный вариант транзакционности. WriteAhead лог реализуется при помощи перехвата всех методов объектов и протоколировании этих вызовов. Регулярно делается чекпоинт — т.е. состояние базы скидывается на диск. Лог-записи старше этого момента считаются ненужными и подлежат перезаписи. При старте базы выполняется чтение сигнатуры чекпоинта, которому она соответствует, лог сканируется в поисках этого чекпоинта, и выполняется воспроизведение всех транзакций, для которых стоит метка "commited". Для небольших объемов (в пределах ~100 Mb) на современном железе это вполне нормально работает.
... << RSDN@Home 1.1.4 beta 4 rev. 347>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[18]: Объектно-ориентированные БД: основные принципы, орга
Здравствуйте, GlebZ, Вы писали: GZ>Эта система очень похожа на систему сохранения MS SQL. Если посмотреть на систему хранения Oracle — то вообще ужаснешся. Там у изменяемый размер экстента.
Круто! А на чем это было реализовано? Я вот сейчас потихоньку ковыряюсь с оптимизацией полиморфных ассоциативных запросов в управляемых средах. Экспериментирую на .Net 2.0 beta.
Когда я получу query optimizer, потребуется хранилище и менеджер транзакций, к которому можно будет его прикрутить.
... << RSDN@Home 1.1.4 beta 4 rev. 347>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[7]: Объектно-ориентированные БД: основные принципы, орган
Здравствуйте, GlebZ, Вы писали: GZ>Можешь точно так же посочуствовать и пользователям РСУБД. Удаление миллионов строк точно такая же, тяжелая операция (к тому же логгируемая).
Не, там все по-другому. Ведь есть гарантия, что запись не пересекает границу страницы! А заполненность страниц проверяется при помощи битмэпов. Дефрагментация нужна далеко не всегда — у нас есть гарантия повторного использования очистившихся страниц! Алгоритм "сборки мусора" на порядок проще — т.к. он во-первых запускается явно, т.е. не нужно его слишком уж оптимизировать, а во-вторых обязанность следить за ссылочной целостностью лежит не на нем.
... << RSDN@Home 1.1.4 beta 4 rev. 347>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[23]: Объектно-ориентированные БД: основные принципы, орга
Здравствуйте, eao197, Вы писали:
E>Думаю, что проблем было не одна и не две, и даже не три. Поэтому, имхо, и я прав, и ты прав. E>Только мне кажется, что ODMG не был с нуля спроектирован. А за основу была взята какая-то (сейчас уже не вспомню какая), особо продвинутая на тот момент, ООСУБД. Затем в ODMG напихали еще по мелочам. И получили мертворожденный продукт.
На тот момент особо продвинутая ODBMS была ровно одна: GemStone. И ODMG, по странному стечению обстоятельств, никакого отношения к ней не имеет (кроме изначальной стандартизации биндинга к SmallTalk и С++. Кстати, добавление в этот список Java было, насколько я помню, основным нововведением в ODMG 2).
Если посмотреть историю научных публикаций на тему ODBMS, то в течение 80х виден растущий интерес к OODB вообще, исследования разных подходов... Начиная с 1993, многие авторы перестают издавать статьи (судя по всему, их детища пали под гнетом стандарта). Остальные бьются над одним вопросом — как обойти ограничения OQL для получения приемлемой производительности. В конце 90х большинство DB-публикаций относится к Fuzzy, Full-text, XML и прочей Web-мишуре.
... << RSDN@Home 1.1.4 beta 4 rev. 347>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[18]: Объектно-ориентированные БД: основные принципы, орга
Sinclair пишет: > На самом деле для таких простеньких ООДБМС есть несложный вариант > транзакционности. WriteAhead лог реализуется при помощи перехвата всех > методов объектов и протоколировании этих вызовов. Регулярно делается > чекпоинт — т.е. состояние базы скидывается на диск. Лог-записи старше > этого момента считаются ненужными и подлежат перезаписи. При старте базы > выполняется чтение сигнатуры чекпоинта, которому она соответствует, лог > сканируется в поисках этого чекпоинта, и выполняется воспроизведение > всех транзакций, для которых стоит метка "commited". Для небольших > объемов (в пределах ~100 Mb) на современном железе это вполне нормально > работает.
afaik, prevayler именно так и работает
--
Andrei N.Sobchuck
JabberID: andreis@jabber.ru. ICQ UIN: 46466235.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, GlebZ, Вы писали: GZ>>Эта система очень похожа на систему сохранения MS SQL. Если посмотреть на систему хранения Oracle — то вообще ужаснешся. Там у изменяемый размер экстента. S>Круто! А на чем это было реализовано? Я вот сейчас потихоньку ковыряюсь с оптимизацией полиморфных ассоциативных запросов в управляемых средах. Экспериментирую на .Net 2.0 beta. S>Когда я получу query optimizer, потребуется хранилище и менеджер транзакций, к которому можно будет его прикрутить.
Там к каждому объекту можно прикрутить параметр PCTINCREASE. В нем лежат проценты увеличения. То есть, при аллокации следующего экстента Oracle увеличивает его размер на эту величину. В результате, уменьшается кол-во аллокаций в зависимости от объема данных.
С уважением, Gleb.
Re[18]: Объектно-ориентированные БД: основные принципы, орга
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, GlebZ, Вы писали:
GZ>>Здравствуйте, Serginio1, Вы писали:
S>>>А насчет эффективности для конкретной задачи это ты зря. GZ>>Извини, если я чем-то обидел, но eao197 прав. Может транзакционный механизм как таковой и не нужен. Но в случае сбоя диска — возможна деструкция файла. А это для БД — смертеподобно. И алгоритм сохранения становится более интересным. Я не прав? S>На самом деле для таких простеньких ООДБМС есть несложный вариант транзакционности. WriteAhead лог реализуется при помощи перехвата всех методов объектов и протоколировании этих вызовов. Регулярно делается чекпоинт — т.е. состояние базы скидывается на диск. Лог-записи старше этого момента считаются ненужными и подлежат перезаписи. При старте базы выполняется чтение сигнатуры чекпоинта, которому она соответствует, лог сканируется в поисках этого чекпоинта, и выполняется воспроизведение всех транзакций, для которых стоит метка "commited". Для небольших объемов (в пределах ~100 Mb) на современном железе это вполне нормально работает.
С одной стороны его делать надо. С другой стороны — я имел ввиду порядок сохранения в хранилище(реальные указатели сохраняются последние, старые данные по возможности можно сохранить). При сбое на логгировании — в данном случае получаем деструкцию файла и неизвестное состояние. По механизму, нормальный лог не намного отличается от данного(просто сохранять в кольцевой список).
Если мы не можем запускать компенсирующие действия — у нас еще есть варианты?
С уважением, Gleb.
Re[18]: Объектно-ориентированные БД: основные принципы, орга
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, GlebZ, Вы писали: GZ>>Можешь точно так же посочуствовать и пользователям РСУБД. Удаление миллионов строк точно такая же, тяжелая операция (к тому же логгируемая). S>Не, там все по-другому. Ведь есть гарантия, что запись не пересекает границу страницы! А заполненность страниц проверяется при помощи битмэпов. Дефрагментация нужна далеко не всегда — у нас есть гарантия повторного использования очистившихся страниц!
Некоторая поправка — в большинстве своем гарантируется что поле(не блоб) умещается на страницу (MS SQL).
Во вторых — вопрос: они могут удалить объект не затрагивая страницу если он на ней не единственный? Это свойство связано со сборкой мусора? То есть идет очищение при сборке мусора?
S>Алгоритм "сборки мусора" на порядок проще — т.к. он во-первых запускается явно, т.е. не нужно его слишком уж оптимизировать,
Что значит явно? В конце транзакции?
C уважением, Gleb.
Re[20]: Объектно-ориентированные БД: основные принципы, орга
Здравствуйте, GlebZ, Вы писали:
GZ>Там к каждому объекту можно прикрутить параметр PCTINCREASE. В нем лежат проценты увеличения. То есть, при аллокации следующего экстента Oracle увеличивает его размер на эту величину. В результате, уменьшается кол-во аллокаций в зависимости от объема данных.
Честно говоря, в действительности строение хранилища Oracle значительно более сложное. Оно более продвинутое чем в MS SQL, но на мой взгляд сильно избыточный механизм. здесь
С уважением, Gleb.
Re[19]: Объектно-ориентированные БД: основные принципы, орга
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, GlebZ, Вы писали: GZ>>Эта система очень похожа на систему сохранения MS SQL. Если посмотреть на систему хранения Oracle — то вообще ужаснешся. Там у изменяемый размер экстента. S>Круто! А на чем это было реализовано? Я вот сейчас потихоньку ковыряюсь с оптимизацией полиморфных ассоциативных запросов в управляемых средах. Экспериментирую на .Net 2.0 beta. S>Когда я получу query optimizer, потребуется хранилище и менеджер транзакций, к которому можно будет его прикрутить.
Круто! "Полиморфных ассоциативных запросов в управляемых средах" -- это звучит. Сразу наукой повеяло
Это в рамках аспирантуры и кандидатской диссертации?
Но вот мне интересно, а что query optimizer оптимизирует, если у вас нет хранилища и менеджера транзакций? Или есть предположение о наличи индексов по конкретным атрибутам, а уже как они реализованы -- это уже другой уровень абстракции?
И что используется в качестве языка запросов?
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[18]: Объектно-ориентированные БД: основные принципы, орга
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, GlebZ, Вы писали:
GZ>>Здравствуйте, Serginio1, Вы писали:
S>>>А насчет эффективности для конкретной задачи это ты зря. GZ>>Извини, если я чем-то обидел, но eao197 прав. Может транзакционный механизм как таковой и не нужен. Но в случае сбоя диска — возможна деструкция файла. А это для БД — смертеподобно. И алгоритм сохранения становится более интересным. Я не прав? S>На самом деле для таких простеньких ООДБМС есть несложный вариант транзакционности. WriteAhead лог реализуется при помощи перехвата всех методов объектов и протоколировании этих вызовов. Регулярно делается чекпоинт — т.е. состояние базы скидывается на диск. Лог-записи старше этого момента считаются ненужными и подлежат перезаписи. При старте базы выполняется чтение сигнатуры чекпоинта, которому она соответствует, лог сканируется в поисках этого чекпоинта, и выполняется воспроизведение всех транзакций, для которых стоит метка "commited". Для небольших объемов (в пределах ~100 Mb) на современном железе это вполне нормально работает.
Если уж БД совсем маленькая, в пределах 50-70Mb, и ее обновление можно производить сразу всей (т.е. полной перезаписью), то можно применять совсем простой механизм защиты от сбоев. Записывать сначала все содержимое БД в отдельный файл, например, с расширением .tmp. Если запись не была прервана сбоем, то файл флушируется и закрывается. Затем переименовывается в нужное имя. Если же запись прерывается сбоем, то файл так и остается под расширением .tmp и затем просто игнорируется. В нормальной журналируемой файловой системе (типа NTFS, Ext3, ReiserFS, ...) успешное флуширование и закрытие файла уже будет гарантировать логическую целостность информации. Ну а со сбоями носителя уже ничего не сделаешь.
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[20]: Объектно-ориентированные БД: основные принципы, орга
Здравствуйте, eao197, Вы писали: E>Круто! "Полиморфных ассоциативных запросов в управляемых средах" -- это звучит. Сразу наукой повеяло E>Это в рамках аспирантуры и кандидатской диссертации?
Именно. E>Но вот мне интересно, а что query optimizer оптимизирует, если у вас нет хранилища и менеджера транзакций? Или есть предположение о наличи индексов по конкретным атрибутам, а уже как они реализованы -- это уже другой уровень абстракции?
Ага. Точнее, результатом должно стать формальное описание алгоритма + набор минимальных требований к нижележащему уровню (скорее всего, это будет поддержка сканирования экстентов фиксированного класса и диапазонных сканов по скалярным индексам). E>И что используется в качестве языка запросов?
В настоящий момент я остановился на, как бы это сказать, использовании исходного языка. Т.е. идея в том, что мы пишем примерно такую штуку:
Код делегата (в данном случае анонимного) анализируется, переводится в функциональное представление, и генерируется query plan — императивная программа. В примере вверху все выглядит так, как если бы был вызван вот такой метод:
IEnumerable<IEmployee> SelectWhereSalaryLT500()
{
foreach(Employee e in EmployeeSalaryIndex.ScanRange(null, 500))
yield return e;
foreach(Volunteer v in VolunteerExtent) // добровольцы работают бесплатноyield return v;
}
Т.е. для всех классов, реализующих IEmployee, подбирается оптимальный алгоритм поиска.
... << RSDN@Home 1.1.4 beta 4 rev. 347>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[9]: Объектно-ориентированные БД: основные принципы, орган
Здравствуйте, GlebZ, Вы писали: GZ>Некоторая поправка — в большинстве своем гарантируется что поле(не блоб) умещается на страницу (MS SQL).
Ну, в MS SQL гарантируется, что запись умещается на одной странице. Поля типа image, text, varchar(max) и прочий крупный тоннаж хранятся специальным способом. GZ>Во вторых — вопрос: они могут удалить объект не затрагивая страницу если он на ней не единственный?
Брр. Не очень понял. При удалении записи, страница, на которой она живет, уплотняется. Это не стоит практически ничего по сравнению со стоимостью flush этой страницы. Поэтому свободное место на одной странице можно считать нефрагментированным. Остальные записи на этой странице продолжают жить своей жизнью. Я не знаю, выполняется ли слияние страниц, заполненных менее чем на 50%. GZ>Это свойство связано со сборкой мусора? То есть идет очищение при сборке мусора?
Нет, не связано. S>>Алгоритм "сборки мусора" на порядок проще — т.к. он во-первых запускается явно, т.е. не нужно его слишком уж оптимизировать, GZ>Что значит явно? В конце транзакции?
Нет, "сборку мусора" в странично-ориентированной СУБД нужно проводить только тогда, когда пользователь явно захочет компактифицировать файл. Потому что алгоритм выделения памяти устроен так, что освобожденные страницы гарантированно будут востребованы до того, как придется увеличивать размер файла. А т.к. болшинство приложений работает с постоянным либо нарастающим объемом данных, то пустые страницы долго не простаивают.
... << RSDN@Home 1.1.4 beta 4 rev. 347>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[21]: Объектно-ориентированные БД: основные принципы, орга
Кстати, в R# очень хорошо для поиска по объектному графу подошел XPath. Похожий на твой запрос будет выклюеть так:
IEnumerable<IEmployee> list = Extent<IEmployee>.Select("//Employee[Salary < 500]");
Или есби без излишеств:
foreach (Employee employee in Employees.Select("//Employee[Salary < 500]"))
{
...
}
Технология надо сказать уже работает и может быть спокойно перенесена на произвольный граф объектов. Если еще и компилируемый XPath сбацаем, то вообще лафа будет.
... << RSDN@Home 1.1.4 beta 3 rev. 279>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[22]: Объектно-ориентированные БД: основные принципы, орга
Да, конечно. Виноват — предпразничные дни, будь они неладны... VD>Кстати, в R# очень хорошо для поиска по объектному графу подошел XPath. Похожий на твой запрос будет выклюеть так: VD>
VD>IEnumerable<IEmployee> list = Extent<IEmployee>.Select("//Employee[Salary < 500]");
VD>
VD>Технология надо сказать уже работает и может быть спокойно перенесена на произвольный граф объектов. Если еще и компилируемый XPath сбацаем, то вообще лафа будет.
Let all flowers grow
... << RSDN@Home 1.1.4 beta 4 rev. 347>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[21]: Объектно-ориентированные БД: основные принципы, орга
Здравствуйте, Sinclair, Вы писали:
E>>Это в рамках аспирантуры и кандидатской диссертации? S>Именно.
Понятно. Желаю удачи!
А к то научный руководитель? И где еще в России остался такой интерес к теории БД, особенно ООБД?
<...>
E>>И что используется в качестве языка запросов? S>В настоящий момент я остановился на, как бы это сказать, использовании исходного языка. Т.е. идея в том, что мы пишем примерно такую штуку: S>
S>Код делегата (в данном случае анонимного) анализируется, переводится в функциональное представление, и генерируется query plan — императивная программа. В примере вверху все выглядит так, как если бы был вызван вот такой метод:
Интересно. Но, имхо, такое решение подходит для emebeded ООСУБД. Но как такие запросы обрабатывать в клиент-серверной многопользовательской системе? Передавать код запроса на сервер, чтобы он там скомпилировался, проанализировался и выполнился? Код на унивесальном языке программирования типа C#? Но тогда нужно будет как-то решать проблемы доверия и безопасности этого кода.
И еще вопрос: в выражениях можно будет использовать только атрибуты объектов или обращения к методам?
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[22]: Объектно-ориентированные БД: основные принципы, орга
Здравствуйте, eao197, Вы писали: E>Понятно. Желаю удачи!
Спасибо. E>А к то научный руководитель? А.М. Федотов. E> И где еще в России остался такой интерес к теории БД, особенно ООБД?
У меня E>Интересно. Но, имхо, такое решение подходит для emebeded ООСУБД. Но как такие запросы обрабатывать в клиент-серверной многопользовательской системе? Передавать код запроса на сервер, чтобы он там скомпилировался, проанализировался и выполнился?
Я думал о сериализации делегатов. Т.е. на клиенте мы вычисляем необходимое замыкание и передаем его на сервер. Это позволяет снять с сервера обязанности по компиляции, которая может завершиться и неудачей. E>Код на унивесальном языке программирования типа C#?
Конечно. E>Но тогда нужно будет как-то решать проблемы доверия и безопасности этого кода.
А какие проблемы? Управляемая среда тем и хороша, что не даст сделать ничего лишнего. Мало того, что нет риска "сломать" сервер банальным проходом по памяти — можно еще и ограничить набор допустимых конструкций.
В частности, внутри предиката нельзя менять состояния объектов. Иначе применение оптимизации будет менять семантику запроса — результат будет зависеть от порядка вычисления предиката для разных объектов. E>И еще вопрос: в выражениях можно будет использовать только атрибуты объектов или обращения к методам?
Собственно, все и затевается ради поддержки обращения к методам. Современные ОДБМС очень плохо дружат с полиморфизмом. В примере, который я приводил, Salary было виртуальным свойством, декларированным в интерфейсе.
... << RSDN@Home 1.1.4 beta 4 rev. 347>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[23]: Объектно-ориентированные БД: основные принципы, орга
Здравствуйте, Sinclair, Вы писали:
E>> И где еще в России остался такой интерес к теории БД, особенно ООБД? S>У меня
E>>Интересно. Но, имхо, такое решение подходит для emebeded ООСУБД. Но как такие запросы обрабатывать в клиент-серверной многопользовательской системе? Передавать код запроса на сервер, чтобы он там скомпилировался, проанализировался и выполнился? S>Я думал о сериализации делегатов. Т.е. на клиенте мы вычисляем необходимое замыкание и передаем его на сервер. Это позволяет снять с сервера обязанности по компиляции, которая может завершиться и неудачей.
Т.е. на сервер будет передаваться байт-код?
E>>Но тогда нужно будет как-то решать проблемы доверия и безопасности этого кода. S>А какие проблемы? Управляемая среда тем и хороша, что не даст сделать ничего лишнего. Мало того, что нет риска "сломать" сервер банальным проходом по памяти — можно еще и ограничить набор допустимых конструкций. S>В частности, внутри предиката нельзя менять состояния объектов. Иначе применение оптимизации будет менять семантику запроса — результат будет зависеть от порядка вычисления предиката для разных объектов.
AFAIK, когда-то было доказано, что для создания вирусов, достаточно штатных средств среды (о какой бы среде не шла речь, простейшие вирусы можно было делать даже на shell-скрипта). А тут речь идет об универсальных языках программирования. Может вам в запросе преднамерено передадут код с бесконечным циклом, например.
E>>И еще вопрос: в выражениях можно будет использовать только атрибуты объектов или обращения к методам? S>Собственно, все и затевается ради поддержки обращения к методам. Современные ОДБМС очень плохо дружат с полиморфизмом. В примере, который я приводил, Salary было виртуальным свойством, декларированным в интерфейсе.
Но тогда получится, что речь, в основном идет о getter-ах или о совсем тривиальных методах. А если метод сложнее? Например, если методу требуется проверить цифровую подпись, хранящуюся в одном из атрибутов агентов и сказать, корректна ли она или нет. Откуда на сервере возьмется код по проверке цифровой подписи? Или произвести сложные математические рассчеты (скажем, опрелить, поддает ли указанная точка в на нужную кривую) с применением сторонних библиотек?
Другая сторона медали. Если речь идет о вызовах методов, то метод, по-идее, должен вызываться у инстанцированного объекта. Т.е. для выполнения одного предиката сравнения придется в ОП инстанцировать каждый обрабатываемый объект и вызывать у него метод. Что тогда будет с производительностью сервера (особенно, если объект при инстанцировании будет выполнять какие-нибудь нетривиальные вещи, например, вычислять значения transient атрибутов на основании persistent атрибутов)?
И еще один вопрос, связанный вызовом методов у объектов. Если код методов объекта не хранится централизованно на сервере, то может возникнуть проблема наличия разных версий кода объекта у разных клиентов. Например, метод Salary у какого-то старого объекта будет возращать значение атрибута m_salary, а у более нового клиента -- значение m_salary с учетом каких-либо коэффициентов, премий и штрафов. Тогда один и тот же запрос, выполненый двумя этими клиентами над одним и тем же множеством данных может привести к разным результатам.
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[10]: Объектно-ориентированные БД: основные принципы, орга
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, GlebZ, Вы писали: GZ>>Некоторая поправка — в большинстве своем гарантируется что поле(не блоб) умещается на страницу (MS SQL). S>Ну, в MS SQL гарантируется, что запись умещается на одной странице. Поля типа image, text, varchar(max) и прочий крупный тоннаж хранятся специальным способом.
Глянул BOL. Что-то стормозил . Твоя правда. Только varchar всегда — хранятся вместе с row.
GZ>>Во вторых — вопрос: они могут удалить объект не затрагивая страницу если он на ней не единственный? S>Брр. Не очень понял. При удалении записи, страница, на которой она живет, уплотняется. Это не стоит практически ничего по сравнению со стоимостью flush этой страницы. Поэтому свободное место на одной странице можно считать нефрагментированным. Остальные записи на этой странице продолжают жить своей жизнью. Я не знаю, выполняется ли слияние страниц, заполненных менее чем на 50%.
Если не проставлено свойство autoshrink, то скорее всего нет. Есть некоторая вероятность, что есть слияния в clastered tables. Иначе получат большую вероятность того, что освобожденное место до shrink никогда не будет заполнено.
GZ>>Это свойство связано со сборкой мусора? То есть идет очищение при сборке мусора? S>Нет, не связано. S>>>Алгоритм "сборки мусора" на порядок проще — т.к. он во-первых запускается явно, т.е. не нужно его слишком уж оптимизировать, GZ>>Что значит явно? В конце транзакции? S>Нет, "сборку мусора" в странично-ориентированной СУБД нужно проводить только тогда, когда пользователь явно захочет компактифицировать файл. Потому что алгоритм выделения памяти устроен так, что освобожденные страницы гарантированно будут востребованы до того, как придется увеличивать размер файла. А т.к. болшинство приложений работает с постоянным либо нарастающим объемом данных, то пустые страницы долго не простаивают.
Теперь понял. Че-то происходит нехорошее с терминами. В последнее время я не могу определить что называть дефрагментацией, а что сборкой мусора. В MS SQL процедура оптимизации памяти — вообще называется shrink. Еще у тебя интересный термин "компактифицировать".
С уважением, Gleb.
Re[22]: Объектно-ориентированные БД: основные принципы, орга
VladD2 пишет: > IEnumerable<IEmployee> list = Extent<IEmployee>.Select("//Employee[Salary < 500]"); > > > Или есби без излишеств: > > foreach (Employee employee in Employees.Select("//Employee[Salary < 500]")) > { > ... > } >
Хм. А где статическая проверка типов для "Employee[Salary < 500]"?
А то некузяво получается, ты доказываеш всем какой крутой статически
типизируемый С# в качестве скриптового языка, а сам используеш совсем
даже не щарп и совсем даже не статически типизируемый.
--
Andrei N.Sobchuck
JabberID: andreis@jabber.ru. ICQ UIN: 46466235.
Здравствуйте, eao197, Вы писали: E>Т.е. на сервер будет передаваться байт-код?
Именно. E>AFAIK, когда-то было доказано, что для создания вирусов, достаточно штатных средств среды
Ну, лично я впервые об этом слышу. E>(о какой бы среде не шла речь, простейшие вирусы можно было делать даже на shell-скрипта).
Shell-скрипт требует админских привилегий для нанесения ущерба. E>А тут речь идет об универсальных языках программирования. Может вам в запросе преднамерено передадут код с бесконечным циклом, например.
В настоящее время помимо авторизации пользователя дополнительно авторизуют также и код. Есть такой термин — CAS, соde access security. При помощи него можно не дать волку (коду форматирования винта, например) притвориться овцой (безобидным гуи-гаджетом). E>Но тогда получится, что речь, в основном идет о getter-ах или о совсем тривиальных методах.
Почему? E> А если метод сложнее? Например, если методу требуется проверить цифровую подпись, хранящуюся в одном из атрибутов агентов и сказать, корректна ли она или нет. Откуда на сервере возьмется код по проверке цифровой подписи?
Ну как откуда? А откуда на сервере вообще берется код? Его заранее деплоят. Не вижу никаких проблем проверить цифровую подпись. E> Или произвести сложные математические рассчеты (скажем, опрелить, поддает ли указанная точка в на нужную кривую) с применением сторонних библиотек?
То же самое. E>Другая сторона медали. Если речь идет о вызовах методов, то метод, по-идее, должен вызываться у инстанцированного объекта.
Естественно. E>Т.е. для выполнения одного предиката сравнения придется в ОП инстанцировать каждый обрабатываемый объект и вызывать у него метод.
Не обязательно. Современные ODBMS так и делают. Мой оптимизатор будет пытаться построить такой план, при котором можно инстанцировать не все объекты. E>Что тогда будет с производительностью сервера (особенно, если объект при инстанцировании будет выполнять какие-нибудь нетривиальные вещи, например, вычислять значения transient атрибутов на основании persistent атрибутов)?
"Нетривиальные вещи" в наше время занимают о-малое затрат по сравнению со стоимостью загрузки страницы с диска. Поэтому дополнительными расходами по инстанцированию можно пренебречь. E>И еще один вопрос, связанный вызовом методов у объектов. Если код методов объекта не хранится централизованно на сервере, то может возникнуть проблема наличия разных версий кода объекта у разных клиентов.
Совершенно верно. Поэтому код хранится централизованно на сервере. E>Например, метод Salary у какого-то старого объекта будет возращать значение атрибута m_salary, а у более нового клиента -- значение m_salary с учетом каких-либо коэффициентов, премий и штрафов. Тогда один и тот же запрос, выполненый двумя этими клиентами над одним и тем же множеством данных может привести к разным результатам.
Ага. Именно это служило причиной критики файл-серверных СУБД, а затем и клиент-серверных решений с толстым клиентом. Client version mismatch — это аналог DLL-hell для data processing. Это как раз то, от чего мы хотим уйти. Навсегда .
... << RSDN@Home 1.1.4 beta 4 rev. 347>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[11]: Объектно-ориентированные БД: основные принципы, орга
Здравствуйте, GlebZ, Вы писали:
GZ>Здравствуйте, Sinclair, Вы писали:
S>>Здравствуйте, GlebZ, Вы писали: GZ>>>Некоторая поправка — в большинстве своем гарантируется что поле(не блоб) умещается на страницу (MS SQL). S>>Ну, в MS SQL гарантируется, что запись умещается на одной странице. Поля типа image, text, varchar(max) и прочий крупный тоннаж хранятся специальным способом. GZ>Глянул BOL. Что-то стормозил . Твоя правда. Только varchar всегда — хранятся вместе с row.
varchar(<const>) — да. Varchar(max) — нет. Читать здесь. GZ>>>Во вторых — вопрос: они могут удалить объект не затрагивая страницу если он на ней не единственный? GZ>Если не проставлено свойство autoshrink, то скорее всего нет.
Autoshrink, afaik, опять же никакого влияния на низкоуровневые алгоритмы не оказывает. Это просто опция иногда делать компактификацию автоматически. Так же, как autoupdate statistics. GZ>Теперь понял. Че-то происходит нехорошее с терминами. В последнее время я не могу определить что называть дефрагментацией, а что сборкой мусора. В MS SQL процедура оптимизации памяти — вообще называется shrink. Еще у тебя интересный термин "компактифицировать".
Верно. Термин компактифицировать == shrink. Не нашел лучшего русского аналога. Не хотелось писать "пошринкать спейс надо тогда, когда гарбадж занимает больше 50% вольюма".
... << RSDN@Home 1.1.4 beta 4 rev. 347>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[25]: Объектно-ориентированные БД: основные принципы, орга
Здравствуйте, Sinclair, Вы писали:
E>>AFAIK, когда-то было доказано, что для создания вирусов, достаточно штатных средств среды S>Ну, лично я впервые об этом слышу. E>>(о какой бы среде не шла речь, простейшие вирусы можно было делать даже на shell-скрипта). S>Shell-скрипт требует админских привилегий для нанесения ущерба.
Была такая книжка, когда-то, "Прикладная вирусология" Николая Безрукова (если память не изменяет). Вот там это и утверждалось.
А на счет shell-скрипта: можно сделать простенький скрипт, который просто до бесконечности копирует самого себя, создавая для этого огромное количество вложенных подкаталогов. Завершается его работа только после исчерпания свободного места на диске. И, если для пользователей не установлены квоты дискового пространства (а это не везде возможно), то такой скрипт может поставить на колени всю систему, даже без административных прав.
E>>А тут речь идет об универсальных языках программирования. Может вам в запросе преднамерено передадут код с бесконечным циклом, например. S>В настоящее время помимо авторизации пользователя дополнительно авторизуют также и код. Есть такой термин — CAS, соde access security. При помощи него можно не дать волку (коду форматирования винта, например) притвориться овцой (безобидным гуи-гаджетом).
Как я понимаю, потребуется запускать код запроса в отдельной виртуальной машине, для которой сильно сокращен список возможных действий (или как это в .Net называется). Но, если коду запроса потребуется обращаться к дополнительным библиотекам, к той же криптографии, например? Сможет ли эта библиотека работать в нужных ограничениях доступа?
Или планируется запускать код запросов в той же виртуальной машине, что и код СУБД? Если так, то существуют ли средства, чтобы запретить коду запроса дергать что-либо из внутренностей СУБД?
А если запускать в другой ВМ, то там свои вопросы будут возникать.
Я ничего не критикую и не навязываю. Мне просто интересно, что ты думаешь по этому поводу. Если это не секрет, конечно.
<...>
Про код, который деплоится на сервер понятно. Я просто хотел уточнить так ли это.
Но что делать, если в СУБД хранятся данные для решения множества задач? Например, СУБД хранит проектную документацию по проекту самолета, где будут и чертежы, и расчеты, и спецификации. Поскольку СУБД объектная, то легко расставлять ссылки, скажем из чертежа на спецификацию какой-либо детали. И для решения каждой из задач необходимы разные наборы инструментов. Получится ли тогда вообще задеплоить все эти инструменты на один сервер?
E>>Другая сторона медали. Если речь идет о вызовах методов, то метод, по-идее, должен вызываться у инстанцированного объекта. S>Естественно. E>>Т.е. для выполнения одного предиката сравнения придется в ОП инстанцировать каждый обрабатываемый объект и вызывать у него метод. S>Не обязательно. Современные ODBMS так и делают. Мой оптимизатор будет пытаться построить такой план, при котором можно инстанцировать не все объекты.
А вот это интересно. Как именно?
Ведь ты не можешь закэшировать возвращаемые методами значения, если не уверен, что код метода всегда будет возращать одинаковое значение при одинаковых входных параметрах. А вдруг код метода зависит, например, от текущей даты или дня недели.
E>>Что тогда будет с производительностью сервера (особенно, если объект при инстанцировании будет выполнять какие-нибудь нетривиальные вещи, например, вычислять значения transient атрибутов на основании persistent атрибутов)? S>"Нетривиальные вещи" в наше время занимают о-малое затрат по сравнению со стоимостью загрузки страницы с диска. Поэтому дополнительными расходами по инстанцированию можно пренебречь.
Не думаю. Если, скажем, размер страницы 64K, а на ней помещается 1000 объектов, то инстанцирование этой тысячи объектов начнет сказываться. Особенно, если страница уже есть в кэше.
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[26]: Объектно-ориентированные БД: основные принципы, орга
E>Была такая книжка, когда-то, "Прикладная вирусология" Николая Безрукова (если память не изменяет). Вот там это и утверждалось. E>А на счет shell-скрипта: можно сделать простенький скрипт, который просто до бесконечности копирует самого себя, создавая для этого огромное количество вложенных подкаталогов. Завершается его работа только после исчерпания свободного места на диске. И, если для пользователей не установлены квоты дискового пространства (а это не везде возможно), то такой скрипт может поставить на колени всю систему, даже без административных прав.
Это называется DOS-атака. Техника защиты от DOS-атак тоже существует, и особых проблем нет. Акцент надо делать на "если квоты не установлены" и учитывать эти особенности при проектировании сервера приложений. Хотя в современном мире это не очень-то принято — достаточно авторизации. Т.е. квоты требуются там, где есть анонимный доступ.
Вот, например, я могу как нефиг делать подключиться к MS SQL и исполнить там бесконечный цикл (на это вообще практически никаких пермишшнов не надо). И что? Во-первых, придет админ и даст мне в репу, а во-вторых, там есть такая галочка "query governor limit", которую можно включить на сервере избежать необходимости отстреливать бесконечные запросы вручную. E>Как я понимаю, потребуется запускать код запроса в отдельной виртуальной машине, для которой сильно сокращен список возможных действий (или как это в .Net называется). Но, если коду запроса потребуется обращаться к дополнительным библиотекам, к той же криптографии, например? Сможет ли эта библиотека работать в нужных ограничениях доступа? E>Или планируется запускать код запросов в той же виртуальной машине, что и код СУБД? Если так, то существуют ли средства, чтобы запретить коду запроса дергать что-либо из внутренностей СУБД?
Я думаю, тебе стоит почитать в MSDN про CAS. Вкратце — в управляемой среде мы всегда можем проверить, какой код и откуда выполняется. Ограничения выдаются не всей машине, а отдельным фрагментам кода. Поэтому тому коду, который был задеплоен на сервер доверенными девелоперам, мы выдаем право работать с чем-то важным, а коду, который приехал к нам из клиентского приложения для однократного выполнения — нет.
E>Про код, который деплоится на сервер понятно. Я просто хотел уточнить так ли это. E>Но что делать, если в СУБД хранятся данные для решения множества задач? Например, СУБД хранит проектную документацию по проекту самолета, где будут и чертежы, и расчеты, и спецификации. Поскольку СУБД объектная, то легко расставлять ссылки, скажем из чертежа на спецификацию какой-либо детали. И для решения каждой из задач необходимы разные наборы инструментов. Получится ли тогда вообще задеплоить все эти инструменты на один сервер?
А в чем, собственно, проблема? Главное — в том, что все ссылки между объектами существуют только в пределах БД. При проектировании комплекса весь код известен. Деплоим все, что нужно для жизни, на сервер — и вуаля. E>А вот это интересно. Как именно? E>Ведь ты не можешь закэшировать возвращаемые методами значения, если не уверен, что код метода всегда будет возращать одинаковое значение при одинаковых входных параметрах. А вдруг код метода зависит, например, от текущей даты или дня недели.
Ну я вроде написал — как. Я дизассемблирую код и перевожу его в функциональное представление. Если удается выделить в предикате термы, позволяющие провести индексный поиск, то мы сразу сужаем количество объектов, на которых придется вызывать residual predicate. Кэширование результатов вызовов я пока вводить не планирую. Но по другой причине — слишком низки шансы получить cache hit для методов с хотя бы одним параметром. E>Не думаю. Если, скажем, размер страницы 64K, а на ней помещается 1000 объектов, то инстанцирование этой тысячи объектов начнет сказываться.
Ну допустим, инстанцирование объекта занимает 100000 тактов. Сколько времени займет эта тысяча на моем PIII-1700? E>Особенно, если страница уже есть в кэше.
Если страница в кэше — то и объекты инстанцированы. Все просто: инстанцирование и удаление объектов должны быть связаны со страничным кэшем 1:1.
... << RSDN@Home 1.1.4 beta 4 rev. 347>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[27]: Объектно-ориентированные БД: основные принципы, орга
Здравствуйте, Sinclair, Вы писали:
E>>Как я понимаю, потребуется запускать код запроса в отдельной виртуальной машине, для которой сильно сокращен список возможных действий (или как это в .Net называется). Но, если коду запроса потребуется обращаться к дополнительным библиотекам, к той же криптографии, например? Сможет ли эта библиотека работать в нужных ограничениях доступа? E>>Или планируется запускать код запросов в той же виртуальной машине, что и код СУБД? Если так, то существуют ли средства, чтобы запретить коду запроса дергать что-либо из внутренностей СУБД? S>Я думаю, тебе стоит почитать в MSDN про CAS. Вкратце — в управляемой среде мы всегда можем проверить, какой код и откуда выполняется. Ограничения выдаются не всей машине, а отдельным фрагментам кода. Поэтому тому коду, который был задеплоен на сервер доверенными девелоперам, мы выдаем право работать с чем-то важным, а коду, который приехал к нам из клиентского приложения для однократного выполнения — нет.
Найду время, почитаю. Я ведь управляемый код не пишу (пока)
E>>Про код, который деплоится на сервер понятно. Я просто хотел уточнить так ли это. E>>Но что делать, если в СУБД хранятся данные для решения множества задач? Например, СУБД хранит проектную документацию по проекту самолета, где будут и чертежы, и расчеты, и спецификации. Поскольку СУБД объектная, то легко расставлять ссылки, скажем из чертежа на спецификацию какой-либо детали. И для решения каждой из задач необходимы разные наборы инструментов. Получится ли тогда вообще задеплоить все эти инструменты на один сервер? S>А в чем, собственно, проблема? Главное — в том, что все ссылки между объектами существуют только в пределах БД. При проектировании комплекса весь код известен. Деплоим все, что нужно для жизни, на сервер — и вуаля.
А если не получится? Если для одних задач нужны Windows-only инструменты, а для других -- Unix-only?
E>>А вот это интересно. Как именно? E>>Ведь ты не можешь закэшировать возвращаемые методами значения, если не уверен, что код метода всегда будет возращать одинаковое значение при одинаковых входных параметрах. А вдруг код метода зависит, например, от текущей даты или дня недели. S>Ну я вроде написал — как. Я дизассемблирую код и перевожу его в функциональное представление. Если удается выделить в предикате термы, позволяющие провести индексный поиск, то мы сразу сужаем количество объектов, на которых придется вызывать residual predicate. Кэширование результатов вызовов я пока вводить не планирую. Но по другой причине — слишком низки шансы получить cache hit для методов с хотя бы одним параметром.
Может я просто не увидел, где ты это описывал, ивини.
Интересная идея. А под термами понимается доступ к атрибутам объекта? Т.е. ты предполагаешь строить индексы по атрибутам, даже если доступ к ним ограничен через getter/setter-ы? А как же тогда инкапсуляция?
E>>Не думаю. Если, скажем, размер страницы 64K, а на ней помещается 1000 объектов, то инстанцирование этой тысячи объектов начнет сказываться. S>Ну допустим, инстанцирование объекта занимает 100000 тактов. Сколько времени займет эта тысяча на моем PIII-1700?
Ну на одной странице может и не много. А на сотне-другой. У меня, лично, получалось, что накладные расходы на инстанцирование мелких объектиков в C++ достигали 1/3 времени от общего времени работы с БД. И уходило это время, в основном, на new/delete. В языках со сборкой мусора эти затраты могут быть и ниже, то тех пор, пока в распоряжении есть достаточно памяти. Зато потом может быть затык в самый неподходящий момен. Но это уже совсем другая история.
E>>Особенно, если страница уже есть в кэше. S>Если страница в кэше — то и объекты инстанцированы. Все просто: инстанцирование и удаление объектов должны быть связаны со страничным кэшем 1:1.
Ok. Теперь предположим, что страница в кэше занимает 64K. Тысяча инстанцированных из нее объектов, например, в полтора раза больше (поскольку для них будет оверхед по занимаемому пространству). Итак, делаем размер кэша в 100Mb и получаем еще 150Mb на хранение инстанцированных объектов. Которые, при этом, могут совсем и не использоваться.
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[28]: Объектно-ориентированные БД: основные принципы, орга
Здравствуйте, eao197, Вы писали:
E>Найду время, почитаю. Я ведь управляемый код не пишу (пока)
Ничего, это ненадолго E>А если не получится? Если для одних задач нужны Windows-only инструменты, а для других -- Unix-only?
Что-то вот тут я перестаю понимать. О каких инструментах идет речь? Серверный код оперирует серверной объектной моделью. Т.е существует некоторый API, представленный набором сборок/пакетов ядра. Попытка задеплоить в сервер сборку System.Windows.Forms ни к чему хорошему не приведет — использование ее объектов подразумевает наличие десктопа, которого в Application Server просто нет. И даже если бы такая попытка удалась, то какова была бы семантика использования таких объектов? Это примерно то же самое, как подключиться к MS SQL Server и выполнить sp_exec('calc.exe'). Ну запустим мы инстанс калькулятора на сервере, и что? Пользователь его все равно не увидит.
В сервере должен жить серверный код. С точки зрения объектов в СУБД окружающая среда состоит из других объектов СУБД и некоторых сервисов (можно считать их static классами), которые помогают объектам выполнять свои обязанности. Я с трудом себе представляю реализацию класса "элемент спецификации самолета", которому бы потребовалась Windows-specific функциональность.
E>Может я просто не увидел, где ты это описывал, ивини. E>Интересная идея. А под термами понимается доступ к атрибутам объекта?
Под термами понимаются некоторые элементарные булевые операции. В частности, доступ к атрибутам объекта. В общем случае, произвольный предикат не удастся представить в виде функции от значений атрибутов объекта. Например, если в нем участвует метод object.GetClass() Но для простоты можно считать, что мы приводим императивный код к виду, в котором листьями AST являются обращения к атрибутам. E>Т.е. ты предполагаешь строить индексы по атрибутам, даже если доступ к ним ограничен через getter/setter-ы?
Для начала да. E>А как же тогда инкапсуляция?
А она никак не страдает. Инкапсуляция управляет возможностями прикладного кода, изолируя автора предиката от особенностей реализации конкретных классов. С точки зрения сервера, никакой инкапсуляции нет. Пользователь по-прежнему не может использовать приватные атрибуты напрямую; вместо этого он вынужден использовать методы доступа. Сервер просто переформулирует валидный запрос в таком виде, чтобы увеличить производительность. E>Ну на одной странице может и не много. А на сотне-другой. У меня, лично, получалось, что накладные расходы на инстанцирование мелких объектиков в C++ достигали 1/3 времени от общего времени работы с БД. И уходило это время, в основном, на new/delete.
Это как минимум очень странно. Я в свое время имел подобный опыт. Но там затраты на превращение raw данных в объекты не превосходили 10%, и то, в основном из-за очень хреновой структуры — там каждый атрибут был объектом, и его размер был очень велик.
Тут надо помнить вот о чем — в инстанцировании объектов, как правило, основное время занимает выделение памяти. Оно становится заметным как только мы залезаем в своп. В СУБД так быть не должно — кэш всегда лежит только в физической памяти. Когда надо поднять еще одну страницу и памяти не хватает, мы должны отфлашить какую-то из занятых, а не лезть в споп. E>В языках со сборкой мусора эти затраты могут быть и ниже, то тех пор, пока в распоряжении есть достаточно памяти. Зато потом может быть затык в самый неподходящий момен. Но это уже совсем другая история. E>Ok. Теперь предположим, что страница в кэше занимает 64K.
Ну, это очень толстая страница Типичный размер страницы кэша — 8kb. E>Тысяча инстанцированных из нее объектов, например, в полтора раза больше (поскольку для них будет оверхед по занимаемому пространству).
Есть такой риск. E>Итак, делаем размер кэша в 100Mb и получаем еще 150Mb на хранение инстанцированных объектов. Которые, при этом, могут совсем и не использоваться.
Ну как это "совсем не использоваться"? Надо повышать cache hit ratio В целом верно — то, чего я ожидаю, даст как минимум двукратный оверхед по памяти. С другой стороны, "память больше не ресурс" Просто кэш станет вмещать чуть меньше. В гигабайте памяти поместится не десять миллионов записей, а три миллиона объектов. Но применение оптимизаций запросов уменьшит требования к кэшу. Т.е. если удалось найти терм, связанный с индексом с селективностью хотя бы в 20%, нам потребуется поднять в память, к примеру, два миллиона оюъектов вместо десяти. Т.е. у нас все еще есть риск иметь cache hit ratio ~ 100%, несмотря на уменьшение эффективной емкости кэша втрое.
Конечно, пока что это писано вилами по воде. Надо ставить натурные эксперименты, проверять, действительно ли в реальных приложениях можно добиться повышения эффективности сервера благодаря такой методике, или оверхед по памяти сделает технику применимой только для небольших сетей крупномасштабных объектов.
... << RSDN@Home 1.1.4 beta 4 rev. 347>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[29]: Объектно-ориентированные БД: основные принципы, орга
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, eao197, Вы писали:
E>>Найду время, почитаю. Я ведь управляемый код не пишу (пока) S>Ничего, это ненадолго
Это уже в другой топик
E>>А если не получится? Если для одних задач нужны Windows-only инструменты, а для других -- Unix-only? S>Что-то вот тут я перестаю понимать. О каких инструментах идет речь? Серверный код оперирует серверной объектной моделью. Т.е
Да, здесь меня занесло. Я забыл, что речь идет о .Net. И все должно будет крутиться под .Net.
E>>Т.е. ты предполагаешь строить индексы по атрибутам, даже если доступ к ним ограничен через getter/setter-ы? S>Для начала да.
Ok.
E>>А как же тогда инкапсуляция? S>А она никак не страдает. Инкапсуляция управляет возможностями прикладного кода, изолируя автора предиката от особенностей реализации конкретных классов. С точки зрения сервера, никакой инкапсуляции нет. Пользователь по-прежнему не может использовать приватные атрибуты напрямую; вместо этого он вынужден использовать методы доступа. Сервер просто переформулирует валидный запрос в таком виде, чтобы увеличить производительность.
Это уже иделогический вопрос -- должен ли сервер иметь право напряму работать со значениями объектов. ИМХО, то что ты предлагаешь, есть нарушение инкапсуляции. Но в ООСУБД, может быть, это и можно допускать.
E>>Ну на одной странице может и не много. А на сотне-другой. У меня, лично, получалось, что накладные расходы на инстанцирование мелких объектиков в C++ достигали 1/3 времени от общего времени работы с БД. И уходило это время, в основном, на new/delete. S>Это как минимум очень странно. Я в свое время имел подобный опыт. Но там затраты на превращение raw данных в объекты не превосходили 10%, и то, в основном из-за очень хреновой структуры — там каждый атрибут был объектом, и его размер был очень велик.
Ну, у меня как раз объекты были не большими, но содержали атрибуты, который нуждались в выделении памяти (std::vector, std::string). В результате инстанцирование одного объекта приводило к множеству new. А еще сказывалось то, что использовался Multithreading режим, в котором new работает медленнее.
E>>В языках со сборкой мусора эти затраты могут быть и ниже, то тех пор, пока в распоряжении есть достаточно памяти. Зато потом может быть затык в самый неподходящий момен. Но это уже совсем другая история. E>>Ok. Теперь предположим, что страница в кэше занимает 64K. S>Ну, это очень толстая страница Типичный размер страницы кэша — 8kb.
Ну это как посмотреть. Диски разные бывают. Вот, например, в BerkeleyDB есть возможность изменять размер страницы. И максимальный размер — 64K.
E>>Итак, делаем размер кэша в 100Mb и получаем еще 150Mb на хранение инстанцированных объектов. Которые, при этом, могут совсем и не использоваться. S>Ну как это "совсем не использоваться"? Надо повышать cache hit ratio В целом верно — то, чего я ожидаю, даст как минимум двукратный оверхед по памяти. С другой стороны, "память больше не ресурс" Просто кэш станет вмещать чуть меньше. В гигабайте памяти поместится не десять миллионов записей, а три миллиона объектов. Но применение оптимизаций запросов уменьшит требования к кэшу. Т.е. если удалось найти терм, связанный с индексом с селективностью хотя бы в 20%, нам потребуется поднять в память, к примеру, два миллиона оюъектов вместо десяти. Т.е. у нас все еще есть риск иметь cache hit ratio ~ 100%, несмотря на уменьшение эффективной емкости кэша втрое.
Нет, я имел в виду, что для выполнения какого-то запроса потребовалось 50 объектов со страницы. Для следующего запроса еще 5 объектов. Затем еще 20. А остальные 900 просто место занимает.
S>Конечно, пока что это писано вилами по воде. Надо ставить натурные эксперименты, проверять, действительно ли в реальных приложениях можно добиться повышения эффективности сервера благодаря такой методике, или оверхед по памяти сделает технику применимой только для небольших сетей крупномасштабных объектов.
Это точно.
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[30]: Объектно-ориентированные БД: основные принципы, орга
E>Это уже иделогический вопрос -- должен ли сервер иметь право напряму работать со значениями объектов. ИМХО, то что ты предлагаешь, есть нарушение инкапсуляции. Но в ООСУБД, может быть, это и можно допускать.
Ничего подобного. Тебя же не оскорбляет способность С++ инлайнить методы? Получается, что "среда" выполняет (о, ужас!) прямой доступ к атрибуту вместо честного вызова метода, сопряженного со всеми проблемами конвейера CPU и напряжения кэша . Серверу — можно.
E>Ну, у меня как раз объекты были не большими, но содержали атрибуты, который нуждались в выделении памяти (std::vector, std::string). В результате инстанцирование одного объекта приводило к множеству new. А еще сказывалось то, что использовался Multithreading режим, в котором new работает медленнее.
Угу. Тем не менее, это означает что у тебя была суперэффективная СУБД. Мне в жизни не встречалась СУБД, способная отдавать данные со скоростью, сравнимой со скоростью New. E>Ну это как посмотреть. Диски разные бывают. Вот, например, в BerkeleyDB есть возможность изменять размер страницы. И максимальный размер — 64K.
Ну как тебе сказать... Размер страницы выбирается из соображений общей эффективности. Вон, в MS SQL помимо страниц есть еще и экстенты — как раз 64к. АФАИК, они такие ровно для улучшения взаимодйствия с дисковым контроллером. E>Нет, я имел в виду, что для выполнения какого-то запроса потребовалось 50 объектов со страницы. Для следующего запроса еще 5 объектов. Затем еще 20. А остальные 900 просто место занимает.
Ну, тут все зависит от размера страницы, и стратегии размещения объектов в применении к типичным access patterns.
... << RSDN@Home 1.1.4 beta 4 rev. 347>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[31]: Объектно-ориентированные БД: основные принципы, орга
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, eao197, Вы писали:
E>>Это уже иделогический вопрос -- должен ли сервер иметь право напряму работать со значениями объектов. ИМХО, то что ты предлагаешь, есть нарушение инкапсуляции. Но в ООСУБД, может быть, это и можно допускать. S>Ничего подобного. Тебя же не оскорбляет способность С++ инлайнить методы? Получается, что "среда" выполняет (о, ужас!) прямой доступ к атрибуту вместо честного вызова метода, сопряженного со всеми проблемами конвейера CPU и напряжения кэша . Серверу — можно.
Нет, не удачный пример. Если у меня есть код get_something() { return m_a + f(); }, то мне безразлично, что вычисление (m_a + f()) происходит в месте вызова get_something, поскольку мне возвращается не "голое значение" атрибута m_a, а преобразованное в соответствии с прикладной логикой. Если же СУБД индексирует по m_a неопосредственно обращаясь к нему, то это, ИМХО, нарушение инкапсуляции.
E>>Ну, у меня как раз объекты были не большими, но содержали атрибуты, который нуждались в выделении памяти (std::vector, std::string). В результате инстанцирование одного объекта приводило к множеству new. А еще сказывалось то, что использовался Multithreading режим, в котором new работает медленнее. S>Угу. Тем не менее, это означает что у тебя была суперэффективная СУБД. Мне в жизни не встречалась СУБД, способная отдавать данные со скоростью, сравнимой со скоростью New.
Ага, надеюсь, что таковой она и будет
Я же сказал, что 1/3 времени. А две третьи -- это время read-а с диска. Плюс извлечение информации уже из закешированных страниц (причем не только из моего кэша, но из кэша файловой системы и из кэша контроллера диска).
E>>Нет, я имел в виду, что для выполнения какого-то запроса потребовалось 50 объектов со страницы. Для следующего запроса еще 5 объектов. Затем еще 20. А остальные 900 просто место занимает. S>Ну, тут все зависит от размера страницы, и стратегии размещения объектов в применении к типичным access patterns.
Возможно.
Sinclair, а у тебя, случайно нет ODMG-3 стандарта в электронном виде?
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[32]: Объектно-ориентированные БД: основные принципы, орга
Здравствуйте, eao197, Вы писали:
E>Нет, не удачный пример.
Вполне удачный. E>Если у меня есть код get_something() { return m_a + f(); }, то мне безразлично, что вычисление (m_a + f()) происходит в месте вызова get_something, поскольку мне возвращается не "голое значение" атрибута m_a, а преобразованное в соответствии с прикладной логикой. E>Если же СУБД индексирует по m_a неопосредственно обращаясь к нему, то это, ИМХО, нарушение инкапсуляции.
По-моему, ты не следуешь за моей мыслью. Ну давай поковыряем твой пример. Предположим, что и get_something, и f() — виртуальные. И предикат устроен примерно так:
bool TempPredicate(myObject m)
{
return m.get_Something() > 0;
}
Ты не сможешь в предикате написать ничего про m.m_a.
Зато СУБД посмотрит в код, и увидит там вот такое:
bool TempPredicate(myObject m)
{
return m.m_a > -5;
}
А это уже повод посканироваться по индексу по m_a.
Вот и все. E> E>Sinclair, а у тебя, случайно нет ODMG-3 стандарта в электронном виде?
Неа. Уж очень он дорогой.
... << RSDN@Home 1.1.4 beta 4 rev. 347>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[23]: Объектно-ориентированные БД: основные принципы, орга
ANS>Хм. А где статическая проверка типов для "Employee[Salary < 500]"?
А это XPath. Его система типов пока что не совместима с Шарповсокй. Но над этим уже работают. По слухам в следующей версии языка будт встроена работа с ХМЛ и БД.
ANS>А то некузяво получается, ты доказываеш всем какой крутой статически ANS>типизируемый С# в качестве скриптового языка, а сам используеш совсем ANS>даже не щарп и совсем даже не статически типизируемый.
Я использую библиотеку осущесавлюющую запросы. А в качестве импереативного языка обработки данных использую XPath. На сегодя используется универсальная библиотека и проверить типы естествнно ен удается. Но в планах создание компилируемых XPath запросов. Вот там (кроме скорости) можно и строгую типизацию между XPath-ом и C# сделать, так как запросы будут превращаться в код на C#.
... << RSDN@Home 1.1.4 beta 3 rev. 279>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[24]: Объектно-ориентированные БД: основные принципы, орга
VladD2 пишет:
> А это XPath. Его система типов пока что не совместима с Шарповсокй. Но > над этим уже работают. По слухам в следующей версии языка будт > встроена работа с ХМЛ и БД.
Если они, не дай бог, это сделают, то получится НЕЧТО еще хуже С++
--
С уважением,
Alex Besogonov (alexy@izh.com)
Posted via RSDN NNTP Server 1.9
Sapienti sat!
Re[33]: Объектно-ориентированные БД: основные принципы, орга
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, eao197, Вы писали:
E>>Нет, не удачный пример. S>Вполне удачный.
Спасибо за разъяснения. Я предполагал что-то подобное, но, имхо, это очень сложная задача. Если ты за нее взялся, то желаю успехов вдвойне! Надеюсь, что это приведет к получению достойного результата.
<...>
E>> E>>Sinclair, а у тебя, случайно нет ODMG-3 стандарта в электронном виде? S>Неа. Уж очень он дорогой.
Вот и у меня такая же история.
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[22]: Объектно-ориентированные БД: основные принципы, орга
VD>Технология надо сказать уже работает и может быть спокойно перенесена на произвольный граф объектов. Если еще и компилируемый XPath сбацаем, то вообще лафа будет.
Во блин. Почему мне больше нравится OQL чем XPath. Не тем что он похож на SQL. Мне на это полностью начхать. XPath все-таки подразумевает дерево(для того и делался), а не произвольный граф.
Например, напиши такой запрос:
select a where a.f1=b.f1 and b.f1=c.f1 and c.f2=20
где никакие связи между a, b, и с нигде не отражены.
VladD2 пишет: > А это XPath. Его система типов пока что не совместима с Шарповсокй. Но > над этим уже работают. По слухам в следующей версии языка будт встроена > работа с ХМЛ и БД.
Кстати, не просветишь о "политике партии" на этот счет? А то я встречал
в Инете упоминания, что XPath не будет, а будет что-то другое, но
подробно не разбирался. Отложилось в голове, что что-то меняется, но вот
что и зачем?
--
Andrei N.Sobchuck
JabberID: andreis@jabber.ru. ICQ UIN: 46466235.
Здравствуйте, prVovik, Вы писали:
V>Здравствуйте, GlebZ, Вы писали:
GZ>>select a where a.f1=b.f1 and b.f1=c.f1 and c.f2=20 V>Ну, если с синтаксисом не напутал: V>
VladD2 пишет:
> C>Если они, не дай бог, это сделают, то получится НЕЧТО еще хуже С++ > Незнаю. Скорее всего все будет ОК. Они слишком заботятся о сохранении > простоты...
Не знаю как вам, но для меня SQL в языке — бред. Так как это скорее
всего будет сделано в виде железной привязки к MSSQL (знаем мы этих
МСников...).
--
С уважением,
Alex Besogonov (alexy@izh.com)
Posted via RSDN NNTP Server 1.9
Sapienti sat!
Re[25]: Объектно-ориентированные БД: основные принципы, орга
Здравствуйте, GlebZ, Вы писали:
GZ>XPath все-таки подразумевает дерево(для того и делался), а не произвольный граф.
Это почему еще?
ИМХО, применение XPath для графа будет отличаться от дерева только тем, что некоторые оси навигации, подразумевающие дерево, потеряют смысл.
... << RSDN@Home 1.1.4 @@subversion >>
лэт ми спик фром май харт
Re[27]: Объектно-ориентированные БД: основные принципы, орга
Здравствуйте, prVovik, Вы писали:
V>Здравствуйте, eao197, Вы писали:
V>>>>>А вот тоже пример: V>>>>>
/a[f = 10]/b[f = 20 ]/c[ f = 30 ]/d/@f
E>>>>Потрясающая читабельность у обоих вариантов V>>>А приведи SQL вариант второго примера
E>>А что он вообще делает? Я ведь XPath не знаю
V>Ну, допустим у нас есть XML дерево: V>
V><a f="10" >
V> <b f="15" />
V> <b f="20" >
V> <c f="25" />
V> <c f="30" >
V> <d f="40"> <!-- значение атрибута f этого узла и надо получить -->
V> </c>
V> </b>
V></a>
V>
Задача понятна. Но как ее решить на SQL/OQL лично я не знаю.
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[27]: Объектно-ориентированные БД: основные принципы, орга
Здравствуйте, Cyberax, Вы писали: C>Не знаю как вам, но для меня SQL в языке — бред. Так как это скорее C>всего будет сделано в виде железной привязки к MSSQL (знаем мы этих C>МСников...).
Неа. Там все будет еще интереснее. Никакой привязки не произойдет — это все фичи языка, а не сервера. Прежде чем клеймить, почитай на микрософт ресерче про си-омегу.
... << RSDN@Home 1.1.4 beta 4 rev. 347>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[28]: Объектно-ориентированные БД: основные принципы, орга
Sinclair пишет:
> C>Не знаю как вам, но для меня SQL в языке — бред. Так как это скорее > C>всего будет сделано в виде железной привязки к MSSQL (знаем мы этих > C>МСников...). > Неа. Там все будет еще интереснее. Никакой привязки не произойдет — > это все фичи языка, а не сервера. Прежде чем клеймить, почитай на > микрософт ресерче про си-омегу <http://research.microsoft.com/comega/>.
Гадость. В язык тянут прикладные вещи типа XML, вместо того, чтобы
добавить средства, позволяющие реализовать то же самое, но в виде библиотек.
--
С уважением,
Alex Besogonov (alexy@izh.com)
Posted via RSDN NNTP Server 1.9
Sapienti sat!
Re[26]: Объектно-ориентированные БД: основные принципы, орга
Здравствуйте, prVovik, Вы писали:
V>Здравствуйте, eao197, Вы писали:
V>>>А вот тоже пример: V>>>
/a[f = 10]/b[f = 20 ]/c[ f = 30 ]/d/@f
E>>Потрясающая читабельность у обоих вариантов V>А приведи SQL вариант второго примера
Во первых- не OQL а SQL. Во вторых — запрос не правомерен, поскольку для OQL нет активной ноды, а все является графом. Поэтому даю два варианта;
Для
//a[f = 10]/b[f = 20 ]/c[ f = 30 ]/d/@f
select a.b.c.d.f where a.f=10 and a.b.f=20 and a.b.c.f=30
Несколько более читабельней будет.
Второй вариант — это если нам известен объект от которого мы скачем. Тут зависит от реализации OQL (коих немало), напишу примерно такой:
select m.a.b.c.d.f where m.a.f=10 and m.a.b.f=20 and m.a.b.c.f=30 and m.oid=@oid
С уважением, Gleb.
Re[18]: Объектно-ориентированные БД: основные принципы, орга
Здравствуйте, Sinclair, Вы писали:
S>На самом деле для таких простеньких ООДБМС есть несложный вариант транзакционности. WriteAhead лог реализуется при помощи перехвата всех методов объектов и протоколировании этих вызовов. Регулярно делается чекпоинт — т.е. состояние базы скидывается на диск. Лог-записи старше этого момента считаются ненужными и подлежат перезаписи. При старте базы выполняется чтение сигнатуры чекпоинта, которому она соответствует, лог сканируется в поисках этого чекпоинта, и выполняется воспроизведение всех транзакций, для которых стоит метка "commited". Для небольших объемов (в пределах ~100 Mb) на современном железе это вполне нормально работает.
Можно сделать достаточно простой транзакционный механизм с версионностью на уровне страниц.
Т.к. запись привязана к странице можно сделать некий менеджер памяти, который хранит цепочку измененных страниц начиная с актуальной.
У каждой страницы есть свой ID транзакции (Int64 выше крыши), а так же ссылка на пишущую транзакцию.
Для упрощения можно создать два вида транзакции читающие и записывающую. Одновременно может выполняться только одна пишущая транзакция. Вбольшинтве случаях при проведении документов в которых изменяется большое количество регистров это оправдано.
Так пишущая транзакция считывает страницу актуальную или транзакционную (пишет только в транзакционную), а читающая в зависимости от ID транзакции.
При фиксации транзакции страницы записываются и страницы становяися актуальными.
Для возвращения страниц с ID транзакции меньшей чем самая ранняя читающая транзакция эти страницы можно возвращать БД, в потоку просматривающем все страницы.
При таком подходе проще вести лог, изменение индексов, архивировании БД итд.
А по скорости она будет мало уступать безтранзационной.
... << RSDN@Home 1.1.4 beta 4 rev. 303>>
и солнце б утром не вставало, когда бы не было меня
Re[19]: Объектно-ориентированные БД: основные принципы, орга
Здравствуйте, Serginio1, Вы писали:
S> Можно сделать достаточно простой транзакционный механизм с версионностью на уровне страниц. S> Т.к. запись привязана к странице можно сделать некий менеджер памяти, который хранит цепочку измененных страниц начиная с актуальной. S> У каждой страницы есть свой ID транзакции (Int64 выше крыши), а так же ссылка на пишущую транзакцию. S> Для упрощения можно создать два вида транзакции читающие и записывающую. Одновременно может выполняться только одна пишущая транзакция. Вбольшинтве случаях при проведении документов в которых изменяется большое количество регистров это оправдано. S> Так пишущая транзакция считывает страницу актуальную или транзакционную (пишет только в транзакционную), а читающая в зависимости от ID транзакции. S> При фиксации транзакции страницы записываются и страницы становяися актуальными. S> Для возвращения страниц с ID транзакции меньшей чем самая ранняя читающая транзакция эти страницы можно возвращать БД, в потоку просматривающем все страницы. S> При таком подходе проще вести лог, изменение индексов, архивировании БД итд. S> А по скорости она будет мало уступать безтранзационной.
Как я понял, смысл в том, что содержимое БД перезаписывается. Но, если при работе пишущей транзакции есть еще и читающие транзакции (которые начались раньше), то уже стартовавшие транзакции читают старое содержимое БД, в то время, пока пишущая транзакция записывает новое содержимое. Так?
Пара замечаний.
В таком подходе нужно будет выставлять какой-то маркер того, что транзакция зафиксирована полностью. Ведь если произойдет сбой при фиксации транзакции, то нужно будет как-то определить, что страницы с максимальным ID транзакции нужно проигнорировать. Но, если такой маркет будет, то при открытии БД нужно будет пройти по всей БД, и поднять все страницы, чтобы найти максимальный корректный ID транзакции.
Еще один подводный камень. Допустим, в БД есть страницы, которые принадлежат транзакциям с ID=4 и ID=5. Нет читающих транзакций. Начинается пишущая транзакция с ID=6. Постепенно она занимает все страницы с ID=4 и принимается за страницы с ID=5. И тут сбой. Страницам с ID=6 верить нельзя. Но кому тогда верить?
Идем далее. Ты утверждаешь о скорости этого решения на основании экспериментов?
А вообще механизм, при котором нет write-ahead-log, но измененные страницы сохраняются отдельно и как-бы растворяются в старом содержимом БД, является одним из классических способов обеспечения транзакционности. По крайней мере я о нем когда-то давно-давно читал. Но в нем есть один тонкий момент: нужно как-то гарантировать целостность цепочки актуальных страниц.
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[20]: Объектно-ориентированные БД: основные принципы, орга
Здравствуйте, eao197, Вы писали:
E>Здравствуйте, Serginio1, Вы писали:
S>> Можно сделать достаточно простой транзакционный механизм с версионностью на уровне страниц. S>> Т.к. запись привязана к странице можно сделать некий менеджер памяти, который хранит цепочку измененных страниц начиная с актуальной. S>> У каждой страницы есть свой ID транзакции (Int64 выше крыши), а так же ссылка на пишущую транзакцию. S>> Для упрощения можно создать два вида транзакции читающие и записывающую. Одновременно может выполняться только одна пишущая транзакция. Вбольшинтве случаях при проведении документов в которых изменяется большое количество регистров это оправдано. S>> Так пишущая транзакция считывает страницу актуальную или транзакционную (пишет только в транзакционную), а читающая в зависимости от ID транзакции. S>> При фиксации транзакции страницы записываются и страницы становяися актуальными. S>> Для возвращения страниц с ID транзакции меньшей чем самая ранняя читающая транзакция эти страницы можно возвращать БД, в потоку просматривающем все страницы. S>> При таком подходе проще вести лог, изменение индексов, архивировании БД итд. S>> А по скорости она будет мало уступать безтранзационной.
E>Как я понял, смысл в том, что содержимое БД перезаписывается. Но, если при работе пишущей транзакции есть еще и читающие транзакции (которые начались раньше), то уже стартовавшие транзакции читают старое содержимое БД, в то время, пока пишущая транзакция записывает новое содержимое. Так?
Да. E>Пара замечаний.
E>В таком подходе нужно будет выставлять какой-то маркер того, что транзакция зафиксирована полностью. Ведь если произойдет сбой при фиксации транзакции, то нужно будет как-то определить, что страницы с максимальным ID транзакции нужно проигнорировать. Но, если такой маркет будет, то при открытии БД нужно будет пройти по всей БД, и поднять все страницы, чтобы найти максимальный корректный ID транзакции.
E>Еще один подводный камень. Допустим, в БД есть страницы, которые принадлежат транзакциям с ID=4 и ID=5. Нет читающих транзакций. Начинается пишущая транзакция с ID=6. Постепенно она занимает все страницы с ID=4 и принимается за страницы с ID=5. И тут сбой. Страницам с ID=6 верить нельзя. Но кому тогда верить?
Нет все новые страницы записываются на новом месте. Страницы со старым ID нужны только для читающих транзакций.
При этом, транзакция должна вести свой лог, измененных страниц, по которой можно восстановить данные (откатить) E>Идем далее. Ты утверждаешь о скорости этого решения на основании экспериментов?
Если применть тотже механизм, что и в Re[11]: Объектно-ориентированные БД: основные принципы, орга
, но с кэшированием страниц то и по сути с отложенной записью страниц (на странице будет не одна измененная запись) то гдето будет близко к тому варианту. E>А вообще механизм, при котором нет write-ahead-log, но измененные страницы сохраняются отдельно и как-бы растворяются в старом содержимом БД, является одним из классических способов обеспечения транзакционности. По крайней мере я о нем когда-то давно-давно читал. Но в нем есть один тонкий момент: нужно как-то гарантировать целостность цепочки актуальных страниц.
У меня за цепочки отвечает отдельная таблица, но согласен это основное тонкое место.
... << RSDN@Home 1.1.4 beta 4 rev. 303>>
и солнце б утром не вставало, когда бы не было меня
Re[21]: Объектно-ориентированные БД: основные принципы, орга
Здравствуйте, Serginio1, Вы писали:
S>Здравствуйте, eao197, Вы писали:
E>>Еще один подводный камень. Допустим, в БД есть страницы, которые принадлежат транзакциям с ID=4 и ID=5. Нет читающих транзакций. Начинается пишущая транзакция с ID=6. Постепенно она занимает все страницы с ID=4 и принимается за страницы с ID=5. И тут сбой. Страницам с ID=6 верить нельзя. Но кому тогда верить?
S> Нет все новые страницы записываются на новом месте. Страницы со старым ID нужны только для читающих транзакций. S> При этом, транзакция должна вести свой лог, измененных страниц, по которой можно восстановить данные (откатить)
Так а зачем тогда лог? Обломилась транзакция, игнорируем ее страницы.
Проще где-то хранить ID последней успешно зафиксированной транзакции. И просто переиспользовать ID, которые больше этого значения.
E>>Идем далее. Ты утверждаешь о скорости этого решения на основании экспериментов? S> Если применть тотже механизм, что и в Re[11]: Объектно-ориентированные БД: основные принципы, орга
, но с кэшированием страниц то и по сути с отложенной записью страниц (на странице будет не одна измененная запись) то гдето будет близко к тому варианту.
Как раз, если ты не будешь переиспользовать уже устаревшие страницы, то производительность начнет деградировать, т.к. на каждый новый комит ОС придется расширять твой файл данных. А эта операция дороже, чем перезапись уже существующих страниц.
E>>А вообще механизм, при котором нет write-ahead-log, но измененные страницы сохраняются отдельно и как-бы растворяются в старом содержимом БД, является одним из классических способов обеспечения транзакционности. По крайней мере я о нем когда-то давно-давно читал. Но в нем есть один тонкий момент: нужно как-то гарантировать целостность цепочки актуальных страниц. S> У меня за цепочки отвечает отдельная таблица, но согласен это основное тонкое место.
Да, и ее придется защищать как-то по другому.
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[22]: Объектно-ориентированные БД: основные принципы, орга
S>> Нет все новые страницы записываются на новом месте. Страницы со старым ID нужны только для читающих транзакций. S>> При этом, транзакция должна вести свой лог, измененных страниц, по которой можно восстановить данные (откатить)
E>Так а зачем тогда лог? Обломилась транзакция, игнорируем ее страницы. E>Проще где-то хранить ID последней успешно зафиксированной транзакции. И просто переиспользовать ID, которые больше этого значения.
Лог нужен для отката, что бы не сканировать все страницы, лучше в памяти, а по поводу восстановления полностью согласен. E>>>Идем далее. Ты утверждаешь о скорости этого решения на основании экспериментов? S>> Если применть тотже механизм, что и в Re[11]: Объектно-ориентированные БД: основные принципы, орга
, но с кэшированием страниц то и по сути с отложенной записью страниц (на странице будет не одна измененная запись) то гдето будет близко к тому варианту.
E>Как раз, если ты не будешь переиспользовать уже устаревшие страницы, то производительность начнет деградировать, т.к. на каждый новый комит ОС придется расширять твой файл данных. А эта операция дороже, чем перезапись уже существующих страниц.
Ты немного не понял. Они возвращаются БД. Но я предполагаю эту операцию производить в бэкграунд потоке, т.к. читающие транзакции могут быть очень долгими, и возвращать все страницы с ID транзакции меньше наименьшей читающей транзакции, или оставлять только актуальные если таковых нет.
E>>>А вообще механизм, при котором нет write-ahead-log, но измененные страницы сохраняются отдельно и как-бы растворяются в старом содержимом БД, является одним из классических способов обеспечения транзакционности. По крайней мере я о нем когда-то давно-давно читал. Но в нем есть один тонкий момент: нужно как-то гарантировать целостность цепочки актуальных страниц. S>> У меня за цепочки отвечает отдельная таблица, но согласен это основное тонкое место.
E>Да, и ее придется защищать как-то по другому.
В любом случае это пока только фантазии
... << RSDN@Home 1.1.4 beta 4 rev. 303>>
и солнце б утром не вставало, когда бы не было меня
Re[23]: Объектно-ориентированные БД: основные принципы, орга
Здравствуйте, Serginio1, Вы писали:
S>Здравствуйте, eao197, Вы писали:
S>>> Нет все новые страницы записываются на новом месте. Страницы со старым ID нужны только для читающих транзакций. S>>> При этом, транзакция должна вести свой лог, измененных страниц, по которой можно восстановить данные (откатить)
E>>Так а зачем тогда лог? Обломилась транзакция, игнорируем ее страницы. E>>Проще где-то хранить ID последней успешно зафиксированной транзакции. И просто переиспользовать ID, которые больше этого значения. S> Лог нужен для отката, что бы не сканировать все страницы, лучше в памяти, а по поводу восстановления полностью согласен.
Тогда понятно. Я при откате просто кэш вычищаю и все.
E>>Как раз, если ты не будешь переиспользовать уже устаревшие страницы, то производительность начнет деградировать, т.к. на каждый новый комит ОС придется расширять твой файл данных. А эта операция дороже, чем перезапись уже существующих страниц. S> Ты немного не понял. Они возвращаются БД. Но я предполагаю эту операцию производить в бэкграунд потоке, т.к. читающие транзакции могут быть очень долгими, и возвращать все страницы с ID транзакции меньше наименьшей читающей транзакции, или оставлять только актуальные если таковых нет.
Мне кажется, что это ты меня немного не понял. Давай еще раз:
— есть страницы, которые принадлежат старым транзакциям с ID=4 и ID=5;
— последняя актуальная цепочка содержит страницы, которые принадлежат транзакции ID=5;
— читающих транзакций нет;
— начинается новая пишущая транзакция с ID=6;
— эта транзакция поглощает страницы с ID=4;
— если затем эта транзакция начнет поглощать страницы с ID=5, то при сбое окажется, что актуальные страницы с ID=5 потеряны.
Ведь так?
Поэтому тебе нужно будет ввести еще одно уточнение: нельзя забирать страницы последней актуальной транзакции. Даже если читающих транзакций не было.
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[24]: Объектно-ориентированные БД: основные принципы, орга
E>Мне кажется, что это ты меня немного не понял. Давай еще раз: E>- есть страницы, которые принадлежат старым транзакциям с ID=4 и ID=5; E>- последняя актуальная цепочка содержит страницы, которые принадлежат транзакции ID=5; E>- читающих транзакций нет; E>- начинается новая пишущая транзакция с ID=6; E>- эта транзакция поглощает страницы с ID=4; E>- если затем эта транзакция начнет поглощать страницы с ID=5, то при сбое окажется, что актуальные страницы с ID=5 потеряны.
E>Ведь так?
E>Поэтому тебе нужно будет ввести еще одно уточнение: нельзя забирать страницы последней актуальной транзакции. Даже если читающих транзакций не было.
Приблизительно так, страницы выдает БД, если страница не была ей отдана значит будет выделена новая или отдана из пустых страниц из цепочки свободных страниц.
Актуальная страница может быть отдана только после полной фиксации записывающей транзакции.
или Эдак http://gzip.rsdn.ru/article/db/yukonvers.xml#EHDA
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, GlebZ, Вы писали:
GZ>>Здравствуйте, Sinclair, Вы писали:
S>>>Здравствуйте, GlebZ, Вы писали: GZ>>>>Некоторая поправка — в большинстве своем гарантируется что поле(не блоб) умещается на страницу (MS SQL). S>>>Ну, в MS SQL гарантируется, что запись умещается на одной странице. Поля типа image, text, varchar(max) и прочий крупный тоннаж хранятся специальным способом. GZ>>Глянул BOL. Что-то стормозил . Твоя правда. Только varchar всегда — хранятся вместе с row. S>varchar(<const>) — да. Varchar(max) — нет. Читать здесь.
Спасибо, теперь понятно. Thanks за ссылку. Я в yukonе пока не дока. Не хватает времени хорошо его понять. S>Верно. Термин компактифицировать == shrink. Не нашел лучшего русского аналога. Не хотелось писать "пошринкать спейс надо тогда, когда гарбадж занимает больше 50% вольюма".
С уважением, Gleb.
Re[19]: Объектно-ориентированные БД: основные принципы, орга
Здравствуйте, Serginio1, Вы писали:
S>Можно сделать достаточно простой транзакционный механизм с версионностью на уровне страниц. S>Т.к. запись привязана к странице можно сделать некий менеджер памяти, который хранит цепочку измененных страниц начиная с актуальной. S>У каждой страницы есть свой ID транзакции (Int64 выше крыши), а так же ссылка на пишущую транзакцию. S>Для упрощения можно создать два вида транзакции читающие и записывающую. Одновременно может выполняться только одна пишущая транзакция. В большинтве случаях при проведении документов в которых изменяется большое количество регистров это оправдано. S>Так пишущая транзакция считывает страницу актуальную или транзакционную (пишет только в транзакционную), а читающая в зависимости от ID транзакции. S>При фиксации транзакции страницы записываются и страницы становяися актуальными. S>Для возвращения страниц с ID транзакции меньшей чем самая ранняя читающая транзакция эти страницы можно возвращать БД, в потоку просматривающем все страницы. S>При таком подходе проще вести лог, изменение индексов, архивировании БД итд. S>А по скорости она будет мало уступать безтранзационной.
Все, теперь понял что ты хотел сказать.
Некоторые замечания и предложения.
1. Индекс в любом случае придется делать. А индекс — это косвенная адресация. Возможно легче будет управлять через него. Особенно, в случае большого кол-ва страниц. Все-таки логарифмический или линейный доступ при большом кол-ве страниц значительно лучше. Кстати, ты примерно рассчитывал сколько для твоей бизнес задачи потребуется памяти для хранения указателей на страницы? От этого много зависит.
2. Вопрос с логгером. Проблема в отказе при сохранении таблицы указателей на страницы. Возможно стоит делать копии этих таблиц, и после этого сохранять номер последней транзакции. Это не даст 100%, но 99.9% я думаю будет достаточно. При восстановлении, брать нормальную таблицу и игнорировать остальные.
3. Возможно увеличение базы данных. Особенно, если я правильно понял, при долгой транзакции. Хотя при нынешних гигабайтах — может быть неактуально.
4. Возможна сильная дефрагментация. БД при чтении читают больше данных чем нужно. Вероятность того, что следующий запрос будет на следующий объект из той же таблицы — высока. Но обязательное условие то, что страницы с данными относящимися к одной таблице лежат в одном месте, чтобы не надо было переводить головку диска с дорожки на дорожку. Для этого нужно вводить систему экстентов.
5. Здесь невозможно переводить транзакцию из read only в пишущую. Также нельзя использовать данные из данной транзакции для записи в другой транзакции. Очень высока вероятность что прочитаны устаревшие данные. Получим несогласованные данные. Поэтому нужно явно или неявно ввести перечитывание данных.
6. После просмотра вариантов с индексами и откатом(п.1,2), я бы просмотрел возможность введения нескольких пишущих транзакций. Ничего криминального в данном механизме, для них не вижу.
С уважением, Gleb.
Re[27]: Объектно-ориентированные БД: основные принципы, орга
Здравствуйте, Cyberax, Вы писали:
C>Не знаю как вам, но для меня SQL в языке — бред.
Ничего не слышал о ESQL? Он существет и для С и для С++.
Лично для меня разумным является любое повышение контроля и увеличение удобства если при этом оно не видет к потере универсальности и качества. Так что если ребята из МС сделают это безшевно и не напряжно, то я буду рад.
C> Так как это скорее C>всего будет сделано в виде железной привязки к MSSQL (знаем мы этих C>МСников...).
Похоже "вы" их совсем не знаете. Они конечно интергрируют свои продукты, но при этом они всегда блюдут традиции универсальных АПИ. Думаю, что если поддержка БД будет встроена в Шарп, то она будет сделана на базе ADO.NET, а оный АПИ и сегодня неплохо поддерживает БД других производителей.
... << RSDN@Home 1.1.4 beta 3 rev. 279>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[28]: Объектно-ориентированные БД: основные принципы, орга
Здравствуйте, Sinclair, Вы писали:
S>Неа. Там все будет еще интереснее. Никакой привязки не произойдет — это все фичи языка, а не сервера. Прежде чем клеймить, почитай на микрософт ресерче про си-омегу.
Говорить о том как это будет пока что не решается даже сам Хегельберг (или как там его?).
Cw — это всего лишь иссплдовательский проект. Реализация в Шарпе может оказаться совсем иной.
... << RSDN@Home 1.1.4 beta 3 rev. 279>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[29]: Объектно-ориентированные БД: основные принципы, орга
Здравствуйте, Cyberax, Вы писали:
C>Гадость. В язык тянут прикладные вещи типа XML, вместо того, чтобы C>добавить средства, позволяющие реализовать то же самое, но в виде библиотек.
Э батенька. В иде библиотек это уже есть. Но тут возникает две проблемы:
1. С ними сложнее работать чем со встроенными возмжностями языка.
2. При реализации в виде внешней библиотеки невозможно обеспечить провекри типов на переходах между разными мирами. Проверки откладываются до рантмайма, что снижает надежность программы.
В принципе есть один выход из положения (чтобы и язык не расширять и проблем не иметь). Нужно создать мета-фрэймворк которые позволит дописывать такие фичи в виде мета-библиотек. По сути это будет такое же расширение компилятора, но его сможет сделать каждый смертаный, так как это будет делаться через специальный АПИ.
Почему ребяата из МС не идут по этому пути я незнаю. Возможно боятся резкого усложнения связанного с метапрогарммированием. А возможно недопетривают. Ну, да лучше каки-то возможности чем никаких. А метафрэймворк и и без них сделаем.
... << RSDN@Home 1.1.4 beta 3 rev. 279>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>Кстати, не просветишь о "политике партии" на этот счет? А то я встречал ANS>в Инете упоминания, что XPath не будет, а будет что-то другое, но ANS>подробно не разбирался. Отложилось в голове, что что-то меняется, но вот ANS> что и зачем?
А политика портии опка не известна. Есть только туманные рассуждения Хегельберга тут. И язык Cw являющийся исследовательской разработкой. Возможно что прототипом будте этот язык. А возможно, что нет. Но похоже что-то будет. Хотя все расплывчато.
В СиОмеге XPath остается наместе, но плотно интегрирвется с компиляторм. Его парсинг происходит во вермя компиляции и система типов XPath мапится на систему типов СиОмеги. Отсюда полная статическая типизация и контроль XSD в компайлтайме. Возможно так же подсветка синтаквииса, автозавершение и т.п.
... << RSDN@Home 1.1.4 beta 3 rev. 279>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[25]: Объектно-ориентированные БД: основные принципы, орга
Здравствуйте, GlebZ, Вы писали:
GZ>Во блин. Почему мне больше нравится OQL чем XPath.
Незнаю. Наверно тем, что тебе пофигу есть ли доступная реализаци или нет.
GZ>Не тем что он похож на SQL. Мне на это полностью начхать. XPath все-таки подразумевает дерево(для того и делался), а не произвольный граф.
А ХМЛ и есть дерево. Граф объектов тоже в общем-то дерево. По крайней мере для нас деревянных.
GZ>Например, напиши такой запрос: GZ>select a where a.f1=b.f1 and b.f1=c.f1 and c.f2=20 GZ>где никакие связи между a, b, и с нигде не отражены.
Вообще-то с этим особых проблем нет. Вопрос тольк в эффективности исполнения. Ну, да меня лично не трогую проблемы реляционных БД. У меня AST. Даже название говорит о дереве. И для этого XPath выше крыша. Если бы он не отрмозил и небыло бы проблем с перходм с системы типов XPath на систему типов дотнета, то я горя бы не знал.
... << RSDN@Home 1.1.4 beta 3 rev. 279>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[25]: Объектно-ориентированные БД: основные принципы, орга
Здравствуйте, eao197, Вы писали:
E>Потрясающая читабельность у обоих вариантов
Ды варианты эмулируют реляционные отношения в древесном языке запросв. А ты перейди к обрботке деревьев и сразу получишь обратную картину. XPath окажется лапочкой, а SQL жутчайшим уродом.
... << RSDN@Home 1.1.4 beta 3 rev. 279>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[27]: Объектно-ориентированные БД: основные принципы, орга
Здравствуйте, Serginio1, Вы писали: S> Можно сделать достаточно простой транзакционный механизм с версионностью на уровне страниц.
[пересказ механики ранних interbase поскипан]
Фишка в том, что не вполне ясна методика коммита, а также действия СУБД при восстановлении после сбоя. То, что ты рассказываешь, пока относится только к одновременному использованию. Или ты, как обычно, на какую-то свою тему уже съехал?
... << RSDN@Home 1.1.4 beta 4 rev. 347>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[19]: Объектно-ориентированные БД: основные принципы, орга
Пусть каждая транзакция фиксируется в новом файле с именем <TID>.dat, где TID -- это идентификатор транзакции. Например 00000000.dat, 00f45779.dat, ...
Когда БД открывается, ищутся файлы по регекспу "^[[:xdigit:]]{8}\.dat$". Из полученных имен выделяются все номера транзакций и определяется TIDmax -- максимальный номер транзакции. Транзакция с этим номером и будет актуальной. Все остальные файлы, в принципе, уже не нужны и могут быть удалены.
Когда стартует пишущая транзакция, она создает файл <TIDmax+1>.tmp, куда записывает свое содержимое. Если транзакция завершается успешно, то файл флушируется и закрывается. После чего переименовывается в <TIDmax+1>.dat. Т.о. появляется новая актуальная транзакция и новый TIDmax=TIDmax+1.
Если при этом существуют читающие транзакции, то они читают старое содержимое БД из .dat-файлов со старыми TID. Как только все читающие транзакции освобождают некий TIDi и TIDi!=TIDmax, то файл <TIDi>.dat может быть уничтожен.
Если пишущая транзакция откатывается, то просто удаляется <TIDmax+1>.tmp и TIDmax остается без изменения.
Если происходит сбой при записи <TIDmax+1>.tmp, то при последующем рестарте этот файл будет просто проигнорирован.
При таком подходе не потребуется вести и защищать цепочку актуальных страниц файла данных.
Более того, поскольку все новые файлы будут записываться последовательно, то ОС может (и будет) значительно оптимизировать такую запись.
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[30]: Объектно-ориентированные БД: основные принципы, орга
VladD2 пишет: > В принципе есть один выход из положения (чтобы и язык не расширять и > проблем не иметь). Нужно создать мета-фрэймворк которые позволит > дописывать такие фичи в виде мета-библиотек. По сути это будет такое же > расширение компилятора, но его сможет сделать каждый смертаный, так как > это будет делаться через специальный АПИ. > > Почему ребяата из МС не идут по этому пути я незнаю. Возможно боятся
Похожа, что будет слишком похоже на устаревший Smalltalk или поросший
мхом CLOS.
--
Andrei N.Sobchuck
JabberID: andreis@jabber.ru. ICQ UIN: 46466235.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, eao197, Вы писали:
E>>Потрясающая читабельность у обоих вариантов
VD>Ды варианты эмулируют реляционные отношения в древесном языке запросв. А ты перейди к обрботке деревьев и сразу получишь обратную картину. XPath окажется лапочкой, а SQL жутчайшим уродом.
SQL да. OQL нет. Хотя и по кол-ву символов проиграет XPath.
С уважением, Gleb.
Re[26]: Объектно-ориентированные БД: основные принципы, орга
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, eao197, Вы писали:
E>>Потрясающая читабельность у обоих вариантов
VD>Ды варианты эмулируют реляционные отношения в древесном языке запросв. А ты перейди к обрботке деревьев и сразу получишь обратную картину. XPath окажется лапочкой, а SQL жутчайшим уродом.
Да я вообще-то о том, что это мне Perl напоминает. Сколько раз не пытался начать его использовать, все равно через три дня забывал, чем @ от $ отличается
Да и вообще, это типа шутка была.
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[28]: Объектно-ориентированные БД: основные принципы, орга
GZ>Некоторые замечания и предложения. GZ>1. Индекс в любом случае придется делать. А индекс — это косвенная адресация. Возможно легче будет управлять через него. Особенно, в случае большого кол-ва страниц. Все-таки логарифмический или линейный доступ при большом кол-ве страниц значительно лучше. Кстати, ты примерно рассчитывал сколько для твоей бизнес задачи потребуется памяти для хранения указателей на страницы? От этого много зависит.
Ссылки на страницы (вернее на некую структуру состоящих их актуальных страниц, страниц поздних версий итд) хранятся в иерархическом массиве). В любом случае памяти она занимает в не так и много, хотя можно сделать и индекс (вернее иерархический массив) на диске, а в памяти хранить ввиде Хэш таблиц с подгрузкой по мере необходимости и высвобождении страниц при преодолении определенном лимита памяти.
Если БД занимает порядка 10 ГБ памяти по массив страниц будет порядка (30-60 МБ).
GZ>2. Вопрос с логгером. Проблема в отказе при сохранении таблицы указателей на страницы. Возможно стоит делать копии этих таблиц, и после этого сохранять номер последней транзакции. Это не даст 100%, но 99.9% я думаю будет достаточно. При восстановлении, брать нормальную таблицу и игнорировать остальные.
Согласен. GZ>3. Возможно увеличение базы данных. Особенно, если я правильно понял, при долгой транзакции. Хотя при нынешних гигабайтах — может быть неактуально.
Что бы набить 10 ГБ нужно сильно постараться. В любом случае нужно смотреть на предметную область, универсальных решений не бывает. GZ>4. Возможна сильная дефрагментация. БД при чтении читают больше данных чем нужно. Вероятность того, что следующий запрос будет на следующий объект из той же таблицы — высока. Но обязательное условие то, что страницы с данными относящимися к одной таблице лежат в одном месте, чтобы не надо было переводить головку диска с дорожки на дорожку. Для этого нужно вводить систему экстентов.
Все равно читается все страницами, а некий аналог дефрагментаци ты и так получишь если при выборке будешь использовать индес, где данные будут разбросаны как попало (если конечно этот индекс не клястерный) GZ>5. Здесь невозможно переводить транзакцию из read only в пишущую. Также нельзя использовать данные из данной транзакции для записи в другой транзакции. Очень высока вероятность что прочитаны устаревшие данные. Получим несогласованные данные. Поэтому нужно явно или неявно ввести перечитывание данных.
Пишущая транзакция есть и читающая и пишущая одновременно, просто при обращении к страницам она должна использоваь транзакционные, при чтении если их нет то считывать с актуальных, запись идет только на транзакционные. Поэтому пересчет в этой транзакции идет полный, в том числе и индексов. GZ>6. После просмотра вариантов с индексами и откатом(п.1,2), я бы просмотрел возможность введения нескольких пишущих транзакций. Ничего криминального в данном механизме, для них не вижу.
А я ох как их вижу. Небольшой пример. Ведем партийный учет, две транзакции списывают один и тот же товар, товара хватает а вот партий нет,
и как две незавершенные транзакции будут согласовываться ????
Кроме того при страничной версионности, баги могут возникать намного чаще чем при версионности записями. Но уверяю, что скорости хватит на все пишущие транзакции (народ ждет и поболее
В любом случае это только декларация о намерениях и большое спасибо за участие в обсуждении.
... << RSDN@Home 1.1.4 beta 4 rev. 303>>
и солнце б утром не вставало, когда бы не было меня
Re[20]: Объектно-ориентированные БД: основные принципы, орга
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Serginio1, Вы писали: S>> Можно сделать достаточно простой транзакционный механизм с версионностью на уровне страниц. S>[пересказ механики ранних interbase поскипан]
Ну вот видишь как полезно изобретать велосипед S>Фишка в том, что не вполне ясна методика коммита, а также действия СУБД при восстановлении после сбоя. То, что ты рассказываешь, пока относится только к одновременному использованию. Или ты, как обычно, на какую-то свою тему уже съехал?
Одновременной записи, но неограниченном чтении, (хотя и писателей можно сделать больше но проблем намнооого больше).
При комите идет корректировка ссылок на новые страницы и цепочку версионных страниц в таблице отвечающую за цепочку страниц.
С сохранением старых страниц для отката, при запуске.
... << RSDN@Home 1.1.4 beta 4 rev. 303>>
и солнце б утром не вставало, когда бы не было меня
Re[29]: Объектно-ориентированные БД: основные принципы, орга
Здравствуйте, VladD2, Вы писали:
VD>Говорить о том как это будет пока что не решается даже сам Хегельберг (или как там его?).
Судя по тому, что он дотчанин (не изучал оного) Но скандинавы ближе к немецкому то скрее Хэйлсберг или Хайлсберг
... << RSDN@Home 1.1.4 beta 4 rev. 303>>
и солнце б утром не вставало, когда бы не было меня
Re[28]: Объектно-ориентированные БД: основные принципы, орга
VladD2 пишет:
> C>Не знаю как вам, но для меня SQL в языке — бред. > Ничего не слышал о ESQL? Он существет и для С и для С++.
Я слышал и об sqlj, даже работал с ним. Моего мнения это не меняет.
> Лично для меня разумным является любое повышение контроля и увеличение > удобства если при этом оно не видет к потере универсальности и > качества. Так что если ребята из МС сделают это безшевно и не > напряжно, то я буду рад.
А мне вот хочется, чтобы еще и 3D графику в язык интегрировали. Чем она
хуже SQL?
> C> Так как это скорее всего будет сделано в виде железной привязки к > MSSQL (знаем мы этих > C>МСников...). > Похоже "вы" их совсем не знаете. Они конечно интергрируют свои > продукты, но при этом они всегда блюдут традиции универсальных АПИ.
POSIX они, например, очень классно поддерживают. С WS та же история.
> Думаю, что если поддержка БД будет встроена в Шарп, то она будет > сделана на базе ADO.NET, а оный АПИ и сегодня неплохо поддерживает БД > других производителей.
Но при этом это все будет заточено под MSSQL
--
С уважением,
Alex Besogonov (alexy@izh.com)
Posted via RSDN NNTP Server 1.9
Sapienti sat!
Re[30]: Объектно-ориентированные БД: основные принципы, орга
VladD2 пишет:
> C>Гадость. В язык тянут прикладные вещи типа XML, вместо того, чтобы > C>добавить средства, позволяющие реализовать то же самое, но в виде > библиотек. > Э батенька. В иде библиотек это уже есть. Но тут возникает две проблемы: > 1. С ними сложнее работать чем со встроенными возмжностями языка.
Не всегда. Кроме того, у этого подхода есть недостатки — библиотеку я
могу расширить или выбросить и взять другую, а с языком такие штучки не
получатся.
> 2. При реализации в виде внешней библиотеки невозможно обеспечить > провекри типов на переходах между разными мирами. Проверки > откладываются до рантмайма, что снижает надежность программы.
Это смотря какие библиотеки и смотря на каком языке. Да и generic'и уже
не за горами.
> В принципе есть один выход из положения (чтобы и язык не расширять и > проблем не иметь). Нужно создать мета-фрэймворк которые позволит > дописывать такие фичи в виде мета-библиотек. По сути это будет такое > же расширение компилятора, но его сможет сделать каждый смертаный, так > как это будет делаться через специальный АПИ.
Это пол-года назад в fido7.su.softw обсуждалось. Называется DSL (Domain
Specific Language), сейчас JetBrains (создатель IDEA) активно в этом
направлении копает. Мне эта идея не особо нравится (слишком много
возможностей для abuse), но я признаю, что иногда такой подход может
быть полезным.
--
С уважением,
Alex Besogonov (alexy@izh.com)
Posted via RSDN NNTP Server 1.9
Sapienti sat!
Re[24]: Объектно-ориентированные БД: основные принципы, орга
VladD2 пишет:
> GZ>Не тем что он похож на SQL. Мне на это полностью начхать. XPath > все-таки подразумевает дерево(для того и делался), а не произвольный граф. > А ХМЛ и есть дерево. Граф объектов тоже в общем-то дерево. По крайней > мере для нас деревянных.
Граф — это, вообще говоря, более широкое понятие, чем дерево. В
частности, дерево не допускает циклов и любой узел достижим из вершины.
--
С уважением,
Alex Besogonov (alexy@izh.com)
Posted via RSDN NNTP Server 1.9
Sapienti sat!
Re[29]: Объектно-ориентированные БД: основные принципы, орга
Здравствуйте, eao197, Вы писали:
E>Да я вообще-то о том, что это мне Perl напоминает. Сколько раз не пытался начать его использовать, все равно через три дня забывал, чем @ от $ отличается E>Да и вообще, это типа шутка была.
Ну, в XPath "@"- это просто сокращенная форма записи от "attribute::". То есть b[@f=10] это всеравно, что b[attribute::f=10]. Так что, если не нравится символ "@", то его можно и не использовать
... << RSDN@Home 1.1.4 @@subversion >>
лэт ми спик фром май харт
Re[31]: Объектно-ориентированные БД: основные принципы, орга
Здравствуйте, Cyberax, Вы писали:
C>Не всегда. Кроме того, у этого подхода есть недостатки — библиотеку я C>могу расширить или выбросить и взять другую, а с языком такие штучки не C>получатся.
Встраивая поддрежку паттерна в язык разработчики этого языка обычно довольно глубоко продумывают что и как делать. В противном случае они просто угробят язык. А необходимость обратной совместимости не даст исправить ошибку в дальнейшем. Все это праткически гарантирует высокое качество реализации. Ну, а то что появляется стандарт на реализацию и изображение паттерна — это очень хорошо. И людям будет проще код читать/писать и разным средсвам анализа кода.
C>Это смотря какие библиотеки и смотря на каком языке. Да и generic'и уже C>не за горами.
Дженерики тут к сожалению никак не помогу. Единственное что тут помогло бы — это средства метапрограммирования. Тут именно проблема динамического перехода между двумя системами типов.
>> В принципе есть один выход из положения (чтобы и язык не расширять и >> проблем не иметь). Нужно создать мета-фрэймворк которые позволит >> дописывать такие фичи в виде мета-библиотек. По сути это будет такое >> же расширение компилятора, но его сможет сделать каждый смертаный, так >> как это будет делаться через специальный АПИ.
C>Это пол-года назад в fido7.su.softw обсуждалось. Называется DSL (Domain C>Specific Language), сейчас JetBrains (создатель IDEA) активно в этом C>направлении копает. Мне эта идея не особо нравится (слишком много C>возможностей для abuse), но я признаю, что иногда такой подход может C>быть полезным.
Гы. Это лет 30 разад обсуждалось и к DSL — это никакого отношения не имеет. DSL тоже интересно решение, но оно как бы параллельно метапрограммированию. Метапрограммирование может оказаться хорошим средством реализации DSL-проектов. Но обратное не врено. Метапрограммирование расширяет возможности конкретного языка. А DSL создает новый язык который как не крути прийдется мапить на обычные языки программирования. Вот такой мап и можно упростить с помощью метапрограммирования.
... << RSDN@Home 1.1.4 beta 3 rev. 279>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[29]: Объектно-ориентированные БД: основные принципы, орга
Здравствуйте, eao197, Вы писали:
E>Да я вообще-то о том, что это мне Perl напоминает. Сколько раз не пытался начать его использовать, все равно через три дня забывал, чем @ от $ отличается E>Да и вообще, это типа шутка была.
Вот так тебе понятнее:
//class[attribute::Name == 'MyClass']
?
Чтобы стало понятнее:
// — означает искать во всех подветках начиная от корня.
[] — задает фильтр.
attribute:: — (тоже самео что и @) говорит что просходит обращение к атрибуту (свойству), а не элементу (тегу, классу).
... << RSDN@Home 1.1.4 beta 3 rev. 279>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[25]: Объектно-ориентированные БД: основные принципы, орга
Здравствуйте, Cyberax, Вы писали:
C>Граф — это, вообще говоря, более широкое понятие, чем дерево. В C>частности, дерево не допускает циклов и любой узел достижим из вершины.
Думаешь, тут кто-то не занает этого? Вот только граф можно представить как основное дерево и как бы не очень важные связи между ветками. Такое представление для человеческого мозка более приемлемо.
... << RSDN@Home 1.1.4 beta 3 rev. 279>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[26]: Объектно-ориентированные БД: основные принципы, орга
VladD2,
> C> Граф — это, вообще говоря, более широкое понятие, чем дерево. В частности, дерево не допускает циклов и любой узел достижим из вершины.
> Думаешь, тут кто-то не занает этого? Вот только граф можно представить как основное дерево и как бы не очень важные связи между ветками.
1) Дерево остовное. 2) Не всегда получится. И лесом не всегда выйдет, не только деревом. 3) Даже когда можно, это не всегда имеет смысл с точки зрения прикладной задачи.
> Такое представление для человеческого мозка более приемлемо.
Это сильно зависит от ТТХ.
Posted via RSDN NNTP Server 1.9
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Re[27]: Объектно-ориентированные БД: основные принципы, орга
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>1) Дерево остовное. 2) Не всегда получится. И лесом не всегда выйдет, не только деревом. 3) Даже когда можно, это не всегда имеет смысл с точки зрения прикладной задачи.
Не всегда. Во только в то области где в основном применяются ХМЛ и БД древовидное представление всегда рулит. Да ООП тоже к деревья наовит строить. А раз мы пишем код на ООЯ, то и данные хорошо бы иметь ОО. Основаня проблема связи РСУБД с ООЯ — это как раз превращение реляции в деревья.
Еще раз поворюсь. Человек пытается выделить дерево там где на него даже и намека может не быть. И именно потому, что ему удобнее мыслить таким образом. Ну, проще дерево в голове укладывается нежели граф. И алгоритмы обработки проще.
>> Такое представление для человеческого мозка более приемлемо.
ПК>Это сильно зависит от ТТХ.
Мозга?
... << RSDN@Home 1.1.4 beta 3 rev. 279>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[28]: Объектно-ориентированные БД: основные принципы, орга
VladD2 пишет:
> C>Не всегда. Кроме того, у этого подхода есть недостатки — библиотеку я > C>могу расширить или выбросить и взять другую, а с языком такие штучки не > C>получатся. > Встраивая поддрежку паттерна в язык разработчики этого языка обычно > довольно глубоко продумывают что и как делать. В противном случае они > просто угробят язык. А необходимость обратной совместимости не даст > исправить ошибку в дальнейшем. Все это праткически гарантирует высокое > качество реализации. Ну, а то что появляется стандарт на реализацию и > изображение паттерна — это очень хорошо. И людям будет проще код > читать/писать и разным средсвам анализа кода.
Это мы уже проходили на примере С++. Там в язык добавили столько
средств, что сейчас в полной мере все возможности С++ не знает и
Страуструп, наверное. Причем обычно создателям не удается просмотреть
все взаимные влияния фич на этапе их добавления, и недостатки выявляются
уже во время использования. Так было с С++ным bool'ом, например.
> C>Это смотря какие библиотеки и смотря на каком языке. Да и generic'и уже > C>не за горами. > Дженерики тут к сожалению никак не помогу. Единственное что тут > помогло бы — это средства метапрограммирования. Тут именно проблема > динамического перехода между двумя системами типов.
НЕЛЬЗЯ сделать язык, система типов которого будет совместима со всем,
чем только можно. Лучше бы создателям С# это понять, а не пытаться
адаптировать систему типов под SQL, XML и т.п. А если завтра придет
кому-нибудь в голову поддержку ASN1 добавить?
> C>Это пол-года назад в fido7.su.softw обсуждалось. Называется DSL (Domain > C>Specific Language), сейчас JetBrains (создатель IDEA) активно в этом > C>направлении копает. Мне эта идея не особо нравится (слишком много > C>возможностей для abuse), но я признаю, что иногда такой подход может > C>быть полезным. > Гы. Это лет 30 разад обсуждалось и к DSL — это никакого отношения не > имеет. DSL тоже интересно решение, но оно как бы параллельно > метапрограммированию.
Я считаю их практически очень близкими понятиями.
> Метапрограммирование может оказаться хорошим средством реализации > DSL-проектов. Но обратное не врено. Метапрограммирование расширяет > возможности конкретного языка. А DSL создает новый язык который как не > крути прийдется мапить на обычные языки программирования. Вот такой > мап и можно упростить с помощью метапрограммирования.
Как ни крути, а возможности для abuse'а у метапрограммирования слишком
большие.
--
С уважением,
Alex Besogonov (alexy@izh.com)
Posted via RSDN NNTP Server 1.9
Sapienti sat!
Re[30]: Объектно-ориентированные БД: основные принципы, орга
VladD2 пишет:
> C>А мне вот хочется, чтобы еще и 3D графику в язык интегрировали. Чем она > C>хуже SQL? > Тем что это не язык.
Почему? Берем матрицы, векторы (можно еще и тензоры ), добавляем их в
язык. Затем добавляем в язык геометрические тела в виде примитивов и
операции над ними в виде примитивных операций.
> А то что можно уже интегрировали. Про Cg слыхал?
Ну так и sqlj тоже есть давно для SQL. А я вот хочу в 3D-графику в C#!
> C>Но при этом это все будет заточено под MSSQL > Это твои домыслы.
Я помню что произошло с COM'ом (точнее с OLE). МС кричала, что это будет
кроссплатформенная кроссязыковая технология, для любого языка
программирования и т.п. А получилось, что OLE по странному совпадению
лучше подходит для VisualBasic'а.
--
С уважением,
Alex Besogonov (alexy@izh.com)
Posted via RSDN NNTP Server 1.9
Sapienti sat!
Re[26]: Объектно-ориентированные БД: основные принципы, орга
VladD2 пишет:
> C>Граф — это, вообще говоря, более широкое понятие, чем дерево. В > C>частности, дерево не допускает циклов и любой узел достижим из вершины. > Думаешь, тут кто-то не занает этого? Вот только граф можно представить > как основное дерево и как бы не очень важные связи между ветками. > Такое представление для человеческого мозка более приемлемо.
Здравствуйте, Cyberax, Вы писали:
C>Это мы уже проходили на примере С++. Там в язык добавили столько C>средств, что сейчас в полной мере все возможности С++ не знает и C>Страуструп, наверное.
Кстати, глубокое заблуждение. С++ проктически ничерта не имеет. Тут Шарп его еще в первой версии делал. У плюсов в другом проблема. Из-за непродуманности и борьбе за совместимость с С каждая фигня в С++ имеет тучу нюансов. Из-за этого геморрой порой возникает на ровном месте.
C> Причем обычно создателям не удается просмотреть C>все взаимные влияния фич на этапе их добавления, и недостатки выявляются C>уже во время использования. Так было с С++ным bool'ом, например.
Полно те. Сколько тех изменений в нем было?
C>НЕЛЬЗЯ сделать язык, система типов которого будет совместима со всем, C>чем только можно. Лучше бы создателям С# это понять, а не пытаться C>адаптировать систему типов под SQL, XML и т.п.
Не боись. Они явно не тупее нас с тобой.
C> А если завтра придет C>кому-нибудь в голову поддержку ASN1 добавить?
Да, да. И когда заходишь в помещение, то нужно становиться по дальше от люстры. А то не дай бог землятресение...
C>Я считаю их практически очень близкими понятиями.
И ошибашся. Подходы довольно разные.
... << RSDN@Home 1.1.4 beta 4 rev. 351>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[31]: Объектно-ориентированные БД: основные принципы, орга
Здравствуйте, Cyberax, Вы писали:
C>Почему? Берем матрицы, векторы (можно еще и тензоры ), добавляем их в C>язык. Затем добавляем в язык геометрические тела в виде примитивов и C>операции над ними в виде примитивных операций.
И что это даст? Они и в виде классов вписываются в концепции языка очень хорошо.
C>Ну так и sqlj тоже есть давно для SQL. А я вот хочу в 3D-графику в C#!
Я думаю, что в данном случае речь идет о совсем других понятиях нежеле sqlj. В том же Cw ребята вводят такие фичи из ФЯ как кортежи. Например, одной из проблем при работе с SQL-ем является то, что невозможно возвращать типизированные наботы данных. Обязательно будет приведение. А с кортежами все решается на раз. Ну, а если синтаксис запроса можно будет проверить во время компиляции...
В общем, главно, чтобы эти фичи не мешали остальным возможностям языка.
C>Я помню что произошло с COM'ом (точнее с OLE). МС кричала, что это будет C>кроссплатформенная кроссязыковая технология, для любого языка C>программирования и т.п.
Так оно и вышло.
C> А получилось, что OLE по странному совпадению C>лучше подходит для VisualBasic'а.
Дельфи тоже был ничем не хуже. Это как раз и есть встраивание в язык. Забавно, что и Дельфи и Васик с успехом пережили КОМ.
... << RSDN@Home 1.1.4 beta 4 rev. 351>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[27]: Объектно-ориентированные БД: основные принципы, орга
Здравствуйте, Cyberax, Вы писали:
C>Через неделю тестов мне OGNL стал нравится намного больше, чем JXPath, C>как раз из-за ориентации на _графы_ объектов без явной иерархии.
Что я могу сказать? Мне хватает ХПаза. Мне бы скорость по выше. Так как задачи слишьком объемные.
... << RSDN@Home 1.1.4 beta 4 rev. 351>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[12]: Объектно-ориентированные БД: основные принципы, орга
VladD2 пишет:
> C>Это мы уже проходили на примере С++. Там в язык добавили столько > C>средств, что сейчас в полной мере все возможности С++ не знает и > C>Страуструп, наверное. > Кстати, глубокое заблуждение. С++ проктически ничерта не имеет.
Это только кажется. С помощью шаблонов в С++ делается: сериализация,
reflection и даже можно сделать небольшой встроенный функциональный язык:
Это пример из Boost.Spirit.Phoenix.
> Тут Шарп его еще в первой версии делал. У плюсов в другом проблема. > Из-за непродуманности и борьбе за совместимость с С каждая фигня в С++ > имеет тучу нюансов. Из-за этого геморрой порой возникает на ровном месте.
Просто в С++ фичи немного другую направленность имеют, чем в С#.
> C> Причем обычно создателям не удается просмотреть > C>все взаимные влияния фич на этапе их добавления, и недостатки > выявляются > C>уже во время использования. Так было с С++ным bool'ом, например. > Полно те. Сколько тех изменений в нем было?
Много. Еще были: исключения, автоматические cast'ы, выведение типов и т.п.
> C>НЕЛЬЗЯ сделать язык, система типов которого будет совместима со всем, > C>чем только можно. Лучше бы создателям С# это понять, а не пытаться > C>адаптировать систему типов под SQL, XML и т.п. > Не боись. Они явно не тупее нас с тобой.
После WinForms я начинаю в этом сомневаться...
--
С уважением,
Alex Besogonov (alexy@izh.com)
Posted via RSDN NNTP Server 1.9
Sapienti sat!
Re[35]: Объектно-ориентированные БД: основные принципы, орга
Здравствуйте, Cyberax, Вы писали:
C>VladD2 пишет:
>> C>Это мы уже проходили на примере С++. Там в язык добавили столько >> C>средств, что сейчас в полной мере все возможности С++ не знает и >> C>Страуструп, наверное. >> Кстати, глубокое заблуждение. С++ проктически ничерта не имеет.
C>С помощью шаблонов в С++ делается: сериализация, C>reflection
Это только кажется. (с)
C>и даже можно сделать небольшой встроенный функциональный язык:
Надеюсь ты понимашь насколько проще данный пример будет выглядеть на функциональном языке или даже на C#? Ну, а теперь попытайся расширить своей пример разрешив задавать параметр с консоли.
C>Просто в С++ фичи немного другую направленность имеют, чем в С#.
Просто их в С++ нет. Их нужно постоянно эмулировать. Иногда это проходит гладко, а иногда выливается в поистене юмористические сложности для решения примитивных задач.
Вот, например, сколько нужно написать кода чтобы выяснить длинну статически инициализированного массива:
int a[] = { 1, 3, 4 };
? И сколько компилятор будет обдумывать каждый такой изыск?
C>После WinForms я начинаю в этом сомневаться...
И чем не угодила эта баблиотека? Слишком просто использовать?
... << RSDN@Home 1.1.4 beta 4 rev. 351>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[36]: Объектно-ориентированные БД: основные принципы, орга
VladD2 пишет:
> C>С помощью шаблонов в С++ делается: сериализация, > C>reflection > Это только кажется. (с)
Что кажется? Сериализацию я вот прямо сейчас использую.
> C>и даже можно сделать небольшой встроенный функциональный язык: > Надеюсь ты понимашь насколько проще данный пример будет выглядеть на > функциональном языке или даже на C#? Ну, а теперь попытайся расширить > своей пример разрешив задавать параметр с консоли.
На C# проще не будет — тут получается именно функциональный язык с
ленивым выполнением. Почти Хаскель А чтение с консоли сделать просто
— заменить, например "cout << arg1" на "cin >> arg1".
> C>Просто в С++ фичи немного другую направленность имеют, чем в С#. > Просто их в С++ нет. Их нужно постоянно эмулировать. Иногда это > проходит гладко, а иногда выливается в поистене юмористические > сложности для решения примитивных задач.
Есть. Шаблонное метапрограммирование — очень мощная техника.
> Вот, например, сколько нужно написать кода чтобы выяснить длинну > статически инициализированного массива: > >int a[] = { 1, 3, 4 }; > > ? И сколько компилятор будет обдумывать каждый такой изыск?
sizeof(a) не катит? Компилируется в константу.
> C>После WinForms я начинаю в этом сомневаться... > И чем не угодила эта баблиотека? Слишком просто использовать?
Там СТОЛЬКО всего, что мне не нравится, что я даже говорить не буду
--
С уважением,
Alex Besogonov (alexy@izh.com)
Posted via RSDN NNTP Server 1.9
Sapienti sat!
Re[28]: Объектно-ориентированные БД: основные принципы, орга
VladD2 пишет:
> C>Через неделю тестов мне OGNL стал нравится намного больше, чем JXPath, > C>как раз из-за ориентации на _графы_ объектов без явной иерархии. > Что я могу сказать? Мне хватает ХПаза. Мне бы скорость по выше. Так > как задачи слишьком объемные.
Повезло, значит.
Кстати, еще один аргумент против введения XPath'а и SQL в язык — а
почему именно ИХ в язык добавлять?
--
С уважением,
Alex Besogonov (alexy@izh.com)
Posted via RSDN NNTP Server 1.9
Sapienti sat!
Re[32]: Объектно-ориентированные БД: основные принципы, орга
VladD2 пишет:
> C>Почему? Берем матрицы, векторы (можно еще и тензоры ), добавляем их в > C>язык. Затем добавляем в язык геометрические тела в виде примитивов и > C>операции над ними в виде примитивных операций. > И что это даст? Они и в виде классов вписываются в концепции языка > очень хорошо.
Ну так и SQL тоже.
> C>Ну так и sqlj тоже есть давно для SQL. А я вот хочу в 3D-графику в C#! > Я думаю, что в данном случае речь идет о совсем других понятиях нежеле > sqlj. В том же Cw ребята вводят такие фичи из ФЯ как кортежи. > Например, одной из проблем при работе с SQL-ем является то, что > невозможно возвращать типизированные наботы данных. Обязательно будет > приведение. А с кортежами все решается на раз. Ну, а если синтаксис > запроса можно будет проверить во время компиляции...
Все красиво на бумаге, да забыли про овраги...
Вот, например, Firebird поддерживает домены значений — я там могу на тип
поставить ограничение, что он принимает значения от -1 до 1. Аналога
доменов в Cw нет — как мапить их будем? Далее, статическая проверка SQL
потребует наличие схемы базы данных и DB-specific-драйвера при
компиляции исходника — а это выглядит слегка странно. Про различные
поведения типов в разных БД я уже вообще молчу.
Ну и что самое главное — сейчас многие УЖЕ используют OR-mapping решения
и УЖЕ имеют типизированные объектные средства работы с базой. Зачем еще
чего-то добавлять в язык?
> C>Я помню что произошло с COM'ом (точнее с OLE). МС кричала, что это > будет > C>кроссплатформенная кроссязыковая технология, для любого языка > C>программирования и т.п. > Так оно и вышло.
Кроссплатформенности нормальной нет, только.
> C> А получилось, что OLE по странному совпадению > C>лучше подходит для VisualBasic'а. > Дельфи тоже был ничем не хуже. Это как раз и есть встраивание в язык. > Забавно, что и Дельфи и Васик с успехом пережили КОМ.
Дельфи в этом не сильно отличается от VB. А вот в С++ идеология
IDispatch вообще не вписывается, например.
--
С уважением,
Alex Besogonov (alexy@izh.com)
Posted via RSDN NNTP Server 1.9
Sapienti sat!
Re[30]: Объектно-ориентированные БД: основные принципы, орга
Здравствуйте, prVovik, Вы писали:
V>Здравствуйте, eao197, Вы писали:
E>>А как будет выглядеть запрос в XPath, если XML выглядит так (идея в том, что b -- это ссылки на другие объекты): E>>
E>><some-root>
E>><a f="10">
E>> <b ref="#0001" />
E>> <b ref="#0002" />
E>></a>
E>><b id="0001" f="15" />
E>><b id="0002" f="20" >
E>> <c f="25" />
E>> <c f="30" >
E>> <d f="40" /> <!-- значение атрибута f этого узла и надо получить -->
E>> </c>
E>></b>
E>></some-root>
E>>
V>
/b[ /a[@f=10]/b/@ref=@id and @f=20 ]/c[ f=30 ]/d/@f
Вероятно я не совсем точно выразился. Нужно было найти такой узел a/b, который ссылается на соседний b, у которого b.f == 20 && b/c.f == 30 && b/c/d.f == 40.
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[31]: Объектно-ориентированные БД: основные принципы, орга
Здравствуйте, eao197, Вы писали:
E>>>А как будет выглядеть запрос в XPath, если XML выглядит так (идея в том, что b -- это ссылки на другие объекты): E>>>
E>>><some-root>
E>>><a f="10">
E>>> <b ref="#0001" />
E>>> <b ref="#0002" />
E>>></a>
E>>><b id="0001" f="15" />
E>>><b id="0002" f="20" >
E>>> <c f="25" />
E>>> <c f="30" >
E>>> <d f="40" /> <!-- значение атрибута f этого узла и надо получить -->
E>>> </c>
E>>></b>
E>>></some-root>
E>>>
V>>
/b[ /a[@f=10]/b/@ref=@id and @f=20 ]/c[ f=30 ]/d/@f
E>Вероятно я не совсем точно выразился. Нужно было найти такой узел a/b, который ссылается на соседний b, у которого b.f == 20 && b/c.f == 30 && b/c/d.f == 40.
/a/b[ @ref=/b[ @f=20 and c[@f=30]/d[@f=40] ]/@id ]
... << RSDN@Home 1.1.4 @@subversion >>
лэт ми спик фром май харт
Re[33]: Объектно-ориентированные БД: основные принципы, орга
Здравствуйте, Cyberax, Вы писали: C>VladD2 пишет: >> C>Почему? Берем матрицы, векторы (можно еще и тензоры ), добавляем их в >> C>язык. Затем добавляем в язык геометрические тела в виде примитивов и >> C>операции над ними в виде примитивных операций. >> И что это даст? Они и в виде классов вписываются в концепции языка >> очень хорошо. C>Ну так и SQL тоже.
В SQL синтаксис есть, например, который компилятор проверить может. Так же есть описание того, как база данных устроена, по каким правилам "живёт". Значит и семантику проверить можно. А в графике чем он жизнь упростит?
>> C>Ну так и sqlj тоже есть давно для SQL. А я вот хочу в 3D-графику в C#! >> Я думаю, что в данном случае речь идет о совсем других понятиях нежеле >> sqlj. В том же Cw ребята вводят такие фичи из ФЯ как кортежи. >> Например, одной из проблем при работе с SQL-ем является то, что >> невозможно возвращать типизированные наботы данных. Обязательно будет >> приведение. А с кортежами все решается на раз. Ну, а если синтаксис >> запроса можно будет проверить во время компиляции... C>Все красиво на бумаге, да забыли про овраги... C>Вот, например, Firebird поддерживает домены значений — я там могу на тип C>поставить ограничение, что он принимает значения от -1 до 1. Аналога C>доменов в Cw нет — как мапить их будем?
Тип данных от этого не меняется. Что произойдёт, если в такое поле двойку попытаться записать? Если он её к ближайшей стенке (к 1) приведёт и запишет 1, то да, это надо будет учесть, аттрибут какой-нить выдумать . А если Firebird при этом только сообщает об ошибке, то это равнозначно и ошибке в рантайме.
C>Далее, статическая проверка SQL C>потребует наличие схемы базы данных и DB-specific-драйвера при C>компиляции исходника — а это выглядит слегка странно.
Что именно в этом "странно"?
C>Про различные поведения типов в разных БД я уже вообще молчу.
Да к любому можно найти подход ...
C>Ну и что самое главное — сейчас многие УЖЕ используют OR-mapping решения C>и УЖЕ имеют типизированные объектные средства работы с базой. Зачем еще C>чего-то добавлять в язык?
Избавить от бесконечных проверок типов разработчиков ОРМ и повысить тем самым надёжность их продукции.
>> C>Я помню что произошло с COM'ом (точнее с OLE). МС кричала, что это >> будет >> C>кроссплатформенная кроссязыковая технология, для любого языка >> C>программирования и т.п. >> Так оно и вышло. C>Кроссплатформенности нормальной нет, только.
В чём именно? Её может не поддерживать код, реализующий объект. А OLE — это ж только описание
>> C> А получилось, что OLE по странному совпадению >> C>лучше подходит для VisualBasic'а. >> Дельфи тоже был ничем не хуже. Это как раз и есть встраивание в язык. >> Забавно, что и Дельфи и Васик с успехом пережили КОМ. C>Дельфи в этом не сильно отличается от VB. А вот в С++ идеология C>IDispatch вообще не вписывается, например.
Коряво выглядит? Да. Но разве IDispatch как раз не для бэйсика- и js- подобных языков задумывался?
Ultra playing "Roxette — Neverending Love [Frank Mono 7" mix]"
<< RSDN@Home 1.1.4 beta 4 rev. 0 >>
Help will always be given at Hogwarts to those who ask for it.
Re[34]: Объектно-ориентированные БД: основные принципы, орга
_FRED_ пишет:
>>> И что это даст? Они и в виде классов вписываются в концепции языка >>> очень хорошо. > C>Ну так и SQL тоже. > В SQL синтаксис есть, например, который компилятор проверить может.
А в 3D компилятор мне не сможет проверить, что у меня матрица не
сингулярная.
> Так же есть описание того, как база данных устроена, по каким правилам > "живёт". Значит и семантику проверить можно. А в графике чем он жизнь > упростит?
В графике есть, например, языки шейдеров.
> C>Все красиво на бумаге, да забыли про овраги... > C>Вот, например, Firebird поддерживает домены значений — я там могу на > тип > C>поставить ограничение, что он принимает значения от -1 до 1. Аналога > C>доменов в Cw нет — как мапить их будем? > Тип данных от этого не меняется. Что произойдёт, если в такое поле > двойку попытаться записать? Если он её к ближайшей стенке (к 1) > приведёт и запишет 1, то да, это надо будет учесть, аттрибут > какой-нить выдумать
Firebird выдаст domain violation и откатит транзакцию.
> . А если Firebird при этом только сообщает об ошибке, то это > равнозначно и ошибке в рантайме.
Вот. Как выяснилось компилятор у нас уже не все проверяет. А если
подумать, то можно накопать и еще таких камешков подводных.
> C>Далее, статическая проверка SQL > C>потребует наличие схемы базы данных и DB-specific-драйвера при > C>компиляции исходника — а это выглядит слегка странно. > Что именно в этом "странно"?
Что для компиляции требуется DB-specific модули.
> C>Ну и что самое главное — сейчас многие УЖЕ используют OR-mapping > решения > C>и УЖЕ имеют типизированные объектные средства работы с базой. Зачем еще > C>чего-то добавлять в язык? > Избавить от бесконечных проверок типов разработчиков ОРМ и повысить > тем самым надёжность их продукции.
А проверки типов из такого никуда не уйдут — они просто спрячутся. А для
ORM обычно есть инструменты, которые позволяют провалидировать maping
относительно данной БД.
> C>Кроссплатформенности нормальной нет, только. > В чём именно? Её может не поддерживать код, реализующий объект. А OLE > — это ж только описание
Есть ли в Линуксе OLE и DCOM?
> C>Дельфи в этом не сильно отличается от VB. А вот в С++ идеология > C>IDispatch вообще не вписывается, например. > Коряво выглядит? Да. Но разве IDispatch как раз не для бэйсика- и js- > подобных языков задумывался?
Так вся OLE вокруг IDispatch'а построена.
--
С уважением,
Alex Besogonov (alexy@izh.com)
Posted via RSDN NNTP Server 1.9
Sapienti sat!
Re[37]: Объектно-ориентированные БД: основные принципы, орга
Здравствуйте, Cyberax, Вы писали:
C>Что кажется? Сериализацию я вот прямо сейчас использую.
Что делается. Это слезы.
C>На C# проще не будет — тут получается именно функциональный язык с C>ленивым выполнением.
Чже же тут ленивого?
C> Почти Хаскель А чтение с консоли сделать просто
Гы. Ну, уж если мериться пенисами, то не на такой фигне. На вот сэмулируй на своем хецкере:
using System;
class Program
{
delegate int Inner(int x);
delegate Inner Outer1(int y);
static void Main(string[] args)
{
Outer1 a = delegate(int x)
{
Inner c = delegate(int y)
{
x++;
return x + y;
};
return c;
};
Console.WriteLine(a(4)(5));
Test(a(4));
}
static void Test(Inner inner)
{
Console.WriteLine(inner(5));
}
}
Если вдруг удастся (в чем я сииильно сомневаюсь), то погляди на объем используемого библиотечного кода. Для сравнения — это чистый язык.
>> C>Просто в С++ фичи немного другую направленность имеют, чем в С#. >> Просто их в С++ нет. Их нужно постоянно эмулировать. Иногда это >> проходит гладко, а иногда выливается в поистене юмористические >> сложности для решения примитивных задач.
C>Есть. Шаблонное метапрограммирование — очень мощная техника.
Ага. Если других не видел. А если видел, то постыбился бы это внеполовое извращение вещью называть, не то что мощьно.
C>sizeof(a) не катит? Компилируется в константу.
Ну, передай в другую функцию и попробуй. Для сравнения:
array.Length
>> C>После WinForms я начинаю в этом сомневаться... >> И чем не угодила эта баблиотека? Слишком просто использовать?
C>Там СТОЛЬКО всего, что мне не нравится, что я даже говорить не буду
Правильно так проще, а то ведь подбирать аргументы, да еще там где их и быть неможет — это сложная задача.
... << RSDN@Home 1.1.4 beta 4 rev. 351>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[33]: Объектно-ориентированные БД: основные принципы, орга
Здравствуйте, Cyberax, Вы писали:
C>Ну так и SQL тоже.
Ты прикидываешся или правда разницы не видишь?
C>Все красиво на бумаге, да забыли про овраги...
Я одно не пойму что ты за других так переживаешь? Сделают — посмотришь. Что злословить, то бес толку?
C>Вот, например, Firebird поддерживает домены значений — я там могу на тип C>поставить ограничение, что он принимает значения от -1 до 1. Аналога C>доменов в Cw нет — как мапить их будем?
Ограничения поддерживаются SQL 99, так что можно про птичек не вспоминать. Думаю, как есть так и мапить. Констрэйны проблема сервера. А вообще — это проблема МС. Сделают — посотрим.
C> Далее, статическая проверка SQL C>потребует наличие схемы базы данных и DB-specific-драйвера при C>компиляции исходника — а это выглядит слегка странно.
Про то что SQL имет стандартный синтаксис не думал? Может проще его парсить заранее?
C> Про различные C>поведения типов в разных БД я уже вообще молчу.
Да что тебя так разная фигня трогает? Ну, предположим можно в виде ХМЛ-я описать и на диск бросить. Да мало ли решений может быть?
C>Ну и что самое главное — сейчас многие УЖЕ используют OR-mapping решения C>и УЖЕ имеют типизированные объектные средства работы с базой. Зачем еще C>чего-то добавлять в язык?
Затем что многеи не имеют и использовать это ... не хоатя.
C>Кроссплатформенности нормальной нет, только.
Просто потому-что тебе так хочется? А ничего, что несколько поставшиков все же предлагает КОМ на других платформах?
C>Дельфи в этом не сильно отличается от VB. А вот в С++ идеология C>IDispatch вообще не вписывается, например.
Дык где в язык КОМ не встроен, так монечно было не здорово. Но где был встроен, там опять таки все ОК. Погляди на VC и C++Builder. В них можно довольно просто использовать любые КОМ-объекты обладающие библиотекой типов.
... << RSDN@Home 1.1.4 beta 4 rev. 351>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[35]: Объектно-ориентированные БД: основные принципы, орга
Здравствуйте, Cyberax, Вы писали:
C>Вот. Как выяснилось компилятор у нас уже не все проверяет. А если C>подумать, то можно накопать и еще таких камешков подводных.
Ну, то-есть если компилятор все проверить не может, то ничего проверять не нужно? Логика еще та.
C>А проверки типов из такого никуда не уйдут — они просто спрячутся.
Нда. Клинический случай. Да, спрячутся. В процесс компиляции.
C>Есть ли в Линуксе OLE и DCOM?
За бабки есть. Хотя наверно, кое что есть и бесплатно.
C>Так вся OLE вокруг IDispatch'а построена.
Ну, ты оказывается еще в ОЛЕ знакток. Может не стоит рассуждать о том, в чем не понимашь?
... << RSDN@Home 1.1.4 beta 4 rev. 351>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[29]: Объектно-ориентированные БД: основные принципы, орга
VladD2 пишет:
> C>Кстати, еще один аргумент против введения XPath'а и SQL в язык — а > C>почему именно ИХ в язык добавлять? > XPath и XQuery стандарты.
ASN1 тоже стандарт. И что?
--
С уважением,
Alex Besogonov (alexy@izh.com)
Posted via RSDN NNTP Server 1.9
Sapienti sat!
Re[36]: Объектно-ориентированные БД: основные принципы, орга
VladD2 пишет:
> C>Вот. Как выяснилось компилятор у нас уже не все проверяет. А если > C>подумать, то можно накопать и еще таких камешков подводных. > Ну, то-есть если компилятор все проверить не может, то ничего > проверять не нужно? Логика еще та.
Если компилятор не может проверить _адекватно_, то лучше уж пусть не
проверяет вообще. Сейчас такая ситуация, что у каждой СУБД куча своих
заморочек — и если сделать что-то общее для всех СУБД, то получится
весьма ограниченная функциональность.
Кстати, то почти все, что есть в Омеге для SQL замечательно ложится на
С++ные шаблоны и переопределенные операторы.
> C>Есть ли в Линуксе OLE и DCOM? > За бабки есть. Хотя наверно, кое что есть и бесплатно.
Даже за бабки нет ничего нормального (мы искали, причем взяли бы за
почти любую цену).
> C>Так вся OLE вокруг IDispatch'а построена. > Ну, ты оказывается еще в ОЛЕ знакток. Может не стоит рассуждать о том, > в чем не понимашь?
Пальцем в небо — OLE я знаю досконально. Сейчас вот как раз дописываю
ActiveX-контейнер из ATL
OLE зависим от IDispatch'а, это ключевая фишка для ActiveX-контролов. В
теории возможны AX-контролы и без IDispatch'а, но на практике они будут
малополезны, так как их свойства нельзя будет редактировать из VB/Delphi/...
--
С уважением,
Alex Besogonov (alexy@izh.com)
Posted via RSDN NNTP Server 1.9
Sapienti sat!
Re[34]: Объектно-ориентированные БД: основные принципы, орга
VladD2 пишет:
> C>Ну так и SQL тоже. > Ты прикидываешся или правда разницы не видишь?
Я смысла не вижу.
> C>Все красиво на бумаге, да забыли про овраги... > Я одно не пойму что ты за других так переживаешь? Сделают — > посмотришь. Что злословить, то бес толку?
Так этого и боюсь, что сделают. У моего коллеги по работе как раз
недавно заказчик попросил _переделать_ (!!!) приложение с ADO на ADO.NET
(хорошо, видать, мозги ему промыли МСовские консультанты), хотя из
доступа к данным там было 3 запроса. А если бы этот заказчик услышал про
омегоподобные вещи....
> C> Далее, статическая проверка SQL > C>потребует наличие схемы базы данных и DB-specific-драйвера при > C>компиляции исходника — а это выглядит слегка странно. > Про то что SQL имет стандартный синтаксис не думал? Может проще его > парсить заранее?
Новая шутка: стандартный синтаксис SQL. Запомню.
> C> Про различные > C>поведения типов в разных БД я уже вообще молчу. > Да что тебя так разная фигня трогает? Ну, предположим можно в виде > ХМЛ-я описать и на диск бросить. Да мало ли решений может быть?
А _ЗАЧЕМ_ добавлять ради этого новые сущности в язык?
> C>Ну и что самое главное — сейчас многие УЖЕ используют OR-mapping > решения > C>и УЖЕ имеют типизированные объектные средства работы с базой. Зачем еще > C>чего-то добавлять в язык? > Затем что многеи не имеют и использовать это ... не хоатя.
А омегу сразу все захотят.
> C>Кроссплатформенности нормальной нет, только. > Просто потому-что тебе так хочется? А ничего, что несколько > поставшиков все же предлагает КОМ на других платформах?
Мы тестировали несколько продуктов. В основном там перенесены простейшие
функции типа создания объектов, маршалирование по библиотекам типов и
т.п. Но ни один из них не поддерживает полностью модель
ActiveX-контролов и полную спецефикацию RPC.
> C>Дельфи в этом не сильно отличается от VB. А вот в С++ идеология > C>IDispatch вообще не вписывается, например. > Дык где в язык КОМ не встроен, так монечно было не здорово. Но где был > встроен, там опять таки все ОК. Погляди на VC и C++Builder. В них > можно довольно просто использовать любые КОМ-объекты обладающие > библиотекой типов
Получается уродство в красивой обертке.
--
С уважением,
Alex Besogonov (alexy@izh.com)
Posted via RSDN NNTP Server 1.9
Sapienti sat!
Re[38]: Объектно-ориентированные БД: основные принципы, орга
mapitag_t и mapival_t — это сложные типы, для которых тоже прописана
сериализация.
> C>На C# проще не будет — тут получается именно функциональный язык с > C>ленивым выполнением. > Чже же тут ленивого?
Вычисления производятся только тогда, когда они нужны, а не когда
впервые встретились.
> C> Почти Хаскель А чтение с консоли сделать просто > Гы. Ну, уж если мериться пенисами, то не на такой фигне. На вот > сэмулируй на своем хецкере: > >using System; > >class Program >{ > delegate int Inner(int x); > delegate Inner Outer1(int y); > > static void Main(string[] args) > { > Outer1 a = delegate(int x) > { > Inner c = delegate(int y) > { > x++; > return x + y; > }; > > return c; > }; > > Console.WriteLine(a(4)(5)); > > Test(a(4)); > } > > static void Test(Inner inner) > { > Console.WriteLine(inner(5)); > } >} > > > > > Если вдруг удастся (в чем я сииильно сомневаюсь), то погляди на объем > используемого библиотечного кода. Для сравнения — это чистый язык.
Чуть пооптимизировал
> C>Есть. Шаблонное метапрограммирование — очень мощная техника. > Ага. Если других не видел. А если видел, то постыбился бы это > внеполовое извращение вещью называть, не то что мощьно.
Видел.
> C>sizeof(a) не катит? Компилируется в константу. > Ну, передай в другую функцию и попробуй. Для сравнения: > >array.Length > >
std::vector — и ваши волосы будут мягкими и шелковистыми.
>>> C>После WinForms я начинаю в этом сомневаться... >>> И чем не угодила эта баблиотека? Слишком просто использовать? > C>Там СТОЛЬКО всего, что мне не нравится, что я даже говорить не буду > Правильно так проще, а то ведь подбирать аргументы, да еще там где их > и быть неможет — это сложная задача.
0. Мне нравится как спроектирован Swing..
1. В WF нет разделения на модель и вид.
2. Нет layout'ов.
3. СЛИШКОМ сильное использование наследования.
--
С уважением,
Alex Besogonov (alexy@izh.com)
Posted via RSDN NNTP Server 1.9
Sapienti sat!
Re[13]: Объектно-ориентированные БД: основные принципы, орга
VladD2 пишет: > Встраивая поддрежку паттерна в язык разработчики этого языка обычно > довольно глубоко продумывают что и как делать. В противном случае они > просто угробят язык. А необходимость обратной совместимости не даст > исправить ошибку в дальнейшем. Все это праткически гарантирует высокое > качество реализации. Ну, а то что появляется стандарт на реализацию и
Каким образом огромная ответсвенность гарантирует качество реализации?
Имхо, угробление уже началось. C#1 был явно проще. Пусть даже с меньшими
наворотами.
--
Andrei N.Sobchuck
JabberID: andreis@jabber.ru. ICQ UIN: 46466235.
VladD2 пишет: > C>чем только можно. Лучше бы создателям С# это понять, а не пытаться > C>адаптировать систему типов под SQL, XML и т.п. > > Не боись. Они явно не тупее нас с тобой.
Кстати, вот в треде об обучении я видел высказывание, что зачем учить
другие языки, один выучил, что самый на рынке популярный и вперёд. В
связи с этим возник вопрос, а кто тогда разрабатывает новые платформы,
языки, системы? Откуда они берутся?
Это действительно совсем ни у кого из ныне учищахся нет куража от того,
что разобрался сам как работает система, и сделал по-другому?
Может лучше, может хуже, но сделал сам. Или просто такие люди
сюда не пишут, а тихонько себе что-то хачут?
Настолько ли сильно ли подготовка буржуинов лучше чем у нас, что можно
ожидать, что они сделают сразу всё правильно и на благо простых
программеров?
--
Andrei N.Sobchuck
JabberID: andreis@jabber.ru. ICQ UIN: 46466235.
Здравствуйте, Cyberax, Вы писали: >> C>Вот. Как выяснилось компилятор у нас уже не все проверяет. А если >> C>подумать, то можно накопать и еще таких камешков подводных. >> Ну, то-есть если компилятор все проверить не может, то ничего >> проверять не нужно? Логика еще та. C>Если компилятор не может проверить _адекватно_, то лучше уж пусть не C>проверяет вообще. Сейчас такая ситуация, что у каждой СУБД куча своих C>заморочек — и если сделать что-то общее для всех СУБД, то получится C>весьма ограниченная функциональность. C>Кстати, то почти все, что есть в Омеге для SQL замечательно ложится на C>С++ные шаблоны и переопределенные операторы.
А после того, как ты структуру БД поменяешь или изменишь тип поля в таблице, шаблоны компилиться перестанут. Ага.
>> C>Есть ли в Линуксе OLE и DCOM?
Кто и где обещал ДКОМ не под винды?
>> За бабки есть. Хотя наверно, кое что есть и бесплатно. C>Даже за бабки нет ничего нормального (мы искали, причем взяли бы за C>почти любую цену).
Значит что-то всё-таки есть, а выделенное уже субъективное мнение, да?
>> C>Так вся OLE вокруг IDispatch'а построена. >> Ну, ты оказывается еще в ОЛЕ знакток. Может не стоит рассуждать о том, >> в чем не понимашь? C>Пальцем в небо — OLE я знаю досконально. Сейчас вот как раз дописываю C>ActiveX-контейнер из ATL C>OLE зависим от IDispatch'а, это ключевая фишка для ActiveX-контролов. В C>теории возможны AX-контролы и без IDispatch'а, но на практике они будут C>малополезны, так как их свойства нельзя будет редактировать из VB/Delphi/...
Ты мешаешь в кучу ОЛЕ, КОМ, АХ, ДКОМ... Что бы всё запутать, да?
Приведи ссылку или расскажи какую именно МС обещала кроссплатформенность и в чём. Мне кажется это немного отличается от того, что тебе хочется получить, и обижаться на МС за это неспортивно
Ultra playing "Prodigy — Break And Enter"
<< RSDN@Home 1.1.4 beta 4 rev. 0 >>
Help will always be given at Hogwarts to those who ask for it.
Re[35]: Объектно-ориентированные БД: основные принципы, орга
Здравствуйте, Cyberax, Вы писали: >>>> И что это даст? Они и в виде классов вписываются в концепции языка >>>> очень хорошо. >> C>Ну так и SQL тоже. >> В SQL синтаксис есть, например, который компилятор проверить может. C>А в 3D компилятор мне не сможет проверить, что у меня матрица не C>сингулярная.
Гы. Приходится описывать килограммы константных матриц?? Я дел с графикой не имел, так что поправь пожалуйста, если я ошибаюсь.
Приведи примерчик кода, в котором компилятор "3D компилятор мне ... сможет проверить, что у меня матрица не сингулярная".
>> Так же есть описание того, как база данных устроена, по каким правилам >> "живёт". Значит и семантику проверить можно. А в графике чем он жизнь >> упростит? C>В графике есть, например, языки шейдеров.
не оно? http://microsoft.cs.msu.su/projects/ilshaders/
>> C>Все красиво на бумаге, да забыли про овраги... >> C>Вот, например, Firebird поддерживает домены значений — я там могу на >> тип >> C>поставить ограничение, что он принимает значения от -1 до 1. Аналога >> C>доменов в Cw нет — как мапить их будем? >> Тип данных от этого не меняется. Что произойдёт, если в такое поле >> двойку попытаться записать? Если он её к ближайшей стенке (к 1) >> приведёт и запишет 1, то да, это надо будет учесть, аттрибут >> какой-нить выдумать C>Firebird выдаст domain violation и откатит транзакцию. >> . А если Firebird при этом только сообщает об ошибке, то это >> равнозначно и ошибке в рантайме. C>Вот. Как выяснилось компилятор у нас уже не все проверяет. А если C>подумать, то можно накопать и еще таких камешков подводных.
Насколько часто из программы надо-то константные выражения вставлять в таблицу???? В рантайме-то компилятор мало чем помочь может.
Но вот проверить что архитектор базы данных не изменил структуру таблиц пока я формочки рисовал в компаил-тайм полезно.
>> C>Далее, статическая проверка SQL >> C>потребует наличие схемы базы данных и DB-specific-драйвера при >> C>компиляции исходника — а это выглядит слегка странно. >> Что именно в этом "странно"? C>Что для компиляции требуется DB-specific модули.
"Что именно в этом "странно"?" Я так и не вижу ничего "этакого"...
>> C>Ну и что самое главное — сейчас многие УЖЕ используют OR-mapping >> решения >> C>и УЖЕ имеют типизированные объектные средства работы с базой. Зачем еще >> C>чего-то добавлять в язык? >> Избавить от бесконечных проверок типов разработчиков ОРМ и повысить >> тем самым надёжность их продукции.
C>А проверки типов из такого никуда не уйдут — они просто спрячутся. А для C>ORM обычно есть инструменты, которые позволяют провалидировать maping C>относительно данной БД.
Проверки типов будут происходить в компаил-тайм, а не в рантайме (я надеюсь ). Разница есть?
Ultra playing "Prodigy — Break And Enter"
<< RSDN@Home 1.1.4 beta 4 rev. 0 >>
Help will always be given at Hogwarts to those who ask for it.
Re[38]: Объектно-ориентированные БД: основные принципы, орга
_FRED_ пишет:
> C>Кстати, то почти все, что есть в Омеге для SQL замечательно ложится на > C>С++ные шаблоны и переопределенные операторы. > А после того, как ты структуру БД поменяешь или изменишь тип поля в > таблице, шаблоны компилиться перестанут. Ага.
Если вынести мэпинг в отдельный XML-файл, то вполне можно сделать его
валидацию на этапе компиляции. Более того, это УЖЕ сделано в Hibernate.
>>> C>Есть ли в Линуксе OLE и DCOM? > Кто и где обещал ДКОМ не под винды?
Microsoft is openly licensing DCOM technology to other software
companies to run on all of the major operating systems, including
multiple implementations of UNIX-based systems. Software AG has DCOM
running on the Solaris-based operating system today. Additionally,
Microsoft is handing over DCOM technology with other core ActiveX
technologies to The Open Group. The Internet Draft technical publication
that contains a publicly available description of the DCOM network
protocol can be found at http://www.dc.luth.se/doc/id/draft-brown-dcom-v1-spec-00.txt.
>>> За бабки есть. Хотя наверно, кое что есть и бесплатно. > C>Даже за бабки нет ничего *нормального* (мы искали, причем взяли бы за > C>почти любую цену). > Значит что-то всё-таки есть, а выделенное уже субъективное мнение, да?
Ситуация такая: было сложное приложение, сделанное на COM. Заказчик
когда-то повелся на обещания МСа сделать все открытым и
многоплатформенным. Мы тестировали несколько портированных COMов, но ни
один из них не подошел для портирования — везде чего-то не хватало.
> C>Пальцем в небо — OLE я знаю досконально. Сейчас вот как раз дописываю > C>ActiveX-контейнер из ATL > C>OLE зависим от IDispatch'а, это ключевая фишка для ActiveX-контролов. В > C>теории возможны AX-контролы и без IDispatch'а, но на практике они будут > C>малополезны, так как их свойства нельзя будет редактировать из > VB/Delphi/... > Ты мешаешь в кучу ОЛЕ, КОМ, АХ, ДКОМ... Что бы всё запутать, да?
А чего их отделять? Те же AXы — это обрезанный OLE с небольшими
добавлениями. DCOM — это COM с межмашинным маршалингом.
--
С уважением,
Alex Besogonov (alexy@izh.com)
Posted via RSDN NNTP Server 1.9
Sapienti sat!
Re[14]: Объектно-ориентированные БД: основные принципы, орга
Здравствуйте, prVovik, Вы писали:
V>Здравствуйте, GlebZ, Вы писали:
GZ>>Для полного счастья — другой пример: GZ>>select a.f1, a.f2 where a.f=b.f and b.f1=c.f1 and c.f2=a.f2
V>for $x in /a return $x[ @f=/b[ @f1=/c[ @f2=$x/@f2 ]/@f1 ]/f ]
О, а лучше так:
FOR $a IN /a, $b IN /b, $c IN /c RETURN $a[ ($a/@f=$b/@f) AND ($b/f1=$c/@f1) AND ($c/@f2=$a/@f2) ]
Получилось один в один.
... << RSDN@Home 1.1.4 @@subversion >>
лэт ми спик фром май харт
Re[35]: Объектно-ориентированные БД: основные принципы, орга
Здравствуйте, prVovik, Вы писали:
V>Здравствуйте, prVovik, Вы писали:
V>>Здравствуйте, GlebZ, Вы писали:
GZ>>>Для полного счастья — другой пример: GZ>>>select a.f1, a.f2 where a.f=b.f and b.f1=c.f1 and c.f2=a.f2
V>>for $x in /a return $x[ @f=/b[ @f1=/c[ @f2=$x/@f2 ]/@f1 ]/f ]
V>О, а лучше так: V>
V>FOR $a IN /a, $b IN /b, $c IN /c RETURN $a[ ($a/@f=$b/@f) AND ($b/f1=$c/@f1) AND ($c/@f2=$a/@f2) ]
V>
V>Получилось один в один.
Уже лучше. Предыдущий я чего-то не понял. Это правда не является XPath а скорее XQuery, и возвращает объекты, а не набор полей, но за решение респект. Дюже понравилось.
С уважением, Gleb.
PS: Неужели вся эта фигня будет работать?
Re[36]: Объектно-ориентированные БД: основные принципы, орга
Здравствуйте, Cyberax, Вы писали:
C>А чего такого? Все очень просто:
Да уж. Проще не бывает.
>> C>На C# проще не будет — тут получается именно функциональный язык с >> C>ленивым выполнением. >> Чже же тут ленивого?
C>Вычисления производятся только тогда, когда они нужны, а не когда C>впервые встретились.
Что-то я не заметл там "когда они нужны". Там массив по которому и делаются вычисления. Что я пропустил?
C>
А ты не оптимизируй. А то фигня выходит. Если ты еще не въехал, то поясняю a(4) — это функция (сслка на нее) которая позволяет частично задать значение другой функции. "4" запоминается в возвращаемом результате "а" и при вызое используется для вычислений. И заметь, никаких библиотек не требуется. Функциональное программирование по полной программе, без эмуляций и ограничений.
Что же касается ленивых вычислений, то попробуй повторить на С++ вот такую примитивную конструкцию:
static IEnumerable<int> XRange(int start, int len, int inc)
{
int count = (len - start) / inc;
for (int val = start, i = 0; i < count; i++, val += inc)
yield return val;
}
и сравни с оригиналом.
C>std::vector — и ваши волосы будут мягкими и шелковистыми.
Ну, значит ты согласен, что встроенные массивы С++ ни на что не годны и даже если нужен массив с фиксированной длинной прийдется применять класс-хэлпер?
Вот так по капле и получается трах на ровном месте. Я тут как-то делал программку — подсчет слов, на С++ и на Шарпе. На Шарпе сделал за 2 минуты. На С++ протрахался час.
C>0. Мне нравится как спроектирован Swing.. C>1. В WF нет разделения на модель и вид.
Ну, это не совсем так. Тот же DataGrid вроде как по ней работает. ListBox тоже. Свинг конечно идеологически не плох, но реализация у него явно хромает.
C>2. Нет layout'ов.
Во втором фрэймворке реализованы в виде отдельных котролов.
C>3. СЛИШКОМ сильное использование наследования.
Ага. Это точно. А так же полиморфизма и инкапсуляции. Железные недостатки.
В общем, только всего уложилось в то, что в Свинге больше ориентировано на внешнюю модель.
Да и какое отношение имет язык к фрэйворку? Ими занимаются разные люди. Даже разными частями фрэймворка занимаются разные люди.
... << RSDN@Home 1.1.4 beta 4 rev. 359>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[35]: Объектно-ориентированные БД: основные принципы, орга
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>VladD2 пишет: >> C>чем только можно. Лучше бы создателям С# это понять, а не пытаться >> C>адаптировать систему типов под SQL, XML и т.п. >> >> Не боись. Они явно не тупее нас с тобой.
ANS>Кстати, вот в треде об обучении я видел высказывание, что зачем учить ANS>другие языки, один выучил, что самый на рынке популярный и вперёд.
Кстати, ты не первый кто их видел. Будь бобр, приведи ссылку на такое высказывание. Только чтобы там именно было "зачем учить другие языки". А таких как ты уж больно много стало. Замечаете то что хотите, а не то что есть на самом деле.
ANS> В ANS>связи с этим возник вопрос, а кто тогда разрабатывает новые платформы, ANS>языки, системы? ANS> Откуда они берутся?
Задай это тому от кого ты это слышал.
ANS>Это действительно совсем ни у кого из ныне учищахся нет куража от того, ANS>что разобрался сам как работает система, и сделал по-другому? ANS>Может лучше, может хуже, но сделал сам. Или просто такие люди ANS>сюда не пишут, а тихонько себе что-то хачут?
Однако много вопросов можно задать если приписать собеседнику слова которых он не говорил...
ANS>Настолько ли сильно ли подготовка буржуинов лучше чем у нас, что можно ANS>ожидать, что они сделают сразу всё правильно и на благо простых ANS>программеров?
... Очень много...
... << RSDN@Home 1.1.4 beta 4 rev. 359>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[33]: Объектно-ориентированные БД: основные принципы, орга
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>VladD2 пишет: >> Встраивая поддрежку паттерна в язык разработчики этого языка обычно >> довольно глубоко продумывают что и как делать. В противном случае они >> просто угробят язык. А необходимость обратной совместимости не даст >> исправить ошибку в дальнейшем. Все это праткически гарантирует высокое >> качество реализации. Ну, а то что появляется стандарт на реализацию и
ANS>Каким образом огромная ответсвенность гарантирует качество реализации?
Это даже как-то не ловко объяснять. Это все равно что обяснять что холодный, или что такое синий цвет.
ANS>Имхо, угробление уже началось. C#1 был явно проще. Пусть даже с меньшими ANS>наворотами.
А, по-моему, ты делаешь предположения не попробовав. Программировать стало только проще. Новые фичи просто снимают некоторые заботы с программиста и увеличивает контроль со стороны компилятора.
... << RSDN@Home 1.1.4 beta 4 rev. 359>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[37]: Объектно-ориентированные БД: основные принципы, орга
Здравствуйте, Cyberax, Вы писали:
C>Если компилятор не может проверить _адекватно_,
Кто сказал? Он как раз может адекватно проверить.
C> то лучше уж пусть не C>проверяет вообще. Сейчас такая ситуация, что у каждой СУБД куча своих C>заморочек — и если сделать что-то общее для всех СУБД, то получится C>весьма ограниченная функциональность.
Зачем низная ничего о реализации делать предположения? Пусть делают. Сделают — скажем спасибо. Не сделают, значит и вправду слишком сложно и не универсально получилось.
C>Кстати, то почти все, что есть в Омеге для SQL замечательно ложится на C>С++ные шаблоны и переопределенные операторы.
Ага. Языком. А на практике для доступа к БД С++ используют только маньяки. Да и не дают шаблоны ровным счетом ничего. Основная проблема заключается в том, что нет контроля на переходе между мирами. И в том, что ошибки не могут быть проверены до запуска программы.
>> C>Есть ли в Линуксе OLE и DCOM? >> За бабки есть. Хотя наверно, кое что есть и бесплатно.
C>Даже за бабки нет ничего нормального (мы искали, причем взяли бы за C>почти любую цену).
Вы плохо искали. Есть несколько реализаций. В том числе тут рядом обсуждался один из вариантов. Там не только КОМ, но и АТЛ с МФЦ дают. А классика есть у CA.
>> C>Так вся OLE вокруг IDispatch'а построена. >> Ну, ты оказывается еще в ОЛЕ знакток. Может не стоит рассуждать о том, >> в чем не понимашь?
C>Пальцем в небо — OLE я знаю досконально.
Я плякаль. Досканальное знание ОЛЕ и при этом не знает, что IDispatch появился в VB значительно позже ОЛЕ. ОЛЕ 1 даже на КОМ не было основано. КОМ собственно и родился как побочный продукт разработки ОЛЕ.
C> Сейчас вот как раз дописываю C>ActiveX-контейнер из ATL
Рад за тебя. Я такой фигней бросил заниматся еще в 2001. Можешь взять готовый.
C>OLE зависим от IDispatch'а, это ключевая фишка для ActiveX-контролов.
Знаток, блин. ActiveX-ы появились лет эдак через 10 после появления ОЛЕ 1 и через где-то 5 после ОЛЕ2. Они базировались на ОЛЕ. По началу они так и назывались OLE Control eXtention, или OCX. IDispatch же появился в VB (если не ошибаюсь 3 или 4) когда в нем технология VBX была заменана на OCX. На сегодня дисптч относят к Automation API. В начале его назвали OLE Automation API, но потом переименовали, так как мода называть все "ОЛЕ" закончилась и началась мода "+" и "Active".
C> В C>теории возможны AX-контролы и без IDispatch'а, но на практике они будут C>малополезны, так как их свойства нельзя будет редактировать из VB/Delphi/...
Очень смешно слышать пдобное от досканального знатака ОЛЕ. Оле и расшифровывалось как Обжект Линкинг этд Эмбединг. Изначально это интерфейс для связывания Ворда с Экселем (чтобы в Ворд можно было вставлять табличку из Экселя). Ну, и нет никаких проблем создать ActiveХ который будет использовать исключительно кастом-интерфейсы и прекрасно работать в ВБ (и уж темблее в Дельфи).
Ну, и главно. Ты занимашся технологиями прошлого века. Тот же винформс даст им 100-кртаную фору.
... << RSDN@Home 1.1.4 beta 4 rev. 359>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[38]: Объектно-ориентированные БД: основные принципы, орга
Я еще не говорил? Чтобы обеспечить статический контроль типов.
C>А омегу сразу все захотят.
C# Х.
>> C>Кроссплатформенности нормальной нет, только. >> Просто потому-что тебе так хочется? А ничего, что несколько >> поставшиков все же предлагает КОМ на других платформах?
C>Мы тестировали несколько продуктов. В основном там перенесены простейшие C>функции типа создания объектов, маршалирование по библиотекам типов и C>т.п. Но ни один из них не поддерживает полностью модель C>ActiveX-контролов и полную спецефикацию RPC.
Про RPC — это не правда. ActiveX — это вообще набор интерфейсов. Контейнеров куча. Хотя бы наш живет на голом КОМ-е.
>> C>Дельфи в этом не сильно отличается от VB. А вот в С++ идеология >> C>IDispatch вообще не вписывается, например. >> Дык где в язык КОМ не встроен, так монечно было не здорово. Но где был >> встроен, там опять таки все ОК. Погляди на VC и C++Builder. В них >> можно довольно просто использовать любые КОМ-объекты обладающие >> библиотекой типов
C>Получается уродство в красивой обертке.
Дык КОМ иделом и не был. В области компонентного прграммирования дотнет и Ява рулят одназнача.
... << RSDN@Home 1.1.4 beta 4 rev. 359>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[40]: Объектно-ориентированные БД: основные принципы, орга
VladD2 пишет:
> C>Вычисления производятся только тогда, когда они нужны, а не когда > C>впервые встретились. > Что-то я не заметл там "когда они нужны". Там массив по которому и > делаются вычисления. Что я пропустил?
Возьмем этот же пример: "_arg1++ + _arg2". Операция _arg1++ генерирует
функтор, принимающий на вход первый аргумент и увеличивающий его на 1.
_arg2 — это функтор, который ничего не делает. Далее идет операция "+",
которая создает третий функтор, принимающий на вход два других функтора.
Это сложно рассказывать — надо показывать.
> >C>boost::function func<>(_arg1++ + _arg2); >C>func(4,5); >C> > > > C>Чуть пооптимизировал > А ты не оптимизируй. А то фигня выходит. Если ты еще не въехал, то > поясняю a(4) — это функция (сслка на нее) которая позволяет частично > задать значение другой функции. "4" запоминается в возвращаемом > результате "а" и при вызое используется для вычислений.
Так тут абсолютно тоже самое. _arg++ — функция, _arg2 — функция, а +
комбинирует две функции.
> Что же касается ленивых вычислений, то попробуй повторить на С++ вот > такую примитивную конструкцию: > >static IEnumerable<int> XRange(int start, int len, int inc) >{ > int count = (len — start) / inc; > for (int val = start, i = 0; i < count; i++, val += inc) > yield return val; >} > > и сравни с оригиналом.
int XRange(ccrContParam,int start,int len,int inc)
{
ccrBeginContext;
int i,count,val;
ccrEndContext(foo);
ccrBegin(foo);
count=(len-start)/inc;
for (foo->i=0,foo->val=start; foo->i<count; foo->i++,foo->val+=inc)
{
ccrReturn(foo->val);
}
ccrFinish(-1);
}
Что характерно, если развернуть макросы и сравнить со сгенерированным
кодом для C#, то получится примерно одно и то же.
> C>std::vector — и ваши волосы будут мягкими и шелковистыми. > Ну, значит ты согласен, что встроенные массивы С++ ни на что не годны > и даже если нужен массив с фиксированной длинной прийдется применять > класс-хэлпер?
Массивы на С++ настолько гибкие, что без ограничителей с ними сложно
работать
А для массива с фиксированной длиной есть еще и boost::array.
> Вот так по капле и получается трах на ровном месте. Я тут как-то делал > программку — подсчет слов, на С++ и на Шарпе. На Шарпе сделал за 2 > минуты. На С++ протрахался час.
Это не показатель. Может быть я тоже самое написал бы за 5 минут.
> C>0. Мне нравится как спроектирован Swing.. > C>1. В WF нет разделения на модель и вид. > Ну, это не совсем так. Тот же DataGrid вроде как по ней работает. > ListBox тоже. Свинг конечно идеологически не плох, но реализация у > него явно хромает.
Согласен, реализация Свинга хромает (хотя последние версии очень даже
нормальны). У меня просто это такая несбыточная мечта, что кто-нибудь
наконец-то создаст нормальный GUI-фрэймворк.
> C>2. Нет layout'ов. > Во втором фрэймворке реализованы в виде отдельных котролов.
Посмотрю.
> C>3. СЛИШКОМ сильное использование наследования. > Ага. Это точно. А так же полиморфизма и инкапсуляции. Железные > недостатки.
Hint: кроме наследования есть еще и делегирование и аггрегирование.
--
С уважением,
Alex Besogonov (alexy@izh.com)
Posted via RSDN NNTP Server 1.9
Sapienti sat!
Re[36]: Объектно-ориентированные БД: основные принципы, орга
Ну и? А теперь вы можете мне показать распространенную крупную базу, у
которой нет своих несовместимых со стандартом расширения SQL?
> C>А _ЗАЧЕМ_ добавлять ради этого новые сущности в язык? > Я еще не говорил? Чтобы обеспечить статический контроль типов.
Если для этого надо вводить новые сущности в язык ДЛЯ КАЖДОГО ОТДЕЛЬНОГО
СЛУЧАЯ — то это лучше не делать вообще.
> C>Мы тестировали несколько продуктов. В основном там перенесены > простейшие > C>функции типа создания объектов, маршалирование по библиотекам типов и > C>т.п. Но ни один из них не поддерживает полностью модель > C>ActiveX-контролов и полную спецефикацию RPC. > Про RPC — это не правда.
Правда, полностью его нормально никто не сделал.
> ActiveX — это вообще набор интерфейсов. Контейнеров куча. Хотя бы наш > живет на голом КОМ-е.
Угу. Сейчас как раз этим и занимаюсь, блин. Пишу свою реалиазцию контейнера.
> C>Получается уродство в красивой обертке. > Дык КОМ иделом и не был. В области компонентного прграммирования > дотнет и Ява рулят одназнача.
Согласен.
--
С уважением,
Alex Besogonov (alexy@izh.com)
Posted via RSDN NNTP Server 1.9
Sapienti sat!
Re[36]: Объектно-ориентированные БД: основные принципы, орга
VladD2 пишет: > Здравствуйте, Andrei N.Sobchuck, Вы писали: > ANS>VladD2 пишет: >> > C>чем только можно. Лучше бы создателям С# это понять, а не пытаться >> > C>адаптировать систему типов под SQL, XML и т.п. >> > >> > Не боись. Они явно не тупее нас с тобой. > > ANS>Кстати, вот в треде об обучении я видел высказывание, что зачем учить > ANS>другие языки, один выучил, что самый на рынке популярный и вперёд. > > Кстати, ты не первый кто их видел. Будь бобр, приведи ссылку на такое > высказывание. Только чтобы там именно было "зачем учить другие языки". А > таких как ты уж больно много стало. Замечаете то что хотите, а не то что > есть на самом деле.
: A>Следующей по важности целью является обучение студента
алгоритмированию. Эта цель определяется специальностью, на которую
учащийся поступил. Тут, очевидно, язык не важен, практически полная
абстракция. Единственное требование — это соответствие возможностей
языка поставленным задачам. Пишите хоть на языке, который называется
"великий и могучий Русский язык", только вот компилятора для него еще не
придумали и тестировать написанную программу вручную преподу врядли
понравится.
Если язык не важен, то почему нельзя писать, на том с чем он столкнётся? Зачем для этого учить лишние языки (фортраны, паскали) Не проще ли на
основе применения этих алгоритмов заодно углубить свои познания в том же
C# или Java?
> ANS> В > ANS>связи с этим возник вопрос, а кто тогда разрабатывает новые платформы, > ANS>языки, системы? Откуда они берутся? > > Задай это тому от кого ты это слышал.
Задать вопрос тому, от кого я слышал о появлении новых платформ? Да ты
шутник!
> ANS>Это действительно совсем ни у кого из ныне учищахся нет куража от того, > ANS>что разобрался *сам* как работает система, и сделал по-другому? > ANS>Может лучше, может хуже, но сделал *сам*. Или просто такие люди > ANS>сюда не пишут, а тихонько себе что-то хачут? > > Однако много вопросов можно задать если приписать собеседнику слова > которых он не говорил...
А ты не ёрничая ответил бы есть у тебя кураж когда ты, например, пишеш
Janus, или разбираешся в чем или нет?
--
Andrei N.Sobchuck
JabberID: andreis@jabber.ru. ICQ UIN: 46466235.
C>Согласен, реализация Свинга хромает (хотя последние версии очень даже C>нормальны). У меня просто это такая несбыточная мечта, что кто-нибудь C>наконец-то создаст нормальный GUI-фрэймворк.
И очень даже сбыточная Эпловую Cocoa видел? Мне очень нравится!
И гибкость, и MVC-везде, где только можно, и вместе с тем, простая для изучения и работы...
У нее, правда, есть один фатальный недостаток...
... << RSDN@Home 1.1.4 beta 4 rev. 303>>
Кто здесь?!
Re[41]: Объектно-ориентированные БД: основные принципы, орга
Здравствуйте, Cyberax, Вы писали:
C>Возьмем этот же пример: "_arg1++ + _arg2". Операция _arg1++ генерирует C>функтор, принимающий на вход первый аргумент и увеличивающий его на 1. C>_arg2 — это функтор, который ничего не делает. Далее идет операция "+", C>которая создает третий функтор, принимающий на вход два других функтора. C>Это сложно рассказывать — надо показывать.
Что ты называшь "фанторами"? Что же до показывать. Я тебе привожу примеры которые можно легко откомпилировать просто поместив в пустой проект. Твой же код воообще не полно и требует установки дополнительных библиотек и настройки среды. Так что с показом тут не очень.
В общем, попробуй привести полный аналог кода, без оптимизаций и так чтобы его можно было скомпилировать хотя бы при наличии установленного буста.
C>Так тут абсолютно тоже самое. _arg++ — функция, _arg2 — функция, а + C>комбинирует две функции.
Нет в твоем коде ни одной функции. Еще раз повторюсь. Я привел полностью рабочий, а не гипотетический. В общем, не нужно оптимизировать. Просто повтори. И целиком, а не частично.
>>static IEnumerable<int> XRange(int start, int len, int inc) >>{ >> int count = (len — start) / inc; >> for (int val = start, i = 0; i < count; i++, val += inc) >> yield return val; >>} >> >> и сравни с оригиналом.
C>http://www.chiark.greenend.org.uk/~sgtatham/coroutines.html C>
C>Что характерно, если развернуть макросы и сравнить со сгенерированным C>кодом для C#, то получится примерно одно и то же.
Да? Вот беда. Мой код компилируется и работает. А твой даже не очень. При этом он уже больше моего. И вообще не ясно что он делает. А что там делает компилятор меня не интересует. Я работаю на уровне абстракций языка. И получаю ясную и простую программу.
C>Массивы на С++ настолько гибкие, что без ограничителей с ними сложно C>работать
Ага. Я бы сказал больше. В С++ просто нет полноценных массивов.
C>А для массива с фиксированной длиной есть еще и boost::array.
Это опять же обертка. Массивы — это примитивы языка.
>> Вот так по капле и получается трах на ровном месте. Я тут как-то делал >> программку — подсчет слов, на С++ и на Шарпе. На Шарпе сделал за 2 >> минуты. На С++ протрахался час.
C>Это не показатель. Может быть я тоже самое написал бы за 5 минут.
Уверен, что если задача не пишется "по памяти", т.е. второй раз, то ты всегда проиграешь мне минимум в трое. Ну, а на сложных и того больше. Уроветь языка очень низкий. Количество шолухи которое постоянно нужно держать в голове слишком велико. Надежность получаемых решений низкая. Библиотеки сложные и запутанные. В итоге постоянно возникают затыки на ровных местах. Я когда-то тоже думал что пишу на плюсах относительно быстро. Вот только ключевое слово оказалось "относительно".
C>Согласен, реализация Свинга хромает (хотя последние версии очень даже C>нормальны).
Возможно я не копался в последнем. Но все что я видел оказывлось красивым до тех пор пока сам не начинаещь использовать получившийся ГУИ. А как начинашь, так сразу нарывашся на кучу мелких проблем. То клипборд работает не так как надо, то функциональности не хватет. То с фокусом проблемы.
C>У меня просто это такая несбыточная мечта, что кто-нибудь C>наконец-то создаст нормальный GUI-фрэймворк.
Гы. Авалон спасет отца русской демократии. Правда он получился довольно сложным. Но гибкость и возможности потрясающие. И как ты хочешь все на ОО-моделях. Даже кнопка и та контейнер в который можно помещать разные элементы вроде текста и графики.
>> C>3. СЛИШКОМ сильное использование наследования. >> Ага. Это точно. А так же полиморфизма и инкапсуляции. Железные >> недостатки.
C>Hint: кроме наследования есть еще и делегирование и аггрегирование.
Наследование само по себе быть недостатком не может. Вернее может, но только если в голове тараканы. Другое дело, что наследование может быть не оптимальным. Но что-то я не припомню особых проблем с этим в Формсах.
... << RSDN@Home 1.1.4 beta 4 rev. 359>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[37]: Объектно-ориентированные БД: основные принципы, орга
: ANS>A>Следующей по важности целью является обучение студента ANS>алгоритмированию. Эта цель определяется специальностью, на которую ANS>учащийся поступил. Тут, очевидно, язык не важен, практически полная ANS>абстракция. Единственное требование — это соответствие возможностей ANS>языка поставленным задачам. Пишите хоть на языке, который называется ANS>"великий и могучий Русский язык", только вот компилятора для него еще не ANS>придумали и тестировать написанную программу вручную преподу врядли ANS>понравится. ANS>Если язык не важен, то почему нельзя писать, на том с чем он столкнётся? ANS>Зачем для этого учить лишние языки (фортраны, паскали) Не проще ли на ANS>основе применения этих алгоритмов заодно углубить свои познания в том же ANS>C# или Java?
А тебе не кажется, что тут речь шала о том, что изучать алгоритмы можно и на этих языках? И что человек не имел в виду, что другие технологии вредно изучать? В общем, посыл был в "зачем для этого".
Можно переспросить у товарища что он имел в виду.
>> ANS> В >> ANS>связи с этим возник вопрос, а кто тогда разрабатывает новые платформы, >> ANS>языки, системы? Откуда они берутся? >> >> Задай это тому от кого ты это слышал.
ANS>Задать вопрос тому, от кого я слышал о появлении новых платформ? Да ты ANS>шутник!
Тому от кого ты слышал, что учить нужно только один язык.
ANS>А ты не ёрничая ответил бы есть у тебя кураж когда ты, например, пишеш ANS>Janus, или разбираешся в чем или нет?
Я не знаю что означает для тебя слово "кураж". Мне в принципе интересно писать код. И я стараюсь писать то что мне нравится и на том на чем мне нравится писать. Если говорить конкретно о Янусе, то сейчас я в основном замазываю чужие глюки и добавляю мелкие фичи. Когда я рефакторил Янус переводя его на ОО-модель, то это было действительно интересно.
Вот недавно перевел Янус на 64-битную платформу. Веренее сам Янус перевелся влет и так. А вот нэйтив-код (Синтила (текстовый редаткор) и т.п.) оказалось перевести не так просто. Потрахался не не шутку с С++. Но тоже интересно.
... << RSDN@Home 1.1.4 beta 4 rev. 359>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[37]: Объектно-ориентированные БД: основные принципы, орга
Здравствуйте, Cyberax, Вы писали:
>> C>Новая шутка: стандартный синтаксис SQL. Запомню. >> Да, уж. Потрудись: http://aam.ugpl.de/book/print/157 .
C>Ну и? А теперь вы можете мне показать распространенную крупную базу, у C>которой нет своих несовместимых со стандартом расширения SQL?
Не моежм. Но это и не требуется, так как мы можем лицизреть целую кучу СУБД удовляетворяющих SQL-92/99. Тот же MSSQL и Oracle на сегодня ему точно удовлетворяют. Вполне достаточно если будет совместимость с SQL-92.
C>Если для этого надо вводить новые сущности в язык ДЛЯ КАЖДОГО ОТДЕЛЬНОГО C>СЛУЧАЯ — то это лучше не делать вообще.
Согласен. Думаю, разработчики Шарпа тоже согласятся. Вот только "ДЛЯ КАЖДОГО ОТДЕЛЬНОГО СЛУЧАЯ" — это явно твои домыслы.
C>Правда, полностью его нормально никто не сделал.
Там делать нечего. МС повторил стандарт DCE RPC.
C>Угу. Сейчас как раз этим и занимаюсь, блин. Пишу свою реалиазцию контейнера.
Велосипедостроение увлекательное занятие.
... << RSDN@Home 1.1.4 beta 4 rev. 359>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[38]: Объектно-ориентированные БД: основные принципы, орга
VladD2 пишет:
> C>Ну и? А теперь вы можете мне показать распространенную крупную базу, у > C>которой нет своих несовместимых со стандартом расширения SQL? > Не моежм. Но это и не требуется, так как мы можем лицизреть целую кучу > СУБД удовляетворяющих SQL-92/99. Тот же MSSQL и Oracle на сегодня ему > точно удовлетворяют. Вполне достаточно если будет совместимость с SQL-92.
Тогда нельзя будет использовать расширеные возможности каждой БД. Но не
стоит волноваться — для МS SQL поддержка всех его расширенных
возможностей по какой-то совершенно странной случайности обязательно будет.
> C>Если для этого надо вводить новые сущности в язык ДЛЯ КАЖДОГО > ОТДЕЛЬНОГО > C>СЛУЧАЯ — то это лучше не делать вообще. > Согласен. Думаю, разработчики Шарпа тоже согласятся. Вот только "ДЛЯ > КАЖДОГО ОТДЕЛЬНОГО СЛУЧАЯ" — это явно твои домыслы.
SQL и XML — для меня частные случаи.
> C>Правда, полностью его нормально никто не сделал. > Там делать нечего. МС повторил стандарт DCE RPC.
Поищите в MSDN по словам "wire_marshal" — это МСовское расширение RPC.
Там еще таких несколько есть.
> C>Угу. Сейчас как раз этим и занимаюсь, блин. Пишу свою реалиазцию > контейнера. > Велосипедостроение увлекательное занятие.
Я не с ноля же пишу, а аккуратно копирую с ATL
--
С уважением,
Alex Besogonov (alexy@izh.com)
Posted via RSDN NNTP Server 1.9
Sapienti sat!
Re[42]: Объектно-ориентированные БД: основные принципы, орга
_wqwa пишет:
> C>Согласен, реализация Свинга хромает (хотя последние версии очень даже > C>нормальны). У меня просто это такая несбыточная мечта, что кто-нибудь > C>наконец-то создаст нормальный GUI-фрэймворк. > И очень даже сбыточная Эпловую Cocoa видел? Мне очень нравится!
Я вообще на OS X смотрю и плачу. Все в ней сделано правильно (по
сравнению с Win/Lin), а вот использовать — нельзя Так как уровень
распространения Маков ~0.
--
С уважением,
Alex Besogonov (alexy@izh.com)
Posted via RSDN NNTP Server 1.9
Sapienti sat!
Re[38]: Объектно-ориентированные БД: основные принципы, орга
VladD2 пишет: > C>Ну и? А теперь вы можете мне показать распространенную крупную базу, у > C>которой нет своих несовместимых со стандартом расширения SQL? > > Не моежм. Но это и не требуется, так как мы можем лицизреть целую кучу > СУБД удовляетворяющих SQL-92/99. Тот же MSSQL и Oracle на сегодня ему > точно удовлетворяют. Вполне достаточно если будет совместимость с SQL-92.
Можно ссылку хотя бы на то, где написано, что MSSQL полностью
удовлетворяет SQL-92.
--
Andrei N.Sobchuck
JabberID: andreis@jabber.ru. ICQ UIN: 46466235.
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>Можно ссылку хотя бы на то, где написано, что MSSQL полностью ANS>удовлетворяет SQL-92.
Полностью не удовлетворяет никто, но "удовлетворяемость" стандарту делится на несколько уровней: начальный, переходный, промежуточный, полный... Официально все СУБД сертифицированы только на начальный, в том числе и MSSQL, а неофициально основные игроки поддерживают где-то на уровне переходный-промежуточный.
... [ RSDN@Home 1.1.4 rev 303 ]
Мы уже победили, просто это еще не так заметно...
Re[40]: Объектно-ориентированные БД: основные принципы, орга
Я вот набрал
и в первой <br />
же ссылке вижу: Both SQL Server 2000 and MySQL version 4.1 support the ANSI SQL-92
entry level and do not support the ANSI SQL-92 intermediate level.
--
Andrei N.Sobchuck
JabberID: andreis@jabber.ru. ICQ UIN: 46466235.
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>Both SQL Server 2000 and MySQL version 4.1 support the ANSI SQL-92 ANS>entry level and do not support the ANSI SQL-92 intermediate level.
И? "support the ANSI SQL-92 entry level" более чем достаточно. Почитай что это означает. Это как раз совместимость на уровне селектов и апдэйктов.
... << RSDN@Home 1.1.4 beta 4 rev. 351>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[36]: Объектно-ориентированные БД: основные принципы, орга
_FRED_ пишет:
>>>>> И что это даст? Они и в виде классов вписываются в концепции языка >>>>> очень хорошо. >>> C>Ну так и SQL тоже. >>> В SQL синтаксис есть, например, который компилятор проверить может. > C>А в 3D компилятор мне не сможет проверить, что у меня матрица не > C>сингулярная. > Гы. Приходится описывать килограммы константных матриц?? Я дел с > графикой не имел, так что поправь пожалуйста, если я ошибаюсь.
Нет, не приходится. Но мне неприходится описывать и килограммы
статического SQL! Он у меня лежит в отдельном XML-файле, в котором
описывается OR-maping.
> Приведи примерчик кода, в котором компилятор "3D компилятор мне ... > сможет проверить, что у меня матрица не сингулярная".
Оно.
>>> . А если Firebird при этом только сообщает об ошибке, то это >>> равнозначно и ошибке в рантайме. > C>Вот. Как выяснилось компилятор у нас уже не все проверяет. А если > C>подумать, то можно накопать и еще таких камешков подводных. > Насколько часто из программы надо-то константные выражения вставлять в > таблицу???? В рантайме-то компилятор мало чем помочь может.
ВОТ! А зачем тогда вообще нужна вся эта возня с SQL в языке? Сложность
языка увеличивается пропорционально квадрату количества фич в нем. Зачем
сильно усложнять язык, если можно обойтись без этого?
> Но вот проверить что архитектор базы данных не изменил структуру > таблиц пока я формочки рисовал в компаил-тайм полезно.
Ну так используйте OR-maping, и пусть архитектор базы меняет его при
изменении схемы. Какие здесь проблемы?
>>> Что именно в этом "странно"? > C>Что для компиляции требуется DB-specific модули. > "Что именно в этом "странно"?" Я так и не вижу ничего "этакого"...
Я понимаю, людям которые пишут все только под одну конфигурацию софта
(Win+MS SQL+.NET) это не кажется странным...
> C>А проверки типов из такого никуда не уйдут — они просто спрячутся. А > для > C>ORM обычно есть инструменты, которые позволяют провалидировать maping > C>относительно данной БД. > Проверки типов будут происходить в компаил-тайм, а не в рантайме (я > надеюсь ). Разница есть?
Кто мешает вставить в билд-скрипт валидацию текущего OR-mapping'а
относительно текущей схемы БД? И будет та же compile-time проверка.
--
С уважением,
Alex Besogonov (alexy@izh.com)
Posted via RSDN NNTP Server 1.9
Sapienti sat!
Re[38]: Объектно-ориентированные БД: основные принципы, орга
VladD2 пишет:
> C> то лучше уж пусть не > C>проверяет вообще. Сейчас такая ситуация, что у каждой СУБД куча своих > C>заморочек — и если сделать что-то общее для всех СУБД, то получится > C>весьма ограниченная функциональность. > Зачем низная ничего о реализации делать предположения? Пусть делают. > Сделают — скажем спасибо. Не сделают, значит и вправду слишком сложно > и не универсально получилось.
Ага, они _сначала_ сделают, поставят, разрекламируют, а потом нам с этим
жить.
> C>Даже за бабки нет ничего нормального (мы искали, причем взяли бы за > C>почти любую цену). > Вы плохо искали. Есть несколько реализаций. В том числе тут рядом > обсуждался один из вариантов. Там не только КОМ, но и АТЛ с МФЦ дают. > А классика есть у CA.
Можно ссылки?
> C>Пальцем в небо — OLE я знаю досконально. > Я плякаль. Досканальное знание ОЛЕ и при этом не знает, что IDispatch > появился в VB значительно позже ОЛЕ. ОЛЕ 1 даже на КОМ не было > основано. КОМ собственно и родился как побочный продукт разработки ОЛЕ.
Я говорю сейчас об OLE 1? Под словом "OLE" обычно понимают OLE 2.
> C> Сейчас вот как раз дописываю > C>ActiveX-контейнер из ATL > Рад за тебя. Я такой фигней бросил заниматся еще в 2001. Можешь взять > готовый <http://www.optim.ru/Software/rus/ascContainer/asccontainer.asp>.
Нет, у меня другая направленность. Мне нужно сделать что-то типа Visio.
> C>OLE зависим от IDispatch'а, это ключевая фишка для ActiveX-контролов. > Знаток, блин. ActiveX-ы появились лет эдак через 10 после появления > ОЛЕ 1 и через где-то 5 после ОЛЕ2.
Про OLE 1 забудем, оно к делу слабо относится. Чистый COM появился в
начале 90-х, у меня сейчас лежит драфт стандарта MAPI от 91 года — там
уже используется COM.
> Они базировались на ОЛЕ. По началу они так и назывались OLE Control > eXtention, или OCX.
Сначала был крайне успешный VBX, который просто позволял подключать к VB
внешние обработчики виндовых событий.
> IDispatch же появился в VB (если не ошибаюсь 3 или 4) когда в нем > технология VBX была заменана на OCX. На сегодня дисптч относят к > Automation API. В начале его назвали OLE Automation API, но потом > переименовали, так как мода называть все "ОЛЕ" закончилась и началась > мода "+" и "Active".
Да, и именно тогда началась настоящая мода на ActiveXы, хотя OCX до
этого был практически незаметен (еще и потому, что не было нормальных СДК).
> C>теории возможны AX-контролы и без IDispatch'а, но на практике они будут > C>малополезны, так как их свойства нельзя будет редактировать из > VB/Delphi/... > Очень смешно слышать пдобное от досканального знатака ОЛЕ. Оле и > расшифровывалось как Обжект Линкинг этд Эмбединг.
Прекрасно знаю. Однако ActiveX — это часть OLE, и я вроде бы говорил,
что не разделяю их.
> Изначально это интерфейс для связывания Ворда с Экселем (чтобы в Ворд > можно было вставлять табличку из Экселя). Ну, и нет никаких проблем > создать ActiveХ который будет использовать исключительно > кастом-интерфейсы и прекрасно работать в ВБ (и уж темблее в Дельфи).
Да, но какая _практическая_ польза будет от него? Его свойства нельзя
будет редактировать визуально из VB/Delphi, а это и есть главное
достоинство AXов.
> Ну, и главно. Ты занимашся технологиями прошлого века. Тот же винформс > даст им 100-кртаную фору.
Для C# нет нормальной поддержки VBA. Был VSA, но МС его перестал продавать.
--
С уважением,
Alex Besogonov (alexy@izh.com)
Posted via RSDN NNTP Server 1.9
Sapienti sat!
Re[39]: Объектно-ориентированные БД: основные принципы, орга
Здравствуйте, Cyberax, Вы писали:
C>Да, но какая _практическая_ польза будет от него? Его свойства нельзя C>будет редактировать визуально из VB/Delphi, а это и есть главное C>достоинство AXов.
Заходишь в VS... создашь проект "ATL Project"... Выбирашь добавит класс... Выбирашь "ATL Control"... В диалоге содания на закладке "Options" выбирашь "Interface: Custom"... Добавляешь свойство... Идешь в Дельфи, VS (хоть в дотнет) или ВБ6 и видшь что все ОК.
Далее думашь за каких хреном создал это доисторическое убожщен так как и новый ВБ и Шарп прекрасно живут с ВыньФормсовыми контролами которые и создавать и поддерживать в сто раз проще.
>> Ну, и главно. Ты занимашся технологиями прошлого века. Тот же винформс >> даст им 100-кртаную фору.
C>Для C# нет нормальной поддержки VBA. Был VSA, но МС его перестал продавать.
А VBA ваша компания в состоянии купить? VSA как было так и есть. Можешь пользоватьс бесплатно. Ну, а VS можно купить и отдельно. В сором времени появятся Express-ы которые вообще будет чуть ли не бесплатны.
VladD2 пишет:
> C>Да, но какая _практическая_ польза будет от него? Его свойства нельзя > C>будет редактировать визуально из VB/Delphi, а это и есть главное > C>достоинство AXов. > Заходишь в VS... создашь проект "ATL Project"... Выбирашь добавит > класс... Выбирашь "ATL Control"... В диалоге содания на закладке > "Options" выбирашь "Interface: Custom"... Добавляешь свойство... Идешь > в Дельфи, VS (хоть в дотнет) или ВБ6 и видшь что все ОК.
Сделал (естественно, не пометив интерфейс как automation compatible).
Добавляю в VB6: "Unexpected error (35005)". Тоже самое, но с дуальным
интерфейсом прокатывает без проблем. Делфи у меня не стоит, так что
проверить не могу.
> Далее думашь за каких хреном создал это доисторическое убожщен так как > и новый ВБ и Шарп прекрасно живут с ВыньФормсовыми контролами которые > и создавать и поддерживать в сто раз проще.
Ага, а как мне их заюзать из моего отстойного, устаревшего приложения на
С++?
> C>Для C# нет нормальной поддержки VBA. Был VSA, но МС его перестал > продавать. > А VBA ваша компания в состоянии *купить*?
Да. Стоит он не так дорого — около $10000, без всяких run-time лицензий.
А я уже говорил, кажется, что мы пишем софт для всяких Porsche
> VSA как было так и есть.
Нет. Нам его _отказались_ продавать, сказали: "Берите VBA". В общем, не
понимаю я политику МС в этом вопросе.
> Можешь пользоватьс бесплатно. Ну, а VS можно купить и отдельно. В > сором времени появятся Express-ы которые вообще будет чуть ли не > бесплатны.
Здравствуйте, Cyberax, Вы писали:
C>_wqwa пишет:
>> C>Согласен, реализация Свинга хромает (хотя последние версии очень даже >> C>нормальны). У меня просто это такая несбыточная мечта, что кто-нибудь >> C>наконец-то создаст нормальный GUI-фрэймворк. >> И очень даже сбыточная Эпловую Cocoa видел? Мне очень нравится!
C>Я вообще на OS X смотрю и плачу. Все в ней сделано правильно (по C>сравнению с Win/Lin), а вот использовать — нельзя Так как уровень C>распространения Маков ~0.
а в свете того что есть такая система как дарвин?
и то, что маки двинулись в сторону IBM совместимых машин. Смотрел ли на это более внимательно? может стоит уже начинать двигатся в эту сторону?
З.Ы.
перечитывал архивы, уж извините янусопоклонники что поднял тему..
ironwit wrote:
> C>Я вообще на OS X смотрю и плачу. Все в ней сделано правильно (по > C>сравнению с Win/Lin), а вот использовать — нельзя Так как уровень > C>распространения Маков ~0. > а в свете того что есть такая система как дарвин?
Ну есть. Без закрытой Aqua это просто очередная BSD.
> и то, что маки двинулись в сторону IBM совместимых машин. Смотрел ли > на это более внимательно? может стоит уже начинать двигатся в эту сторону?
Да какая разница. Они публично заявили, что MacOS X _НЕ_ будет работать
на обычных x86-компьютерах, то есть все равно нужно будет покупать их
дорогое железо.
--
С уважением,
Alex Besogonov (alexy@izh.com)
Posted via RSDN NNTP Server 2.0 beta
Sapienti sat!
Re[45]: Объектно-ориентированные БД: основные принципы, орга
Здравствуйте, Cyberax, Вы писали:
C>ironwit wrote:
>> C>Я вообще на OS X смотрю и плачу. Все в ней сделано правильно (по >> C>сравнению с Win/Lin), а вот использовать — нельзя Так как уровень >> C>распространения Маков ~0. >> а в свете того что есть такая система как дарвин?
C>Ну есть. Без закрытой Aqua это просто очередная BSD.
>> и то, что маки двинулись в сторону IBM совместимых машин. Смотрел ли >> на это более внимательно? может стоит уже начинать двигатся в эту сторону?
C>Да какая разница. Они публично заявили, что MacOS X _НЕ_ будет работать C>на обычных x86-компьютерах, то есть все равно нужно будет покупать их C>дорогое железо.