powered by simpleCommunicator - 2.0.59     © 2026 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / Сравнение СУБД [игнор отключен] [закрыт для гостей] / ООСУБД быстрее ЛЮБЫХ решений с реляционными системами ?
25 сообщений из 183, страница 5 из 8
ООСУБД быстрее ЛЮБЫХ решений с реляционными системами ?
    #32832910
Lankaster
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
tygra
Однако большинству здесь присутствующих хватает возможностей СУБД на 99-100%.

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

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

Чтобы повысить эффективность разработки сложных систем. Со сложной логикой и сложными структурами данных. ООП никто не отменял.
Если Вы докажете, что придумали новый, более эффективный подход к разработке - получите всемирное признание. :)
...
Рейтинг: 0 / 0
ООСУБД быстрее ЛЮБЫХ решений с реляционными системами ?
    #32832914
Lankaster
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
ASCRUS
Скажем так - БД - это данные и бизнес-логика, представленные в конкретной СУБД (из за разности диалектов производителей СУБД).

То есть логика в самих данных? Это понятно. Но имеет несколько недостатков.
На первый взгляд вижу: необходимость заполнения базы данными пользователя на этапе разработки, отсутствие гибкости.
ASCRUS
Угу - он родимый и работает по 80-ому порту. Через встроенные в РСУБД веб-сервисы, систему защиты и прав, посредством вызовов хранимых процедур. Причем остальные порты вообще можно закрыть, если к БД требуется доступ только через веб-сервисы. Что тут Вы конкретно видите плохого ?
Безопасность.
...
Рейтинг: 0 / 0
ООСУБД быстрее ЛЮБЫХ решений с реляционными системами ?
    #32832915
Alexey Rovdo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
www.fun4me.narod.ru>> Ведь в случае ООСУБД все контракты конкретного абонента

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


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


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


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

Важно понять, что при малом количестве переходов по прямой навигации и преобладании индексов реляционные системы будут в выигрыше. Но существуют задачи, в которых глубина объектной структуры на порядки превышает приводимый здесь пример. И вот для них ООСУБД оказываются значительно быстрее любых РСУБД.
...
Рейтинг: 0 / 0
ООСУБД быстрее ЛЮБЫХ решений с реляционными системами ?
    #32832922
Фотография www.fun4me.narod.ru
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
>> Как бы мы ни поступили, прямая навигация по ссылкам будет работать быстрее, чем выборка соответствующих Абоненту контрактов с использованием индекса.

Вроде понятно. То есть это то же самое, как если бы в РСУБД ввести специальный тип "первичный ключ" или "ссылка", который будет использоваться вместо суррогатных первичных ключей и указывать непосредственно на физический адрес записи, без поиска по индексу?
...
Рейтинг: 0 / 0
ООСУБД быстрее ЛЮБЫХ решений с реляционными системами ?
    #32832923
Фотография ASCRUS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ASCRUS
Угу - он родимый и работает по 80-ому порту. Через встроенные в РСУБД веб-сервисы, систему защиты и прав, посредством вызовов хранимых процедур. Причем остальные порты вообще можно закрыть, если к БД требуется доступ только через веб-сервисы. Что тут Вы конкретно видите плохого ?
Безопасность.[/quot]
Мне почему то кажется, что проблемами безопасности протоколов должны заниматься ОС и специализированное ПО (думаю никто не мешает перед СУБД сервачек с Firewall и веб-сервером поставить), а вот проблемами прав доступа к данным и их ссылочной целостности СУБД заниматься. И это как раз и есть часть бизнес-логики, кое место только в СУБД, чтобы никто из вне БД, будь то веб, Java или SQL консоль, не мог "подправить" данные в обход логики БД, если конечно у него нет администраторских прав на отключение работы триггеров. Вы какую из безопасностей имели ввиду ? :)
...
Рейтинг: 0 / 0
ООСУБД быстрее ЛЮБЫХ решений с реляционными системами ?
    #32832926
Фотография www.fun4me.narod.ru
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
яВроде понятно. То есть это то же самое, как если бы в РСУБД ввести специальный тип "первичный ключ" или "ссылка", который будет использоваться вместо суррогатных первичных ключей и указывать непосредственно на физический адрес записи, без поиска по индексу?

ошибся. ещё коллекции нужны. и будет то же самое.
...
Рейтинг: 0 / 0
ООСУБД быстрее ЛЮБЫХ решений с реляционными системами ?
    #32832935
Фотография tygra
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Продолжим сказочку про белого бычка :))

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

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

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

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

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

-- Tygra's --
...
Рейтинг: 0 / 0
ООСУБД быстрее ЛЮБЫХ решений с реляционными системами ?
    #32832937
Фотография tygra
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
авторТо есть логика в самих данных? Это понятно. Но имеет несколько недостатков.
На первый взгляд вижу: необходимость заполнения базы данными пользователя на этапе разработки, отсутствие гибкости.
По-руски расшифруйте. Так оно совсем не понятно. Из другой оперы вроде как.

-- Tygra's --
...
Рейтинг: 0 / 0
ООСУБД быстрее ЛЮБЫХ решений с реляционными системами ?
    #32832938
Фотография tygra
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
О! К предыдущему
Логика не в самих данных - это у вас логика в самих данных.
А у нас логика на сервере - вокруг данных. :)

-- Tygra's --
...
Рейтинг: 0 / 0
ООСУБД быстрее ЛЮБЫХ решений с реляционными системами ?
    #32832940
Alexey Rovdo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
www.fun4me.narod.ru яВроде понятно. То есть это то же самое, как если бы в РСУБД ввести специальный тип "первичный ключ" или "ссылка", который будет использоваться вместо суррогатных первичных ключей и указывать непосредственно на физический адрес записи, без поиска по индексу?

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

Про коллекции не понял.
А остальное вполне согласуется с действительностью.
...
Рейтинг: 0 / 0
ООСУБД быстрее ЛЮБЫХ решений с реляционными системами ?
    #32832954
Фотография www.fun4me.narod.ru
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
>> Про коллекции не понял.
Возможность доступа к данным по физическму адресу ("тип "ссылка"") и возможность ссылаться из одной строки сразу на несколько подчинённых строк (коллекции), потому как иначе будет поиск по индексу, при получении подчинённых записей.
...
Рейтинг: 0 / 0
ООСУБД быстрее ЛЮБЫХ решений с реляционными системами ?
    #32832965
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
www.fun4me.narod.ruВроде понятно. То есть это то же самое, как если бы в РСУБД ввести специальный тип "первичный ключ" или "ссылка", который будет использоваться вместо суррогатных первичных ключей и указывать непосредственно на физический адрес записи, без поиска по индексу?
А кто Вам сказал, что его там нет? Есть такой.
...
Рейтинг: 0 / 0
ООСУБД быстрее ЛЮБЫХ решений с реляционными системами ?
    #32832968
Alexey Rovdo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Мне кажется, что в споре об архитектуре, серверах приложений, веб-серверах и использовании "только средств СУБД" почему-то игнорируется простой факт:
Современные системы класса Oracle - это вовсе не только хранилища данных. К ним идет куча прибамбасов, которые к хранению данных никакого отношения не имеют и приплетать их возможности в качестве доказательство возможностей РСУБД некорректно.
Корень вопроса лежит в обсуждении того, следует ли обрабатывать данные на клиенте или с помощью хранимых процедур на сервере. Попробуем сконцентрироваться именно на этом.

Не вижу никакой разницы между системами:
1) РСУБД с поддержкой хранимых процедур
2) ООСУБД в связке с сервером приложений, т.е. клиент работает с базой только через сервер приложений, а уж на сервере приложений мы можем реализовать любую обработку данных. Если кому-то кажется что есть какие-то отличия давайте смотреть на ООСУБД и сервер приложений как на единый продукт, который и работает на одной машине и поставляется под одной маркой. Где отличия-то.
Могу сказать больше - преимущества налицо - две по сути различных задачи (хранение и обработка) можно разделить между серверами, сбалансировав нагрузку.
...
Рейтинг: 0 / 0
ООСУБД быстрее ЛЮБЫХ решений с реляционными системами ?
    #32832976
Фотография www.fun4me.narod.ru
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
>> А кто Вам сказал, что его там нет? Есть такой.

Я знаю, что в Oracle такой есть. Я хотел уточнить, правильно ли я понял, о каких преимуществах навигации по объектам идёт речь.
...
Рейтинг: 0 / 0
ООСУБД быстрее ЛЮБЫХ решений с реляционными системами ?
    #32832978
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Alexey RovdoМогу сказать больше - преимущества налицо - две по сути различных задачи (хранение и обработка) можно разделить между серверами, сбалансировав нагрузку.
"Две по сути разные задачи - надевание презерватива и использование его, можно разделить между носителями, сбалансировав нагрузку". В смысле - надеть на один носитель, а работать другим.

Видите ли, с одной стороны, это разделение на необходимом уровне уже произведено - существуют довольно интеллектуальные устройства "хранения". С другой же стороны, как только приходится вспомнить про эффективность - оказывается, что обработка и хранения суть крайне взаимосвязаны.
...
Рейтинг: 0 / 0
ООСУБД быстрее ЛЮБЫХ решений с реляционными системами ?
    #32832987
vybegallo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
LankasterКогда программист пишет программу он работает с объектами, не так ли. Они существуют в памяти компьютера. Это данные, правильно? Чтобы их сохранить в РБД надо преобразовать эти данные к виду таблиц. Сделать маппинг.
А если не нужно преобразовывать? Просто дать команду commit и объект уже в базе данных. Я так понимаю объектные СУБД.



Ланкастер, вы, похоже, веруете в Большую Красную Кнопку, которую юзеру достаточно нажать - и его задача будет выполнена точно и в срок. Достаточно вставить commit - и данные попадут в ООБД.
Ваша проблема в том, что книг умных вы начитались, а в коде хоть одной, хоть завалящей БД типа mysql не ковырялись. И поэтому слабо представляете себе реализацию и ее технические ограничения.
Особенно мне понравилась фраза про "какая разница, на сервере или на клиенте - в приложении !". Как насчет сотен и тысяч "приложений", одновременно работающих с одними и теми же "объектами" ? кто их будет блокировать - разблокировать, клиент ?
...
Рейтинг: 0 / 0
ООСУБД быстрее ЛЮБЫХ решений с реляционными системами ?
    #32832989
Alexey Rovdo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
softwarer www.fun4me.narod.ruВроде понятно. То есть это то же самое, как если бы в РСУБД ввести специальный тип "первичный ключ" или "ссылка", который будет использоваться вместо суррогатных первичных ключей и указывать непосредственно на физический адрес записи, без поиска по индексу?
А кто Вам сказал, что его там нет? Есть такой.

Нужно видимо пояснить, поскольку действительно возникает недопонимание.
Таким указателем на адрес в памяти при аналогии с РСУБД должен выступать foreign key в таблице Контракты. Т.е. если в таблице контракты мы вместо АбонентID включим поле [Физический адрес объекта Абонент], то тогда по этой ссылке мы сможем быстро обратиться к объекту Абонент, соответствующего контракту.
Но, если нам нужно хранить в составе объекта Абонент все ссылки на отвечающие ему объекты Контракт (что, кстати вовсе не очевидно), то ситуацию можно представить так: в таблице Абонент мы вводим ссылку [физический адрес списка ссылок на объекты контракт], т.е. ссылку на коллекцию, а уже сама коллекция состоит из [ссылок на физические адреса объектов котракт].
Таким образом, спозиционировавшись на объект Абонент мы перескакивая по ссылкам можем быстро находить все соответствующие контракты. В реляционной же модели без перебора индекса (select ... join ... ) нам обойтись не выйдет.
...
Рейтинг: 0 / 0
ООСУБД быстрее ЛЮБЫХ решений с реляционными системами ?
    #32832999
Константин Лисянский
А как хранят данные ООСУБД я даже и не знаю. Может, кто-то просветит?

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

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

Файлы данных обычно страничные по 16к, на одной странице обычно располагаются объекты только одного класса.
В фиксированных областях этих файлов находятся индексные секции, в которых внутреннему ID объекта сопоставляется точное положение объекта в файле данных. Если надо подробнее могу поискать в подручной литературе
...
Рейтинг: 0 / 0
ООСУБД быстрее ЛЮБЫХ решений с реляционными системами ?
    #32833004
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Alexey Rovdoто ситуацию можно представить так: в таблице Абонент мы вводим ссылку [физический адрес списка ссылок на объекты контракт], т.е. ссылку на коллекцию, а уже сама коллекция состоит из [ссылок на физические адреса объектов котракт]
Ну или вводим в таблицу Абонент поле "массив физических адресов объектов Контракт"...
...
Рейтинг: 0 / 0
ООСУБД быстрее ЛЮБЫХ решений с реляционными системами ?
    #32833006
Фотография tygra
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
авторМне кажется, что в споре об архитектуре, серверах приложений, веб-серверах и использовании "только средств СУБД" почему-то игнорируется простой факт:
Современные системы класса Oracle - это вовсе не только хранилища данных. К ним идет куча прибамбасов, которые к хранению данных никакого отношения не имеют и приплетать их возможности в качестве доказательство возможностей РСУБД некорректно.
А кто приплетает? Я вообще говорю про системы класса MS SQL 2000 :)) Там ничего такого нет. И никто ничего этакого не приплетает - TSQL, PL/SQL, встроенные родные языки для обработки данных. А вы что подумали?
авторКорень вопроса лежит в обсуждении того, следует ли обрабатывать данные на клиенте или с помощью хранимых процедур на сервере. Попробуем сконцентрироваться именно на этом.
Нет, не в этом. Некарашо - вы сами начали этот топик и назвали его ООСУБД быстрее ЛЮБЫХ решений с реляционными системами . Когда вас долго выспрашивали, чего такого конкретно дает ООСУБД и ОО-данные, вы не привели никакого примера в доказательство начатого вами вопроса топика. А теперь еще вообще пытаетесь перевести тему в совсем другое русло. Э нет, так не пойдет - давайте про ООСУБД. Либо так и скажите - нет никаких конкретных доказательств, аксиома это просто :)

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

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

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


-- Tygra's --
...
Рейтинг: 0 / 0
ООСУБД быстрее ЛЮБЫХ решений с реляционными системами ?
    #32833010
Alexey Rovdo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
vybegallo LankasterКогда программист пишет программу он работает с объектами, не так ли. Они существуют в памяти компьютера. Это данные, правильно? Чтобы их сохранить в РБД надо преобразовать эти данные к виду таблиц. Сделать маппинг.
А если не нужно преобразовывать? Просто дать команду commit и объект уже в базе данных. Я так понимаю объектные СУБД.



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


Все названные проблемы разрешимы (в большинстве случаев - автоматическими средствами ООСУБД). Не стану говорить про большую кнопку, но явно есть неверие в само наличие этой кнопки. Господа, попробуйте это руками и вы поймете, что кнопка действительно есть, и слова по простой commit вполне справедливы.
...
Рейтинг: 0 / 0
ООСУБД быстрее ЛЮБЫХ решений с реляционными системами ?
    #32833019
Alexey Rovdo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
tygra Некарашо - вы сами начали этот топик и назвали его ООСУБД быстрее ЛЮБЫХ решений с реляционными системами . Когда вас долго выспрашивали, чего такого конкретно дает ООСУБД и ОО-данные, вы не привели никакого примера в доказательство начатого вами вопроса топика. А теперь еще вообще пытаетесь перевести тему в совсем другое русло. Э нет, так не пойдет - давайте про ООСУБД. Либо так и скажите - нет никаких конкретных доказательств, аксиома это просто :)

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

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

Кстати подтвержаю следующее. ОО-системы быстрее не для любых задач, а только для некоторых (там, где есть сложноструктурированные данные). Возможно в начале этого топика я это и не совсем ясно выразил (но и сам этот топик вышел из другого, так что не обессутьте - недоглядел).
...
Рейтинг: 0 / 0
ООСУБД быстрее ЛЮБЫХ решений с реляционными системами ?
    #32833027
Alexey Rovdo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
tygraДык у вас нет нагрузки на БД. Какая может быть нагрузка на хранилище данных?

Поддержка ACID-транзакций, индексов, блокировок, целостности данных - этого то никто не отменял. И объектные системы все это поддерживают равно как и реляционные.
...
Рейтинг: 0 / 0
ООСУБД быстрее ЛЮБЫХ решений с реляционными системами ?
    #32833031
Константин Лисянский
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Виталий ГавриловВсе базы данных состоят как минимум из трех файлов данных

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

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

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

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

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



С уважением,
Константин Лисянский
http://lissianski.narod.ru
...
Рейтинг: 0 / 0
ООСУБД быстрее ЛЮБЫХ решений с реляционными системами ?
    #32833047
Alexey Rovdo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Константин Лисянский Виталий ГавриловВсе базы данных состоят как минимум из трех файлов данных

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

Файлы данных обычно страничные по 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 страниц с рисуночками и объяснениями.
...
Рейтинг: 0 / 0
25 сообщений из 183, страница 5 из 8
Форумы / Сравнение СУБД [игнор отключен] [закрыт для гостей] / ООСУБД быстрее ЛЮБЫХ решений с реляционными системами ?
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]