Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 9 10 11 12 13 [14] 15 16 17 18 .. 24   вперед  Ctrl
 Re: СУБД CACHE'  [new]
dimon_n2000
Guest
Павел Воронцов
Да, мы тут все про бинарное дерево толкуем. Тогда вопрос - и как же М-системы достигают сбалансированности дерева? Например при постоянном добавлении-изменении данных?


ок, В дерево - не сбалансированное дерево. Думаю, что в словаре такого термина нет вообще (хотя честно не заглядывал).

могу ответить токо, что при постоянном добавлении-изменении данных меняется оба показателя - плотность хранения данных и глубина дерева (т.е. скорость доступа)
19 ноя 04, 13:15    [1120342]     Ответить | Цитировать Сообщить модератору
 Re: СУБД CACHE'  [new]
Павел Воронцов
Member

Откуда: Новосибирск
Сообщений: 2400
Блог
Andrey K
Не гоните. В классических РСУБД модель создаёт сам разработчик он же обязан думать о связях и ключах. Она на самом деле может быть вобще не реляционной.
Это Вы о чём? Что такое "классические РСУБД"? Если Вы говорите о современных СУБД, то они не совсем Р, о чём я и написал. Как программист может создать модель? Модель чего? Модель данных - это РМД, её не надо создавать. Разработчик создаёт базу. Пользователи её используют. Как в РСУБД можно создать не реляционную базу?

Что всё это должно значить? Вы меня вконец запутали, ну вас совсем...
19 ноя 04, 13:19    [1120368]     Ответить | Цитировать Сообщить модератору
 Re: СУБД CACHE'  [new]
Павел Воронцов
Member

Откуда: Новосибирск
Сообщений: 2400
Блог
dimon_n2000
могу ответить токо, что при постоянном добавлении-изменении данных меняется оба показателя - плотность хранения данных и глубина дерева (т.е. скорость доступа)
Эрго иногда при вставке новых данных приходится перестраивать всё дерево (или бОльшую его часть), чтобы дерево осталось сбалансированным? Так?
19 ноя 04, 13:21    [1120385]     Ответить | Цитировать Сообщить модератору
 Re: СУБД CACHE'  [new]
tygra
Member

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

Почему же? Я знаю, что такое индексы и как они влияют на планы выполнения и т.д. Но как они там внутри сделаны - мне пофиг!!! Я знаю, что нужно сделать индекс по полям А и С, чтобы работало лучше - я это сделаю, и это поможет. А как уж они там внутри выполняются, чтобы повлиять на производительность - меня не касается. Должно касаться разработчиков СУБД - если есть индекс, должен работать.

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

-- Tygra's --
19 ноя 04, 13:23    [1120392]     Ответить | Цитировать Сообщить модератору
 Re: СУБД CACHE'  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
osse
Gluk (Kazan)

См. Д.Кнут "Искусство программирования" т.3 изд.2
Свою ссылку можете засунуть в ...


There is some debate as to what B stands for. The most common belief is that B may stand for balanced, as all the leaf nodes appear at the same level in the tree (this is described as a balanced tree state). B may also stand for Rudolf Bayer, the designer of this data structure.

Вежливый вы наш


Хорошо, не соблаговолите ли Вы объяснить, в таком случае, что имеется в виду под B-деревом в приложении к MUMPS. Явно не просто "сбалансированное" дерево, балансировать его можно очень по разному. Или этого твердо не знают даже сами адепты MUMPS ? Действительно, зачем ? Все уже придумано до нас. Книжки читать не обязательно.

А ссылаться на организацию данных, допуская такие вольности в трактовке, согласитесь, несколько не серьезно.

Придирчивый Вы наш.
19 ноя 04, 13:24    [1120403]     Ответить | Цитировать Сообщить модератору
 Re: СУБД CACHE'  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
Павел Воронцов
dimon_n2000
могу ответить токо, что при постоянном добавлении-изменении данных меняется оба показателя - плотность хранения данных и глубина дерева (т.е. скорость доступа)
Эрго иногда при вставке новых данных приходится перестраивать всё дерево (или бОльшую его часть), чтобы дерево осталось сбалансированным? Так?


У Б*-дерева приходится перестраивать три страницы. Все они на этот момент находятся в оперативной памяти.
19 ноя 04, 13:26    [1120411]     Ответить | Цитировать Сообщить модератору
 Re: СУБД CACHE'  [new]
dimon_n2000
Guest
Павел Воронцов
dimon_n2000
могу ответить токо, что при постоянном добавлении-изменении данных меняется оба показателя - плотность хранения данных и глубина дерева (т.е. скорость доступа)
Эрго иногда при вставке новых данных приходится перестраивать всё дерево (или бОльшую его часть), чтобы дерево осталось сбалансированным? Так?

нет, максимальное количество блоков, которые могут поменяться =
количество уровней указателей * 2. Обычно меняется два-три блока. при колчиестве блоков в десяки тысяч, как вы понимаете - это мгновенно.
19 ноя 04, 13:34    [1120465]     Ответить | Цитировать Сообщить модератору
 Re: СУБД CACHE'  [new]
dimon_n2000
Guest
Павел Воронцов
dimon_n2000
могу ответить токо, что при постоянном добавлении-изменении данных меняется оба показателя - плотность хранения данных и глубина дерева (т.е. скорость доступа)
Эрго иногда при вставке новых данных приходится перестраивать всё дерево (или бОльшую его часть), чтобы дерево осталось сбалансированным? Так?

нет, максимальное количество блоков, которые могут поменяться =
количество уровней указателей * 2. Обычно меняется два-три блока. при колчиестве блоков в десяки тысяч, как вы понимаете - это мгновенно.
19 ноя 04, 13:34    [1120466]     Ответить | Цитировать Сообщить модератору
 Re: СУБД CACHE'  [new]
Andrey K
Member

Откуда: Москва
Сообщений: 676
Павел Воронцов


Это Вы о чём? Что такое "классические РСУБД"? Если Вы говорите о современных СУБД, то они не совсем Р, о чём я и написал. Как программист может создать модель? Модель чего? Модель данных - это РМД, её не надо создавать. Разработчик создаёт базу. Пользователи её используют. Как в РСУБД можно создать не реляционную базу?

Что всё это должно значить? Вы меня вконец запутали, ну вас совсем...


По порядку

-Это Вы о чём?
Всё о том же

-Что такое "классические РСУБД"?
Уууу.. Какой вы недогадайка. (недогоняйка) :)
Это обычные РСУБД такие как MSSQL, Oracle .... Там где разработчик ручками делает таблички, ключи, связи и всё остальное. То есть проектирует модель данных в соотвествии реляционными канонами.. а может и не в соответствии..

-Модель чего?
ДАННЫХ уважаемый. ДАННЫХ :)

-Как в РСУБД можно создать не реляционную базу?
Отдохните. Сядте в кресло. Расслабьтесь. Думайте только о приятном. (кофе много не пейте... это вредно) ;)

tygra

Почему же? Я знаю, что такое индексы и как они влияют на планы выполнения и т.д. Но как они там внутри сделаны - мне пофиг!!!

СОГЛАСЕН!!! Мне тоже пофиuг, но до определённой степени! Мне например пофиг из какого материалла сделана поверхность жесткого диска. ПРРААвильно пофиг! ВСЁ пофиг... пофиг. (не буду спорить дальше с вами по этой теме... а то вы такие сурьёзные аргументы приводите... однако... боюсь)
19 ноя 04, 13:42    [1120522]     Ответить | Цитировать Сообщить модератору
 Re: СУБД CACHE'  [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
dimon_n2000
SergSuper
dimon_n2000
причем логические деревья храняться в Б деревьях, ибо это самый оптимальный способ физического хранения данных в борьбе за производительность и компактность.
...
РСУБД вынуждены хранить данные несколькими способами, поскольку изначально реляц модель предполагает отсутствие ключа, а следовательно отсутсвие идентификации записи. а раз нет идентфикации, то и обращаться можно токо к куче. чего и наблюдаем в оракл, например. как токо идентфикация пояляется (индексы например), то и хранить тут же предлагается в Б дереве, ибо оно оптимально.


Т.е. получается что иерархическая модель подобна ораклу если б там был возможен только один индекс на таблицу?

ребят, ну поаккуратней с формулировками: ну что это такое: "иерархическая модель подобна ораклу". оракл - это чё, модель чтоль уже ?

Хорошо: Т.е. получается что иерархическая модель подобна РСУБД если б там был возможен только один индекс на таблицу?

dimon, я ж просто Вам подражаю, Вы даже не представляете какой примитив пишите, Вы же когда-нибудь научитесь и Вам стыдно будет за свои слова.
С чего Вы вязли что хранение в В-деревьях Б деревьях - это самый оптимальный способ физического хранения данных в борьбе за производительность и компактность? И что вы считаете что независимо от объёма данных, специфике работы с ними может быть один, самый лучший, способ хранения?
РСУБД вынуждены хранить данные несколькими способами - да вроде один способ - по записям таблицу записывает. Или Вы это про индексы - но индексы данными не являются. И собственно никакой связи между идентификацией и индексом нет.

Andrey K
Ну по идее тогда вам не нужно знать что такое индексы вобще, как они работают и какие бывают... как их правильно построить.. как написать SQL запрос с оптимальным планом выполнения...и.т.д.
Вам это не нужно?


Конечно не нужно. Но пока приходится. В идеале СУБД должна сама анализировать какие индексы нужны и сама их делать, выше я об этом писал. Но это дело будущего, надеюсь не очень далекого.
А почему Вас так это удивляет? Я сомневаюсь что вы хорошо знаете архитектуру Windows и тем более процессора Pentium, но это же Вам не мешает писать программы?
19 ноя 04, 13:58    [1120647]     Ответить | Цитировать Сообщить модератору
 Re: СУБД CACHE'  [new]
Andrey K
Member

Откуда: Москва
Сообщений: 676
SergSuper

Но пока приходится.

В том то всё и дело. :)
19 ноя 04, 14:04    [1120694]     Ответить | Цитировать Сообщить модератору
 Re: СУБД CACHE'  [new]
Андрей Леонидович
Guest
Павел Воронцов !

Опять извините. "Прозевал" Ваш вопрос про объект без характеристик.
Объект "День" с идентификатором, определяемым разработчиком (например, в формате целого числа ГГГГММДД), вполне "жизнеспособен" без единой характеристики.
И, к тому же, "снимает" многие Ваши потенциальные примеры "соединения на лету" (не по ключам).
19 ноя 04, 14:08    [1120731]     Ответить | Цитировать Сообщить модератору
 Re: СУБД CACHE'  [new]
Андрей Леонидович
Guest
Павел Воронцов !

Класс !

Вместо простых ответов по-существу:

1) я, будучи инженером, не понимаю что теория строится для описания чего-либо;
2) какой-то "заговор фран-масонской ложи";
3) "то есть Вы признаете, что идентификатор объекта эквивалентен ключу"...

Нет, не признаю, и подробно и не один раз объяснил - почему...

В магазине, торгующем новыми книгами, может быть (?) и можно использовать ISBN в качестве первичного ключа, а в библиотеке - нет...

Я, конечно же, стремлюсь к истине, а не "владею ей". Надеюсь, по-прежнему, на сотрудничество в этом направлении.
Пока провал ключей, уж извините, очевиден. Но могут появиться какие-то новые данные, которые это опровергнут...
19 ноя 04, 14:15    [1120766]     Ответить | Цитировать Сообщить модератору
 Re: СУБД CACHE'  [new]
Andrey K
Member

Откуда: Москва
Сообщений: 676
SergSuper

С чего Вы вязли что хранение в В-деревьях Б деревьях - это самый оптимальный способ физического хранения данных в борьбе за производительность и компактность? И что вы считаете что независимо от объёма данных, специфике работы с ними может быть один, самый лучший, способ хранения?


Один из лучших. И скорость при использовании Cache это доказывает.

.... наиболее популярным подходом к организации индексов в базах данных является использование техники B-деревьев. С точки зрения внешнего логического представления B-дерево - это сбалансированное сильно ветвистое дерево во внешней памяти. Сбалансированность означает, что длина пути от корня дерева к любому его листу одна и та же.....

Вы никогда не задумывались, почему обычные индексы строятся именно с использованием такой структуры?
- Правильно :) угадали. (наверное)
А если сами данные уже упорядочены и хранятся в такой структуре?
19 ноя 04, 14:26    [1120841]     Ответить | Цитировать Сообщить модератору
 Re: СУБД CACHE'  [new]
Андрей Леонидович
Guest
tygra !

Так посодействуйте как-нибудь возвращению в конструктив. Ведь для этого какой-никакой "спикер нашей палаты" нужен...
Тем более, что Вы тоже начали активно интересоваться...
19 ноя 04, 14:30    [1120874]     Ответить | Цитировать Сообщить модератору
 Re: СУБД CACHE'  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
Oracle Table Organization Index
Начиная с 8i можно вешать на нее дополнительные индексы

В чем проблема-то ?
19 ноя 04, 14:31    [1120876]     Ответить | Цитировать Сообщить модератору
 Re: СУБД CACHE'  [new]
MOA
Member

Откуда:
Сообщений: 1099
Andrey K
В классических РСУБД модель создаёт сам разработчик он же обязан думать о связях и ключах. Она на самом деле может быть вобще не реляционной. ]

Andrey K
Это обычные РСУБД такие как MSSQL, Oracle

Превосходно. Попробуйте создать в MSSQL модель, состоящую хотя бы из одной таблицы - а сможете - так и из 10-ти - да так, чтобы она была "вобще не реляционной".
Думается, результат Вас удивит ;).
19 ноя 04, 14:31    [1120881]     Ответить | Цитировать Сообщить модератору
 Re: СУБД CACHE'  [new]
Павел Воронцов
Member

Откуда: Новосибирск
Сообщений: 2400
Блог
Андрей Леонидович
В магазине, торгующем новыми книгами, может быть (?) и можно использовать ISBN в качестве первичного ключа, а в библиотеке - нет...
Да, согласен. В библиотеке есть каталожные номера для этого. То есть бизнес диктует ограничения и мы их используем. Не больше. Но и не меньше.

Простите, но дата (значение) не может быть объектом. Она может быть лишь значением некоего атрибута объекта. Меня же интересует чему/кому соответствует объект БЕЗ атрибутов? Вот как я приводил
Object o = new Object();
Ведь он (имманентно) обладает идентификатором, не так ли? А что это такое?
19 ноя 04, 14:32    [1120889]     Ответить | Цитировать Сообщить модератору
 Re: СУБД CACHE'  [new]
Андрей Леонидович
Guest
Это видимо один из тех самых "сложных вопросов", который нужно по-чаще повторять:

... Дело в том, что в РСУБД индекс принципиально не является полноценной частью данных. То есть:

1) приложение МОЖЕТ работать без индекса, хотя НЕ МОЖЕТ работать без отношения;
2) к индексу нет доступа в терминах модели данных.

Поэтому, если железнодорожный билет будет продаваться не за одну минуту, а за один час (удалили индекс), считается, что приложение "работает". Медленно, но "работает".

Вот такие "работоспособные" приложения на sql...
19 ноя 04, 14:38    [1120931]     Ответить | Цитировать Сообщить модератору
 Re: СУБД CACHE'  [new]
Andrey K
Member

Откуда: Москва
Сообщений: 676
MOA

Превосходно. Попробуйте создать в MSSQL модель, состоящую хотя бы из одной таблицы - а сможете - так и из 10-ти - да так, чтобы она была "вобще не реляционной".
Думается, результат Вас удивит ;).

Что удивит???
Зачем пробовать создавать? Что вы хотите сказать? :) Не понимаю.
19 ноя 04, 14:38    [1120935]     Ответить | Цитировать Сообщить модератору
 Re: СУБД CACHE'  [new]
ops
Guest
Andrey K
SergSuper

С чего Вы вязли что хранение в В-деревьях Б деревьях - это самый оптимальный способ физического хранения данных в борьбе за производительность и компактность? И что вы считаете что независимо от объёма данных, специфике работы с ними может быть один, самый лучший, способ хранения?


Один из лучших. И скорость при использовании Cache это доказывает.
Вы никогда не задумывались, почему обычные индексы строятся именно с использованием такой структуры?
- Правильно :) угадали. (наверное)
А если сами данные уже упорядочены и хранятся в такой структуре?

епрст... то же самое, что кластерный индекс в mssql. аналогичная фича есть оракуле. только тм индексы могут быть не только b-tree... почему... наверное не во всех случаях поиск по дереву будет самым быстрым. похоже, что до "кешистов" еще не дошло это.
а microsoft в юконе уже другие виды индексов внедряет. к чему бы это? предположение, что в ms сидят дятлы по сравнению с интерсистем не прокатывает - положение продуктов на рынке малость разное. (разве что наоборот)...
19 ноя 04, 14:40    [1120957]     Ответить | Цитировать Сообщить модератору
 Re: СУБД CACHE'  [new]
Andrey K
Member

Откуда: Москва
Сообщений: 676
Gluk (Kazan)
Oracle Table Organization Index
Начиная с 8i можно вешать на нее дополнительные индексы

В чем проблема-то ?

Вот с этого места по подробнее. Как представлены "поля" и "записи" в такой таблице? (Table Organization Index)
19 ноя 04, 14:40    [1120960]     Ответить | Цитировать Сообщить модератору
 Re: СУБД CACHE'  [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
Andrey K
И скорость при использовании Cache это <хренение данных в Б-дереве> доказывает.

"У нас есть такие приборы...,
но мы вам о них не расскажем"

Уважаемый, где эта скорость? Как бы её пощупать? Привёл бы кто пример какой и сказал бы сколько вмемени он работает. Тогда хоть можно было бы сравнить, но вместо это я читаю только о том как круто держать данные в Б-дереве. Так что мне эта мифическая скорость ничего не доказывает.
Кстати например меня больше интересует не скорость работы, а скорость разработки.

Andrey K
]Вы никогда не задумывались, почему обычные индексы строятся именно с использованием такой структуры?


А Вы никогда не задумывались почуму данные в обычных СУБД хранятся в плоских таблицах?
- Правильно :) угадали. (наверное)
Потому что по такой таблице можно построить скока угодно деревьев, а вот по дереву еще одно дерево - тяжко
19 ноя 04, 14:41    [1120971]     Ответить | Цитировать Сообщить модератору
 Re: СУБД CACHE'  [new]
Андрей Леонидович
Guest
Павел Воронцов !

Ну это какие-то Ваши представления. Я Вам привел объект без характеристик (в Вашей терминологии без атрибутов). Экземпляры этого объекта не имеют характеристик, но идентифицированы. Похоже, что Вы тоже не поняли мои объяснения об абстрактном и конкретном объектах...
Готов помогать, чем могу, но уже завтра...
19 ноя 04, 14:45    [1120985]     Ответить | Цитировать Сообщить модератору
 Re: СУБД CACHE'  [new]
MOA
Member

Откуда:
Сообщений: 1099
>Что удивит???
То, что нереляционную модель данных построить не удастся ;). "Максимум", что можно "сделать" - добиться, чтобы отношение(я) не были бы даже и в 1-й нормальной форме. Но отношения (relation) от этого отношениями быть не перестанут, так и останутся, по определению, - множествами кортежей.
19 ноя 04, 14:47    [1121001]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 9 10 11 12 13 [14] 15 16 17 18 .. 24   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить