Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 4 [5] 6 7 8   вперед  Ctrl      все
 Re: ООСУБД быстрее ЛЮБЫХ решений с реляционными системами ?  [new]
Lankaster
Member

Откуда:
Сообщений: 34
tygra

Однако большинству здесь присутствующих хватает возможностей СУБД на 99-100%.

Вот в этом похоже и проблема.
Как на форуме офтальмологов обсуждать особенности производства стекла.
tygra

А что, вы не верите?

Верю, но для меня такой уровень безопасности неприемлем.
tygra

А вообще получается, что вы пришли туда, откуда все уже давно ушли. И ваш метод очень похож на FoxPro 2.6 for DOS, только с ООП - все то же: логика внутри клиента, данные там же практически, обработка данных там же.... Регрессия, однако? :)
Ну хоть один пример, зачем это все????????

Чтобы повысить эффективность разработки сложных систем. Со сложной логикой и сложными структурами данных. ООП никто не отменял.
Если Вы докажете, что придумали новый, более эффективный подход к разработке - получите всемирное признание. :)
17 дек 04, 17:31    [1190106]     Ответить | Цитировать Сообщить модератору
 Re: ООСУБД быстрее ЛЮБЫХ решений с реляционными системами ?  [new]
Lankaster
Member

Откуда:
Сообщений: 34
ASCRUS

Скажем так - БД - это данные и бизнес-логика, представленные в конкретной СУБД (из за разности диалектов производителей СУБД).

То есть логика в самих данных? Это понятно. Но имеет несколько недостатков.
На первый взгляд вижу: необходимость заполнения базы данными пользователя на этапе разработки, отсутствие гибкости.
ASCRUS

Угу - он родимый и работает по 80-ому порту. Через встроенные в РСУБД веб-сервисы, систему защиты и прав, посредством вызовов хранимых процедур. Причем остальные порты вообще можно закрыть, если к БД требуется доступ только через веб-сервисы. Что тут Вы конкретно видите плохого ?

Безопасность.
17 дек 04, 17:37    [1190118]     Ответить | Цитировать Сообщить модератору
 Re: ООСУБД быстрее ЛЮБЫХ решений с реляционными системами ?  [new]
Alexey Rovdo
Member

Откуда: Москва
Сообщений: 913
www.fun4me.narod.ru
>> Ведь в случае ООСУБД все контракты конкретного абонента

И кому он нужен - никому неизвестный конкретный абонент, когда в базе их сотни тысяч? Чем он отличается от других таких же и как его искать?


И кто такая Сара
И где она живёт?
А вдруг она не курит?
А вдруг она не пьёт?


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



Кое что зависит от того, является ли коллекция контрактов абонента встроенной в объект Абонент. Т.е. это может быть:
1) Встроенная коллекция со встроенными объектами (тогда выбирая объект Абонент мы тянем и все его Контракты).
2) Встроенная коллекция ссылок на Контракты (тогда выбирая объект Абонент мы тянем фактически только перечень его Контрактов).
3) Атрибут - ссылка на коллекцию, которая содержит встроенные в нее объекты Контракт (или ссылки на них).
Как бы мы ни поступили, прямая навигация по ссылкам будет работать быстрее, чем выборка соответствующих Абоненту контрактов с использованием индекса.
Разумеется первичный поиск Абонента прийдется осуществлять по индексу и это займет скорее всего столько же (или очень близко к этому) времени, сколько и в реляционном хранилище.

Важно понять, что при малом количестве переходов по прямой навигации и преобладании индексов реляционные системы будут в выигрыше. Но существуют задачи, в которых глубина объектной структуры на порядки превышает приводимый здесь пример. И вот для них ООСУБД оказываются значительно быстрее любых РСУБД.
17 дек 04, 17:37    [1190119]     Ответить | Цитировать Сообщить модератору
 Re: ООСУБД быстрее ЛЮБЫХ решений с реляционными системами ?  [new]
www.fun4me.narod.ru
Member

Откуда: Moscow
Сообщений: 2406
>> Как бы мы ни поступили, прямая навигация по ссылкам будет работать быстрее, чем выборка соответствующих Абоненту контрактов с использованием индекса.

Вроде понятно. То есть это то же самое, как если бы в РСУБД ввести специальный тип "первичный ключ" или "ссылка", который будет использоваться вместо суррогатных первичных ключей и указывать непосредственно на физический адрес записи, без поиска по индексу?
17 дек 04, 17:43    [1190134]     Ответить | Цитировать Сообщить модератору
 Re: ООСУБД быстрее ЛЮБЫХ решений с реляционными системами ?  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
ASCRUS

Угу - он родимый и работает по 80-ому порту. Через встроенные в РСУБД веб-сервисы, систему защиты и прав, посредством вызовов хранимых процедур. Причем остальные порты вообще можно закрыть, если к БД требуется доступ только через веб-сервисы. Что тут Вы конкретно видите плохого ?

Безопасность.[/quot]
Мне почему то кажется, что проблемами безопасности протоколов должны заниматься ОС и специализированное ПО (думаю никто не мешает перед СУБД сервачек с Firewall и веб-сервером поставить), а вот проблемами прав доступа к данным и их ссылочной целостности СУБД заниматься. И это как раз и есть часть бизнес-логики, кое место только в СУБД, чтобы никто из вне БД, будь то веб, Java или SQL консоль, не мог "подправить" данные в обход логики БД, если конечно у него нет администраторских прав на отключение работы триггеров. Вы какую из безопасностей имели ввиду ? :)
17 дек 04, 17:43    [1190136]     Ответить | Цитировать Сообщить модератору
 Re: ООСУБД быстрее ЛЮБЫХ решений с реляционными системами ?  [new]
www.fun4me.narod.ru
Member

Откуда: Moscow
Сообщений: 2406
я
Вроде понятно. То есть это то же самое, как если бы в РСУБД ввести специальный тип "первичный ключ" или "ссылка", который будет использоваться вместо суррогатных первичных ключей и указывать непосредственно на физический адрес записи, без поиска по индексу?


ошибся. ещё коллекции нужны. и будет то же самое.
17 дек 04, 17:45    [1190140]     Ответить | Цитировать Сообщить модератору
 Re: ООСУБД быстрее ЛЮБЫХ решений с реляционными системами ?  [new]
tygra
Member

Откуда: Тверь (Иркутск, Край)
Сообщений: 9997
Продолжим сказочку про белого бычка :))

автор
Вот в этом похоже и проблема.
Как на форуме офтальмологов обсуждать особенности производства стекла.

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

Я правильно все написал? :)

автор
Верю, но для меня такой уровень безопасности неприемлем.

Какой - такой? Веб-сервер может стоять на другом компутере - так оно и есть. Что здесь вас пугает?
И, кстати, к ООБД вообще никак нельзя подлезть из вебсервера :)

автор
Чтобы повысить эффективность разработки сложных систем. Со сложной логикой и сложными структурами данных. ООП никто не отменял.

Никто. ООП я и так использую - только не везде, куда не плюнь, а там, для чего нужно. Для разработки - собственно для программирования клиента. Только вот ОО-данные тут ни при чем. Не надо валить все в одну кучу.
автор
Если Вы докажете, что придумали новый, более эффективный подход к разработке - получите всемирное признание

Да не я. Дейт, вроде, структуру описал, чего-то там еще.
Я то что, я просто использую архитектуру клиент-сервер. Самый универсальный и самый простой способ. :)

ЗЫ Так вы не привели ни одного примера. Как же так.

-- Tygra's --
17 дек 04, 17:52    [1190161]     Ответить | Цитировать Сообщить модератору
 Re: ООСУБД быстрее ЛЮБЫХ решений с реляционными системами ?  [new]
tygra
Member

Откуда: Тверь (Иркутск, Край)
Сообщений: 9997
автор
То есть логика в самих данных? Это понятно. Но имеет несколько недостатков.
На первый взгляд вижу: необходимость заполнения базы данными пользователя на этапе разработки, отсутствие гибкости.

По-руски расшифруйте. Так оно совсем не понятно. Из другой оперы вроде как.

-- Tygra's --
17 дек 04, 17:54    [1190166]     Ответить | Цитировать Сообщить модератору
 Re: ООСУБД быстрее ЛЮБЫХ решений с реляционными системами ?  [new]
tygra
Member

Откуда: Тверь (Иркутск, Край)
Сообщений: 9997
О! К предыдущему
Логика не в самих данных - это у вас логика в самих данных.
А у нас логика на сервере - вокруг данных. :)

-- Tygra's --
17 дек 04, 17:55    [1190169]     Ответить | Цитировать Сообщить модератору
 Re: ООСУБД быстрее ЛЮБЫХ решений с реляционными системами ?  [new]
Alexey Rovdo
Member

Откуда: Москва
Сообщений: 913
www.fun4me.narod.ru
я
Вроде понятно. То есть это то же самое, как если бы в РСУБД ввести специальный тип "первичный ключ" или "ссылка", который будет использоваться вместо суррогатных первичных ключей и указывать непосредственно на физический адрес записи, без поиска по индексу?


ошибся. ещё коллекции нужны. и будет то же самое.


Про коллекции не понял.
А остальное вполне согласуется с действительностью.
17 дек 04, 17:56    [1190173]     Ответить | Цитировать Сообщить модератору
 Re: ООСУБД быстрее ЛЮБЫХ решений с реляционными системами ?  [new]
www.fun4me.narod.ru
Member

Откуда: Moscow
Сообщений: 2406
>> Про коллекции не понял.
Возможность доступа к данным по физическму адресу ("тип "ссылка"") и возможность ссылаться из одной строки сразу на несколько подчинённых строк (коллекции), потому как иначе будет поиск по индексу, при получении подчинённых записей.
17 дек 04, 18:02    [1190192]     Ответить | Цитировать Сообщить модератору
 Re: ООСУБД быстрее ЛЮБЫХ решений с реляционными системами ?  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67463
Блог
www.fun4me.narod.ru
Вроде понятно. То есть это то же самое, как если бы в РСУБД ввести специальный тип "первичный ключ" или "ссылка", который будет использоваться вместо суррогатных первичных ключей и указывать непосредственно на физический адрес записи, без поиска по индексу?

А кто Вам сказал, что его там нет? Есть такой.
17 дек 04, 18:08    [1190206]     Ответить | Цитировать Сообщить модератору
 Re: ООСУБД быстрее ЛЮБЫХ решений с реляционными системами ?  [new]
Alexey Rovdo
Member

Откуда: Москва
Сообщений: 913
Мне кажется, что в споре об архитектуре, серверах приложений, веб-серверах и использовании "только средств СУБД" почему-то игнорируется простой факт:
Современные системы класса Oracle - это вовсе не только хранилища данных. К ним идет куча прибамбасов, которые к хранению данных никакого отношения не имеют и приплетать их возможности в качестве доказательство возможностей РСУБД некорректно.
Корень вопроса лежит в обсуждении того, следует ли обрабатывать данные на клиенте или с помощью хранимых процедур на сервере. Попробуем сконцентрироваться именно на этом.

Не вижу никакой разницы между системами:
1) РСУБД с поддержкой хранимых процедур
2) ООСУБД в связке с сервером приложений, т.е. клиент работает с базой только через сервер приложений, а уж на сервере приложений мы можем реализовать любую обработку данных. Если кому-то кажется что есть какие-то отличия давайте смотреть на ООСУБД и сервер приложений как на единый продукт, который и работает на одной машине и поставляется под одной маркой. Где отличия-то.
Могу сказать больше - преимущества налицо - две по сути различных задачи (хранение и обработка) можно разделить между серверами, сбалансировав нагрузку.
17 дек 04, 18:09    [1190210]     Ответить | Цитировать Сообщить модератору
 Re: ООСУБД быстрее ЛЮБЫХ решений с реляционными системами ?  [new]
www.fun4me.narod.ru
Member

Откуда: Moscow
Сообщений: 2406
>> А кто Вам сказал, что его там нет? Есть такой.

Я знаю, что в Oracle такой есть. Я хотел уточнить, правильно ли я понял, о каких преимуществах навигации по объектам идёт речь.
17 дек 04, 18:14    [1190220]     Ответить | Цитировать Сообщить модератору
 Re: ООСУБД быстрее ЛЮБЫХ решений с реляционными системами ?  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67463
Блог
Alexey Rovdo
Могу сказать больше - преимущества налицо - две по сути различных задачи (хранение и обработка) можно разделить между серверами, сбалансировав нагрузку.

"Две по сути разные задачи - надевание презерватива и использование его, можно разделить между носителями, сбалансировав нагрузку". В смысле - надеть на один носитель, а работать другим.

Видите ли, с одной стороны, это разделение на необходимом уровне уже произведено - существуют довольно интеллектуальные устройства "хранения". С другой же стороны, как только приходится вспомнить про эффективность - оказывается, что обработка и хранения суть крайне взаимосвязаны.
17 дек 04, 18:15    [1190222]     Ответить | Цитировать Сообщить модератору
 Re: ООСУБД быстрее ЛЮБЫХ решений с реляционными системами ?  [new]
vybegallo
Guest
Lankaster
Когда программист пишет программу он работает с объектами, не так ли. Они существуют в памяти компьютера. Это данные, правильно? Чтобы их сохранить в РБД надо преобразовать эти данные к виду таблиц. Сделать маппинг.
А если не нужно преобразовывать? Просто дать команду commit и объект уже в базе данных. Я так понимаю объектные СУБД.



Ланкастер, вы, похоже, веруете в Большую Красную Кнопку, которую юзеру достаточно нажать - и его задача будет выполнена точно и в срок. Достаточно вставить commit - и данные попадут в ООБД.
Ваша проблема в том, что книг умных вы начитались, а в коде хоть одной, хоть завалящей БД типа mysql не ковырялись. И поэтому слабо представляете себе реализацию и ее технические ограничения.
Особенно мне понравилась фраза про "какая разница, на сервере или на клиенте - в приложении !". Как насчет сотен и тысяч "приложений", одновременно работающих с одними и теми же "объектами" ? кто их будет блокировать - разблокировать, клиент ?
17 дек 04, 18:23    [1190236]     Ответить | Цитировать Сообщить модератору
 Re: ООСУБД быстрее ЛЮБЫХ решений с реляционными системами ?  [new]
Alexey Rovdo
Member

Откуда: Москва
Сообщений: 913
softwarer
www.fun4me.narod.ru
Вроде понятно. То есть это то же самое, как если бы в РСУБД ввести специальный тип "первичный ключ" или "ссылка", который будет использоваться вместо суррогатных первичных ключей и указывать непосредственно на физический адрес записи, без поиска по индексу?

А кто Вам сказал, что его там нет? Есть такой.


Нужно видимо пояснить, поскольку действительно возникает недопонимание.
Таким указателем на адрес в памяти при аналогии с РСУБД должен выступать foreign key в таблице Контракты. Т.е. если в таблице контракты мы вместо АбонентID включим поле [Физический адрес объекта Абонент], то тогда по этой ссылке мы сможем быстро обратиться к объекту Абонент, соответствующего контракту.
Но, если нам нужно хранить в составе объекта Абонент все ссылки на отвечающие ему объекты Контракт (что, кстати вовсе не очевидно), то ситуацию можно представить так: в таблице Абонент мы вводим ссылку [физический адрес списка ссылок на объекты контракт], т.е. ссылку на коллекцию, а уже сама коллекция состоит из [ссылок на физические адреса объектов котракт].
Таким образом, спозиционировавшись на объект Абонент мы перескакивая по ссылкам можем быстро находить все соответствующие контракты. В реляционной же модели без перебора индекса (select ... join ... ) нам обойтись не выйдет.
17 дек 04, 18:24    [1190238]     Ответить | Цитировать Сообщить модератору
 Re: ООСУБД быстрее ЛЮБЫХ решений с реляционными системами ?  [new]
Виталий Гаврилов
Member

Откуда: Санкт-петербург
Сообщений: 15
Константин Лисянский

А как хранят данные ООСУБД я даже и не знаю. Может, кто-то просветит?

Много не знаю, но немного расскажу, итак
Все базы данных состоят как минимум из трех файлов данных это
1. system файл данных
2. logical.log файл протокола изменений структуры данных
3. physical.log файл протокола изменений данных

иногда system состоит из двух частей, это структура, т.н. словарь, и данные.

Файлы данных обычно страничные по 16к, на одной странице обычно располагаются объекты только одного класса.
В фиксированных областях этих файлов находятся индексные секции, в которых внутреннему ID объекта сопоставляется точное положение объекта в файле данных. Если надо подробнее могу поискать в подручной литературе
17 дек 04, 18:30    [1190250]     Ответить | Цитировать Сообщить модератору
 Re: ООСУБД быстрее ЛЮБЫХ решений с реляционными системами ?  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67463
Блог
Alexey Rovdo
то ситуацию можно представить так: в таблице Абонент мы вводим ссылку [физический адрес списка ссылок на объекты контракт], т.е. ссылку на коллекцию, а уже сама коллекция состоит из [ссылок на физические адреса объектов котракт]

Ну или вводим в таблицу Абонент поле "массив физических адресов объектов Контракт"...
17 дек 04, 18:32    [1190257]     Ответить | Цитировать Сообщить модератору
 Re: ООСУБД быстрее ЛЮБЫХ решений с реляционными системами ?  [new]
tygra
Member

Откуда: Тверь (Иркутск, Край)
Сообщений: 9997
автор
Мне кажется, что в споре об архитектуре, серверах приложений, веб-серверах и использовании "только средств СУБД" почему-то игнорируется простой факт:
Современные системы класса Oracle - это вовсе не только хранилища данных. К ним идет куча прибамбасов, которые к хранению данных никакого отношения не имеют и приплетать их возможности в качестве доказательство возможностей РСУБД некорректно.

А кто приплетает? Я вообще говорю про системы класса MS SQL 2000 :)) Там ничего такого нет. И никто ничего этакого не приплетает - TSQL, PL/SQL, встроенные родные языки для обработки данных. А вы что подумали?
автор
Корень вопроса лежит в обсуждении того, следует ли обрабатывать данные на клиенте или с помощью хранимых процедур на сервере. Попробуем сконцентрироваться именно на этом.

Нет, не в этом. Некарашо - вы сами начали этот топик и назвали его ООСУБД быстрее ЛЮБЫХ решений с реляционными системами . Когда вас долго выспрашивали, чего такого конкретно дает ООСУБД и ОО-данные, вы не привели никакого примера в доказательство начатого вами вопроса топика. А теперь еще вообще пытаетесь перевести тему в совсем другое русло. Э нет, так не пойдет - давайте про ООСУБД. Либо так и скажите - нет никаких конкретных доказательств, аксиома это просто :)

автор
Не вижу никакой разницы между системами:
1) РСУБД с поддержкой хранимых процедур
2) ООСУБД в связке с сервером приложений, т.е. клиент работает с базой только через сервер приложений, а уж на сервере приложений мы можем реализовать любую обработку данных. Если кому-то кажется что есть какие-то отличия давайте смотреть на ООСУБД и сервер приложений как на единый продукт, который и работает на одной машине и поставляется под одной маркой. Где отличия-то.

Я тоже не вижу. А если нет разницы - зачем выбирать худшее (ООСУБД)??? :)
А если серьезно - конечно нет разницы.
Всего лишь
1. - РСУБД
и
1. ООСУБД
2. Сервер приложений
3. Данные обрабатываются неизвестно где и как
4. и т.д.

автор
Могу сказать больше - преимущества налицо - две по сути различных задачи (хранение и обработка) можно разделить между серверами, сбалансировав нагрузку

Дык у вас нет нагрузки на БД. Какая может быть нагрузка на хранилище данных?

============================
Итого:
Вместо того, чтобы людям, сдесь собравшимся, объяснить, чем таким круче ООСУБД, ОО-данные в виде ОО-объектов, вы ловко перевели тему на многозвенные технологии - а может никто и не заметит :))
Но по многозвенным технологиям тема совсем другая, другой топик и мы договорились, что здесь об этом не будем


-- Tygra's --
17 дек 04, 18:33    [1190261]     Ответить | Цитировать Сообщить модератору
 Re: ООСУБД быстрее ЛЮБЫХ решений с реляционными системами ?  [new]
Alexey Rovdo
Member

Откуда: Москва
Сообщений: 913
vybegallo
Lankaster
Когда программист пишет программу он работает с объектами, не так ли. Они существуют в памяти компьютера. Это данные, правильно? Чтобы их сохранить в РБД надо преобразовать эти данные к виду таблиц. Сделать маппинг.
А если не нужно преобразовывать? Просто дать команду commit и объект уже в базе данных. Я так понимаю объектные СУБД.



Ланкастер, вы, похоже, веруете в Большую Красную Кнопку, которую юзеру достаточно нажать - и его задача будет выполнена точно и в срок. Достаточно вставить commit - и данные попадут в ООБД.
Ваша проблема в том, что книг умных вы начитались, а в коде хоть одной, хоть завалящей БД типа mysql не ковырялись. И поэтому слабо представляете себе реализацию и ее технические ограничения.
Особенно мне понравилась фраза про "какая разница, на сервере или на клиенте - в приложении !". Как насчет сотен и тысяч "приложений", одновременно работающих с одними и теми же "объектами" ? кто их будет блокировать - разблокировать, клиент ?



Все названные проблемы разрешимы (в большинстве случаев - автоматическими средствами ООСУБД). Не стану говорить про большую кнопку, но явно есть неверие в само наличие этой кнопки. Господа, попробуйте это руками и вы поймете, что кнопка действительно есть, и слова по простой commit вполне справедливы.
17 дек 04, 18:34    [1190266]     Ответить | Цитировать Сообщить модератору
 Re: ООСУБД быстрее ЛЮБЫХ решений с реляционными системами ?  [new]
Alexey Rovdo
Member

Откуда: Москва
Сообщений: 913
tygra
Некарашо - вы сами начали этот топик и назвали его ООСУБД быстрее ЛЮБЫХ решений с реляционными системами . Когда вас долго выспрашивали, чего такого конкретно дает ООСУБД и ОО-данные, вы не привели никакого примера в доказательство начатого вами вопроса топика. А теперь еще вообще пытаетесь перевести тему в совсем другое русло. Э нет, так не пойдет - давайте про ООСУБД. Либо так и скажите - нет никаких конкретных доказательств, аксиома это просто :)

============================
Итого:
Вместо того, чтобы людям, сдесь собравшимся, объяснить, чем таким круче ООСУБД, ОО-данные в виде ОО-объектов, вы ловко перевели тему на многозвенные технологии - а может никто и не заметит :))
Но по многозвенным технологиям тема совсем другая, другой топик и мы договорились, что здесь об этом не будем


Ну не я поднял тему многозвенных технологий в этом топике. А в целом согласен - хотелось бы вернуться к вопросу о быстродействии, а для других аспектов создавать новые или выбирать существующие топики.

Кстати подтвержаю следующее. ОО-системы быстрее не для любых задач, а только для некоторых (там, где есть сложноструктурированные данные). Возможно в начале этого топика я это и не совсем ясно выразил (но и сам этот топик вышел из другого, так что не обессутьте - недоглядел).
17 дек 04, 18:42    [1190277]     Ответить | Цитировать Сообщить модератору
 Re: ООСУБД быстрее ЛЮБЫХ решений с реляционными системами ?  [new]
Alexey Rovdo
Member

Откуда: Москва
Сообщений: 913
tygra
Дык у вас нет нагрузки на БД. Какая может быть нагрузка на хранилище данных?


Поддержка ACID-транзакций, индексов, блокировок, целостности данных - этого то никто не отменял. И объектные системы все это поддерживают равно как и реляционные.
17 дек 04, 18:45    [1190286]     Ответить | Цитировать Сообщить модератору
 Re: ООСУБД быстрее ЛЮБЫХ решений с реляционными системами ?  [new]
Константин Лисянский
Member

Откуда: Москва
Сообщений: 902
Виталий Гаврилов
Все базы данных состоят как минимум из трех файлов данных


Это файлы операционной системы? А с сырыми устройствами ООСУБД работают? Это к вопросу производительности.

Файлы данных обычно страничные по 16к, на одной странице обычно располагаются объекты только одного класса.


РСУБД уже давно работают с блоками переменной длины. По-моему ООСУБД отстают.

В фиксированных областях этих файлов находятся индексные секции, в которых внутреннему ID объекта сопоставляется точное положение объекта в файле данных. Если надо подробнее могу поискать в подручной литературе


Ну, в общем, маловато будет. Какие бывают индексы? Есть ли понятие записи? Как осуществляется доступ по индексу? Какова роль оптимизатора?



С уважением,
Константин Лисянский
http://lissianski.narod.ru
17 дек 04, 18:49    [1190290]     Ответить | Цитировать Сообщить модератору
 Re: ООСУБД быстрее ЛЮБЫХ решений с реляционными системами ?  [new]
Alexey Rovdo
Member

Откуда: Москва
Сообщений: 913
Константин Лисянский
Виталий Гаврилов
Все базы данных состоят как минимум из трех файлов данных


Это файлы операционной системы? А с сырыми устройствами ООСУБД работают? Это к вопросу производительности.

Файлы данных обычно страничные по 16к, на одной странице обычно располагаются объекты только одного класса.


РСУБД уже давно работают с блоками переменной длины. По-моему ООСУБД отстают.

В фиксированных областях этих файлов находятся индексные секции, в которых внутреннему ID объекта сопоставляется точное положение объекта в файле данных. Если надо подробнее могу поискать в подручной литературе


Ну, в общем, маловато будет. Какие бывают индексы? Есть ли понятие записи? Как осуществляется доступ по индексу? Какова роль оптимизатора?



С уважением,
Константин Лисянский
http://lissianski.narod.ru



Ну вся эта информация сильно зависит от типа ООСУБД. Могу дать инфу о FastObjects и Versant Developer Suite на английском (документация на продукты, которую можно и скачать вместе с самими продуктами на versant.com).

Об индексах в FastObjects:


There are different types of index structures that are generally employed by databases. These range from simple indexes on sequential files, hash tables, to varying kinds of tree structures. FastObjects uses B+ tree structures to build indexes.
In a FastObjects index tree, each entry in a leaf consists of a pair of values. The first value is the index entry value, the so-called key. It represents the value of the member of a specific object. The second value is the object identity of the object, whose member has a specific value. FastObjects uses the object identities to locate objects. If an objects’ object identity is known it can be directly accessed.
The index tree is sorted by keys. The key values in the root node and the inner nodes define the interval of the keys that are stored in the associated sub-trees.
Within B+ tree indexes, there are two varieties: unique indexes and non-unique ones.
...

И еще 20 страниц с рисуночками и объяснениями.
17 дек 04, 19:06    [1190318]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 4 [5] 6 7 8   вперед  Ctrl      все
Все форумы / Сравнение СУБД Ответить