Здравствуйте, shuklin, Вы писали:
S>Вы если и правы, так только в дефенициях. Мне глубоко пофиг как что назвать.
Вот давай подумаем, зачем ты сюда пришел со своей БД, которая рушит все устои... Ты пришел чтобы рассказать нам об этом, чтобы мы прониклись и оценили, правильно? Для того чтобы мы смогли это оценить и проникнуться нам надо понять что ты говоришь, а чтобы понять что ты говоришь, надо чтобы у нас хотя бы терминология была одинаковая... Но тебе пофиг — парадокс?
То тебе O(1) не нравится и ты его в O(C) переименовал, то объектами невесть что называешь, опять-таки потому что тебе нравится....
S>От названия суть не меняется. Не зависимо от того что "правы" вы в обоих случаях, функциональность от этого не страдает.
Видишь ли, в данном случае обсуждается как раз та функциональность, которая в твоей БД весьма страдает.
S> Если нам важны вопросы секурити и мы согласны забить на перформанс — вуаля, мы идем по первой веточке где вы "правы". S>Если нам нужно получить перформанс — идем по второй, а секурити обеспечиваем уровнем выше.
Если бы ты дал себе труд почитать ветку внимательно, прежде чем вмешиваться, то понял бы, что речь идет вовсе не о производительности, хотя и о ней поговорить стоит.
Если мы отказываемся от инкапсуляции, то получаем хранилище ни чем не лучше реляционного, если не отказываемся, то в твоем варианте, по мимо всего прочего, получаем еще и проблемы с производительностью.
S>по любому ОБД на основе сетевой модели рулят.
Ты это как мантру, в любое сообщение вставляешь? Так куда у нас рулят "ООБД на основе сетевой модели", и чем они лучше сетевых БД, которым уже лет тридцать с хвостиком?
... << RSDN@Home 1.2.0 alpha rev. 0>>
Мы уже победили, просто это еще не так заметно...
Re[13]: Файловые системы, файлы, приложения - устаревшие кон
Здравствуйте, Merle, Вы писали:
S>>Вы если и правы, так только в дефенициях. Мне глубоко пофиг как что назвать. M>Вот давай подумаем, зачем ты сюда пришел со своей БД, которая рушит все устои... Ты пришел чтобы рассказать нам об этом, чтобы мы прониклись и оценили, правильно?
В том числе — и для этого. Ващето больше меня интересует найти дыры в собственной концепции. Ну бывало и такое. Поэтому кстати версия от декабря 2005 имеет иерархическую глубинную архитектуру, а последняя — сетевую. Пасиба народу который меня на sql.ru попинал на предмет объектных VIEW & JOIN. До этого обсуждения я предполагал забить на сеть в глубине ядра. После обсуждения понял что халтурить не выйдет )))
M>Видишь ли, в данном случае обсуждается как раз та функциональность, которая в твоей БД весьма страдает.
Это какая же? Опять начнем мусолить функциональность инкапсуляции? У запретов нет функциональности. Если что то делать нельзя (ходить к закрытым полям) то это вовсе не функциональность а ее отсутвие. Если тебе дорги костыли и запреты — пользуйся ими наздоровье. И такого стиля девелопмента есть поддержка в моей СУБД.
M>Если мы отказываемся от инкапсуляции, то получаем хранилище ни чем не лучше реляционного,
Оно не лучше и не хуже, но оно на основе другой МД. А вот другая МД это именно ДРУГАЯ. Ну а моя реализация по поводу производительности еще не тюнилась профайлером ни разу ... А даже уже дает весьма достаточное быстродейстивие
M> если не отказываемся, то в твоем варианте, по мимо всего прочего, получаем еще и проблемы с производительностью.
"Проблемы" по сравнению с первым случаем использования моей же СУБД а не по сравнению с конкурирующими СУБД.
Re[13]: Файловые системы, файлы, приложения - устаревшие кон
Здравствуйте, shuklin, Вы писали:
S>>Ты не можешь поддерживать полиморфизм, не поддерживая инкапсуляции. Поддержка полиморфизма требует развязки интерфейса и его реализации, а при отсутствии инкапсуляции это невозможно.
S>В таком случае я сказал свое новое слово в данном вопросе.
Здравствуйте, shuklin, Вы писали:
E>>Вероятно, скоро на вашем сайте появится статья: "Дмитрий Шуклин о перспективах полиморфизма без инкапсуляции".
S>Мало вероятно Тему следующей провокации я еще не выбрал
Вот-вот, провокации.
Пока то, что я прочитал в данном форуме больше напоминает попытку раскрутки собственной разработки путем организации провокации и пустого флейма.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[40]: Файловые системы, файлы, приложения - устаревшие кон
Здравствуйте, shuklin, Вы писали:
S>В том числе — и для этого.
Ну раз для этого, тогда сначала потрудись хотя бы привести терминологию к общепринятой...
S> Ващето больше меня интересует найти дыры в собственной концепции. Ну бывало и такое.
Во-во, тебе этих дыр уже, на десять лет разгребания здесь навалили.
S>Это какая же?
А вот так же.
S>Опять начнем мусолить функциональность инкапсуляции?
Ну вообще-то, пока ты не влез, с данной функциональностью все было в порядке.
S>Если что то делать нельзя (ходить к закрытым полям) то это вовсе не функциональность а ее отсутвие.
Очень рекомендую тебе на эту тему побеседовать с апологетами ООП, сразу все на место встанет, где функциональность, а где отсутствие. А заодно литературку какую-нибудь почитать, вместо того, чтобы за клавиатуру хвататься.
S>Оно не лучше и не хуже, но оно на основе другой МД. А вот другая МД это именно ДРУГАЯ.
Ну, если цель сделать просто ДРУГУЮ, то пожалуйста, только не морочь людям голову.
S> Ну а моя реализация по поводу производительности еще не тюнилась профайлером ни разу ... А даже уже дает весьма достаточное быстродейстивие
Ой, не смеши мои шлепанци, по поводу твоего быстродействия тебе уже все сказали и это ты еще параллельный доступ и логгирование не прикручивал.
S>"Проблемы" по сравнению с первым случаем использования моей же СУБД а не по сравнению с конкурирующими СУБД.
У тебя даже индексов нет по полям, о какой производительности вообще может идти речь?
Здравствуйте, shuklin, Вы писали:
S>Тоесть конструктивные аргументы
Как можно давать конструктивные аргументы на неконструктивное впаривание? Это пустая трата сил...
Конструктив был в первом сообщении, но развивать его ты не захотел, а кто я такой чтобы навязываться со своим конструктивом?
... << RSDN@Home 1.2.0 alpha rev. 0>>
Мы уже победили, просто это еще не так заметно...
Re[43]: Файловые системы, файлы, приложения - устаревшие кон
Здравствуйте, Merle, Вы писали:
M>Конструктив был в первом сообщении, но развивать его ты не захотел, а кто я такой чтобы навязываться со своим конструктивом?
Уважаемый, конструктива в вашем первом сообщении был мизер. И этот мизер уже исчерпан в соседних ветках. Топик получился интересный, есть что почитать. См. например про FieldDescriptor ИМХО наиболее интересная тема в данном топике т.к. раскрывает возможность построения объектных VIEW на основе синонимии/омонимии объектных идентификаторов. Еще было интересно про школы с учениками. И результат ИМХО нейтральный для обоих сторон — и там вами не пахло. Возможно в связи с отсутствием у вас контраргументов?
Re[44]: Файловые системы, файлы, приложения - устаревшие кон
Здравствуйте, shuklin, Вы писали:
S>Уважаемый, конструктива в вашем первом сообщении был мизер.
Ну яж не виноват, что ты не в состоянии его воспринять...
S> Возможно в связи с отсутствием у вас контраргументов?
С отсутствием у меня желания заниматься чужим образованием, тем более когда образовываться не хотят.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Мы уже победили, просто это еще не так заметно...
Re[30]: Файловые системы, файлы, приложения - устаревшие кон
Здравствуйте, Sinclair, Вы писали:
S>Все верно. Просто все преимущества RDBMS связаны с четким разделением адресных пространств клиента и сервера. Через этот гемоэнцэфалический барьер проникают только примитивные типы. Того же самого хочется получить и в ODBMS: невозможность вынести настоящий объект за пределы сервера. При этом внутри они должны себя вести как раз как полноценные объекты, со всеми инкапсуляциями, наследованиями и полиморфизмами.
гемоэнцэфалический барьер
S>Ну, вообще "как в датасете" мне не очень нравится. Однако, надо помнить, что датасет апдейтится при помощи дата адаптера; таким образом, на сервер фактически уезжает батч из апдейт команд.
Маленькая поправочка. Уезжает не батч, а генерится поток команд. Если какой-то update не прошел, net начинает спрашивать нужно ли эти данные или нет. Мое IMHO что это лишняя и несколько нехорошая функциональность. Она выглядит опасной. Но если Microsoft реализовал такое, значит кому-то это нужно.
GZ>>В данном случае ты сразу подразумеваешь пессимистический протокол транзакций на блокировках. Можно сделать пессимистически сериализуемой через блокировки только операции. В остальном работать по оптимистическому протоколу. S>У оптимистического протокола своих бед хватает. S>Вкратце: OODBMS полезны в основном в OLTP; всякие могучие отчеты надо гонять поверх данных, и там поведение только вредит. А OLTP куда как лучше справляется в случае пессимистичного блокировщика (если, конечно, не слишком параноидально ставить локи).
Вот с этим не особо согласен. OODBMS конечно не OLAP, срезы им делать нельзя, но из-за того что он позволяет работать недекларативно с данными, для отчетов он более удобен.
Чтобы не повторяться: здесь
GZ>>Тогда удерживать блокировки между операциями не надо, и можно строить транзакции от read commited до serializable(если с предикатными блокировками). S>Чревато. Ой как чревато.
Нормалек. И у пессимистичного, и у оптимистичного протокола свои достоинства, и свои недостатки.
Пессимистичный лучше себя ведет если есть сильная конкуренция за какие-то ресурсы на запись. Его вероятность быть успешным в таких передрягах значительно выше. Зато песня о блокирующем чтение вообще убивает. И самое поганое что если от него отвязываться, то теряешь пессимистичность и получаешь ту же версионную систему.
Мне оптимистические блокировки больше нравятся потому что их можно экспортировать с машины. Например как это делает тот-же датасет. Хотя вариант с тем что сделал Игорь в BLToolkit() мне кажется более правильным. В случае, если мы сможем добавить к экспортируемому объекту версию транзакции, то получится реализация длинных транзакций с высоким уровнем изоляции.
Ну например:
В строке сохраняем версию последней изменившей объект транзакции.
При чтении объекта:
1. Создаем транзакцию.
2. Читаем объект.
3. Если объект помечен что изменен другой незафиксированной транзакцией:
3.1 Транзакция изменившая объект началась раньше или уровень нашей транзакции Read Commited, то мы можем взять предыдущую версию объекта.
3.2 Транзакция изменившая объект началась позже, и уровень нашей транзакции Snapshot то откатываем текущую. Вероятность фиксирования транзакций значительно выше чем отката.
4. В объект помещаем номер транзакции с помощью которой он был прочитан.
5. Далее нам никакая информация о транзакции не нужна, мы можем ее выбросить. На важен только относительный номер транзакции в которой был прочитан объект.
При записи объекта:
1. Открываем новую транзакцию
2. Смотрим был ли перезаписан объект какой либо другой транзакцией чем та, которая ее прочитала. Если был, то отбиваем текущую транзакцию.
3. Если нет, то записываем новый объект и проставляем номер транзакции в запись.
4. Фиксируем транзакцию.
Фактически мы получили систему со snapshot, и самое главное, без какого-то либо состояния на сервере. Если подумать, то наверно можно еще увеличить параллельность.
Однако для Snapshot остаются Write Skew и Fantom.
Write Skew — вещь очень редкая. В принципе на нее особо внимания и не обращаешь.
Что касается фантомов, то без предикатных блокировок(пессимизмъ у нас, или оптимизмъ усе равно) мы от них не избавимся. Но так как наша задача именно избавиться от состояния, то в принципе мы их можем оптимистично облегчить. Например, в случае если кто-то решил записать данные удовлетворяющее некоторой предикатной блокировке, мы можем вмето того, чтобы пессимистично отбросить записывающую транзакцию, оптимистично убить блокировку, и пометить что все данные полученные от транзакции установившей его, нужно отбивать. Что есть достаточно правильно, поскольку если пользователь установил serializable, то именно он берет ответственность за нее, а не тот кто пытается ее нарушить.
Write Skew — штука достаточно сложноопределимая. Насколько я помню формулировка такая:
r1(x)r2(y)w1(y)w2(x). В принципе можно поступить так же. Сделать примерно такие же полублокировки на объекты, при нарушении которых транзакция которая проставили их, отлетает.
И вообще, эти две проблемы можно решить с помощью пользователя. Например, предоставить пользователю инструмент, чтобы при записи объекта, проверялось были ли изменены функционально связанные с ним объекты. Как результат, он сможет сам гибко управлять сериализацией транзакций.
Система чрезвычайно похожа на ораклоидную кроме требования, что объекты могут покидать пределы базы данных.
Re[15]: Файловые системы, файлы, приложения - устаревшие кон
Здравствуйте, Sinclair, Вы писали:
GZ>>IMHO Фактически, минимальный набор джентельмена - GZ>>1. Сканирование таблицы, GZ>>2. Чтение кортежа S>Т.е. bookmark lookup. GZ>>3. Сканирование индекса GZ>>4. Чтение значения индекса по ключу. GZ>>А фактически хрен его знает. Даже в этом минимальном наборе нет места index range search.
Ага. Просто помню что четыре операции минимум. S>А куда это он делся? Можно конечно обойтись и без него, но это сильно сужает перспективы оптимизации. Как ты можешь заметить, чтение значения по ключу — это частный случай чтения множества значений по интервалу от ID до ID. Кстати, надеюсь, ты не забыл, что индекс не обязан быть уникальным?
Да. Но просто я недопру. При сканировании по диапазону, надо получить не значение а минимальную и максимальную позицию ключа в листьях для последующего сканирования.
S>Возможно, есть еще какие-то операции, которые было бы полезно уметь на нижнем уровне, но я что-то так сразу и не соображу. GZ>>Не попадалась документашка, в которой бы было описано какие операции делаются на уровне хранилища(ну пожалуй кроме SystemR, которую современной уже не назовешь). S>Попадалась. Называется Системы баз данных. Полный курс.
Книжка видать хорошая. Надо бы посмотреть. Только я не верю что бывают книги в которых можно описать все.
Re[31]: Файловые системы, файлы, приложения - устаревшие кон
Здравствуйте, AndrewVK, Вы писали:
GZ>>гемоэнцэфалический барьер
AVK>Не сочтите за наезд, но <b>гематоэнцефалический</b> барьер
Я понял по самому термину, что он обозначает. Просто мне сильно понравилось выражение.
Re[27]: Файловые системы, файлы, приложения - устаревшие кон
Здравствуйте, Sinclair, Вы писали:
S>Все верно. Просто все преимущества RDBMS связаны с четким разделением адресных пространств клиента и сервера. Через этот гемоэнцэфалический барьер проникают только примитивные типы. Того же самого хочется получить и в ODBMS: невозможность вынести настоящий объект за пределы сервера. При этом внутри они должны себя вести как раз как полноценные объекты, со всеми инкапсуляциями, наследованиями и полиморфизмами.
А может стоит тут интерпретировать не как объекты OODB, а именно как объекты из компоненты OODB? Для Net такое управление вполне возможно. Версионификация объектов также возможна(о ней даже не забыли в манифесте ). Траблы которые получаются в РСУБД и OODB получаются достаточно сходной природы. Если вьюха или сторед процедура представить как темпоральные объекты. Решаются траблы только по разному.
Re[14]: Файловые системы, файлы, приложения - устаревшие кон
Здравствуйте, shuklin, Вы писали:
S>Это если модель не сетевая, а иерархическая — полностью согласен. В сетевой тот же запрос на основании статистики можно раскручивать с другого конца — со стороны учеников.
Для этого нужен такой язык запросов, который бы не использовал императивную навигацию. В Cerebrum он есть? S>На то она и сеть, что корня у нее нет. ИМХО РМД есть частный случай сетевой модели. А вот иерархии (дерево) действительно во многих случаях проигрывают.
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[16]: Файловые системы, файлы, приложения - устаревшие кон
Здравствуйте, GlebZ, Вы писали: S>>А куда это он делся? Можно конечно обойтись и без него, но это сильно сужает перспективы оптимизации. Как ты можешь заметить, чтение значения по ключу — это частный случай чтения множества значений по интервалу от ID до ID. Кстати, надеюсь, ты не забыл, что индекс не обязан быть уникальным? GZ>Да. Но просто я недопру. При сканировании по диапазону, надо получить не значение а минимальную и максимальную позицию ключа в листьях для последующего сканирования.
Гм. Там все банально. Для B+tree мы, получив диапазон, очень быстро спускаемся к его левой границе и начинаем последовательное сканирование страниц. Поскольку листья образуют двусвязный список, это очень эффективно. Именно поэтому хэшиндексы и стали менее популярны — нет поддержки range scan, и нет побочного эффекта упорядоченности ключей. S>>Попадалась. Называется Системы баз данных. Полный курс. GZ>Книжка видать хорошая. Надо бы посмотреть.
Обязательно посмотри! GZ>Только я не верю что бывают книги в которых можно описать все.
Там смысл не в том, что "все", а в том, что описываются все аспекты построения СУБД.
Вот оглавление, обрати внимание на главы с 11 по 16.
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Мы уже победили, просто это еще не так заметно...
Тему следующей провокации я еще не выбрал
, а что вы мне тут пытаетесь впарить не понятно ) закончились ? 
1.1.4 stable rev. 510
