Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 13 14 15 16 17 [18] 19 20 21 22 .. 24   вперед  Ctrl
 Re: СУБД CACHE'  [new]
www.fun4me.narod.ru
Member

Откуда: Moscow
Сообщений: 2406
Таблица с некоторыми данными в каждый момент своей жизни будет определять некоторое отношение на декартовом произведении областей определений своих столбцов. Равно как и запрос по этой таблице так же будет определять некоторое отношение. Я могу использовать операции над множествами при работе с такими отношениями и, по моему, этого вполне достаточно. Я могу отобразить любые операции реляционной алгебры на язык SQL. Если я могу использовать реляционные методы, значит реляционная модель поддерживается.
20 ноя 04, 20:27    [1123178]     Ответить | Цитировать Сообщить модератору
 Re: СУБД CACHE'  [new]
www.fun4me.narod.ru
Member

Откуда: Moscow
Сообщений: 2406
И, imho, блокировочник более соответствует РМД, чем версионник. Как это - "версионные отношения"? Какая-то трёхмерность получается...
20 ноя 04, 20:46    [1123184]     Ответить | Цитировать Сообщить модератору
 Re: СУБД CACHE'  [new]
Рыжий Кот
Member

Откуда: Мягкий Диван; [забанен] Рустамом; [разбанен] П02;
Сообщений: 21678
Уважаемый Андрей Леонидович.
Мне очень нравится следить за ходом Вашей мысли в том смысле,
что мне становится веселее, скучать не приходится.

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

Вы рассуждаете как человек, уставший развиваться и разбираться;
вот вы хотите, чтобы стало легко и все...

Картинка с другого сайта.
20 ноя 04, 21:14    [1123198]     Ответить | Цитировать Сообщить модератору
 Re: СУБД CACHE'  [new]
vadiminfo
Member

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

Даст.
Собственно не понимаю почему он должен не давать и при чем тут отношения

Не обращайте внимания. Это попытка называть рел моделью только то, что соответсвует базовой реляционной модели 1971. Там отношение - это множество, а потому не может содержать дубликатов (множества в математике не содержат дубликатов). Однако, с тех пор были расширения в РМД (в том числе и самим Коддом), в частности, в информационных технологиях давно используют мультимножества, которые допускают дубликаты. Кроме того, термин реляционная модель - имя класса моделей по основным признакам структуризации данных, поддержки ограничений целостности и манипулированию данными. Базовую рел модель в плане отношений - множеств без расширений была реализована, например, в Парадоксе 4 в досе. С тех пор утекло много воды. Только представьте проверку на наличие дубликатов, если не объявлены ключи, т.е. по умолчанию ключ - это все поля, если не объявлено других. Кроме того, не всегда надо, чтобы и запрос устранял дубли (а он всегда возвращает отношение).
Т.е. это просто Вам подбрасывают уловку с подменой понятий, чтобы доказать что в MS SQL, якобы не РМД, раз она не соответствует только самым ранним представлениям об этой модели. Хотят представить РМД, как нечто окаменелое, не допускающее развитие, чтобы потом пытаться критиковать эти ранние представления. Естественно, они были не совсем адекватны, раз потребовались расширения. На самом деле, в MS SQL как и Оракле расширенная РМД, позволяющая реализовать в частности и базовую, если очень надо.
www.fun4me.narod.ru

И, imho, блокировочник более соответствует РМД, чем версионник. Как это - "версионные отношения"? Какая-то трёхмерность получается...

Механизм реализации модели транзакции никак не определяется реляционной моделью данных. Более того, сторонники ООСУБД, приписывают рел модели якобы недостаток, связанный с тем, что РСУБД в основном ориентированы на кратковременные транзакции. Но и это никак не следует из рел модели. Соответствие или несоответствие рел модели определяется ни блокировочностью, ни версионностью, а чем-то другим, на логическом уровне
20 ноя 04, 22:48    [1123253]     Ответить | Цитировать Сообщить модератору
 Re: СУБД CACHE'  [new]
Andreww
Member [заблокирован]

Откуда:
Сообщений: 1752
2 Andrey K

>Да почему же вы продолжаете утверждать, что я говорил что они ВСЕГДА >оптимальны для любых данных!? Блин не говорил я такого. Что за глупость.

>Я такого не говорил! :) Где вы это увидили? Где? Покажите.
>Почему мне приводят всё время примеры, что я что то гдето говорил, хотя я на >самом деле этого не говорил. Что за глупости всё время указывать мне на то что >я якобы говорил... Вы невнимательно читаете? ... нах.. мне эти кривотолки.. если >вы не хотите понимать...


Вот он, ваш диалог с SergSuper


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


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

По-моему ваши слова ?

А теперь выясняется, что далеко не один. И совсем не всегда самый лучший. Хранение информации только в Б-деревьях (или в Б*) вообще говоря может давать значительные нак. расходы.

Строго говоря Б-деревья (точнее Б*) подходят только для организации индексов в некоторых случаях, а хранить в них данные в большинстве случаев невыгодно.

Не только читать но и высказываться надо вдумчиво :)

Про описание "накладной"

>>Коментариев по выше описанному НЕ БУДЕТ! ООП можно применять
>>при проектировании приложения для работы с БД.

Да и не будет комментариев, ибо это один из возможных способов декомпозиции системы на объекты и их спецификация (примерная). Декомпозиция (состав и контракты классов) могут быть другие в другом бизнес-процессе и т.п. Придираться тут просто глупо, это ваше видение системы (по которой кстати никто требований не выдвигал).

>>Только не нужно мне потом говорить, что я не отличаю что такое обработчик >>события... что такое метод...
>>я всё сжато описал, что бы писанину не разводить. Умный поймёт суть, а дурак >>к словам прие..тца.

Да не собираюся я к словам придираться, когда не к чему придраться обычно ещё и к орфографии придираются :)

Вы вообще-то обещали рассказать как эти объекты будут ХРАНИТСЯ НА НОСИТЕЛЕ. Спроецировать их на деревья и т.п.

А спецификаций таких ещё можно штук 100 набросать и все будут правильными (тем более в отсутствии требований к системе).
21 ноя 04, 00:54    [1123295]     Ответить | Цитировать Сообщить модератору
 Re: СУБД CACHE'  [new]
c127
Guest
2 Андрей Леонидович

>Я окончил Московский авиационный технологический институт в 1977 году. Видимо поэтому (?) - я идиот (опять).

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

А ответа на остальные мои вопросы все нет.
21 ноя 04, 01:26    [1123302]     Ответить | Цитировать Сообщить модератору
 Re: СУБД CACHE'  [new]
Andrey K
Member

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

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

Где вы эту кашу насобирали. Укажите по ссылкам. :) Где чьи слова?

Andreww

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

По-моему ваши слова ?

ПРАВИЛЬНО МОИ! Правильно ОДИН ИЗ лучших. Где вы видите что я утверждал, что он ЕДИНСТВЕННО ПРАВИЛЬНЫЙ!? для использования данных независимо от их специфики!? Где я писал что он единственно правильный?

У вас проблема с восприятием текста в письменном виде? Или вы как Партос "Я дерусь потому что я дерусь!" (См. Три Мушкетёра)

Andreww

Не только читать но и высказываться надо вдумчиво :)

Высказался я вдумчиво. А вы прочитали.. и истолковали всё по своему. (НЕ ВДУМЧИВО)

Andreww

Про описание "накладной"

>>Коментариев по выше описанному НЕ БУДЕТ! ООП можно применять
>>при проектировании приложения для работы с БД.

Да и не будет комментариев, ибо это один из возможных способов декомпозиции системы на объекты и их спецификация (примерная). Декомпозиция (состав и контракты классов) могут быть другие в другом бизнес-процессе и т.п. Придираться тут просто глупо, это ваше видение системы (по которой кстати никто требований не выдвигал).

Правильно. :) Но кто то попросил показать, что это возможно, и я показал.

Andreww

Да не собираюся я к словам придираться, когда не к чему придраться обычно ещё и к орфографии придираются :)

Да это я уже заметил. ;)

Andreww

Вы вообще-то обещали рассказать как эти объекты будут ХРАНИТСЯ НА НОСИТЕЛЕ. Спроецировать их на деревья и т.п.

Вобще то я ничего вам не должен и ничего не обещал!!!!
А вы меня попросили описать именно объектную модель - её я вам и описал.
У вас в голове бардак. Сумбур. Каша Вы путаете просто. Не удивительно что вы не умеете "классифицировать"

Andreww

А спецификаций таких ещё можно штук 100 набросать и все будут правильными (тем более в отсутствии требований к системе).

:) Требования к системе известны. Я уже давно занимаюсь автоматизацией торговой деятельности предприятий. 100 штук не набросаете... всегда есть одна наиболее правильная модель...

...тем более в отсутствии требований к системе Тогда зачем вы её просили описать? Сформулируйте требования сначала. Не задавайте глупых вопросов.
21 ноя 04, 10:52    [1123363]     Ответить | Цитировать Сообщить модератору
 Re: СУБД CACHE'  [new]
Andrey K
Member

Откуда: Москва
Сообщений: 676
www.fun4me.narod.ru
Если я могу использовать реляционные методы, значит реляционная модель поддерживается.

Вот :) Золотые слова.
Только не "поддерживается" а "используется"..... а то опять до слов дое...ца.
21 ноя 04, 10:59    [1123368]     Ответить | Цитировать Сообщить модератору
 Re: СУБД CACHE'  [new]
Andreww
Member [заблокирован]

Откуда:
Сообщений: 1752
2 Andrey K

>>По-моему ваши слова ?

>ПРАВИЛЬНО МОИ! Правильно ОДИН ИЗ лучших.
Где вы видите что я утверждал, что он ЕДИНСТВЕННО ПРАВИЛЬНЫЙ!? для использования данных независимо от их специфики!? Где я писал что он единственно правильный?

А выяснилось, что вы ничего не смыслите в балансировке этих самых деревьев (ссылку и конспективное изложение этих вопросов я привёл) и строго говоря в многопользовательской системе этот способ ХРАНЕНИЯ данных один из ХУДШИХ :)

Уметь надо признавать свои ошибки.

>>Правильно. :) Но кто то попросил показать, что это возможно, и я
показал.

Я попросил показать СПОСОБ ХРАНЕНИЯ НА НОСИТЕЛЕ, помните.
Вы начали что-то мямлить про три дерева, потом поняли какую фигню сморозили и переключились на объектную декомпозицию. Про которую вас НИКТО не спрашивал.

>>Да не собираюся я к словам придираться, когда не к чему придраться обычно ещё и к орфографии придираются :)

>Да это я уже заметил. ;)

Ещё иногда хамить начинают ;)

>>Вы вообще-то обещали рассказать как эти объекты будут ХРАНИТСЯ НА НОСИТЕЛЕ. Спроецировать их на деревья и т.п.

>Вобще то я ничего вам не должен и ничего не обещал!!!!

Ок. Не обещали. И не показали. Всё правильно.

>>А вы меня попросили описать именно объектную модель - её я вам и описал.

Я вас просил показать КАК ВЫ БУДЕТЕ ХРАНИТЬ этот объект, а не расписывать его иерархию наследования и методы. Забыли ? Слишком ВДУМЧИВО читали ? Ссылку привести ?

>>А спецификаций таких ещё можно штук 100 набросать и все будут правильными (тем более в отсутствии требований к системе).

>>:) Требования к системе известны.

Я вообщето вам их не приводил. Про партиционный учёт например вы всё взяли из головы.

>>Я уже давно занимаюсь автоматизацией торговой деятельности предприятий. 100 штук не набросаете... всегда есть одна наиболее правильная модель...

100 штук правильных и одна из них будет наиболее правильная.

>>...тем более в отсутствии требований к системе Тогда зачем вы её просили описать? Сформулируйте требования сначала. Не задавайте глупых вопросов.

Да не просил я систему ОПИСЫВАТЬ. Я просил показать как такой ОБЪЕКТ может ХРАНИТСЯ НА НОСИТЕЛЕ в B-деревьях.
21 ноя 04, 12:05    [1123388]     Ответить | Цитировать Сообщить модератору
 Re: СУБД CACHE'  [new]
Андрей Леонидович
Guest
Молодцы !

Еще дальше продвинулись в изучении РМД. Есть еще некоторые шероховатости (типа "1971"), и не понимание "расширений в РМД (в том числе самим Коддом)". То есть Кодда, похоже, еще не все прочитали, или прочитали не вдумчиво (как преподаватель рассказал, так пусть и будет).

При повторном изучении работ Кодда (1970, 1979) обратите внимание на следующее.
В первой работе описание модели данных заканчивается вторым абзацем на стр. 380. А дальше:

There are usually many alternative ways in which a relational model may be established for data bank.

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

а) Без ключей невозможно (сложно) обрабатывать отношения на компьютере ?
ИЛИ
б) Без ключей сложно отразить данные о реальном мире в базе данных ?

Во второй работе Кодд явно включил ПЕРВИЧНЫЕ ключи в описание модели данных. Причем явно отнес их к элементам СТРУКТУРЫ данных. То есть отношение (теперь это уже некое "отношение Кодда") не может не иметь первичного ключа.

[Таким образом, MS SQL и другие "реляционные" СУБД не поддерживают реляционную модель в обеих интерпретациях:

- если первичный ключ разрешается не объявлять, то должно поддерживаться "просто отношение";
- либо следует поддерживать "отношение Кодда", то есть не допускать отношения без первичного ключа.]

И, наконец, Кодд принципиально больше не использует понятие "внешний ключ". Вместо этого (стр. 400, Rule 2) он очень туманно и косвенно предлагает (опять (!), как и ДО 1970) использовать отношения, представляющие связи сущностей (см. мой план формализации РМД в дискуссии "Сравнение ... СУБД").

P.S. А про "семейства" просто класс ! Вот такая вот "хорошо формализованная РМД".
21 ноя 04, 14:22    [1123508]     Ответить | Цитировать Сообщить модератору
 Re: СУБД CACHE'  [new]
Андрей Леонидович
Guest
Рыжий кот !

Может я и остановился в своем развитии. Постараюсь исправиться. Главное, что Вы постоянно учитесь. Рад за Вас !
21 ноя 04, 14:24    [1123509]     Ответить | Цитировать Сообщить модератору
 Re: СУБД CACHE'  [new]
Андрей Леонидович
Guest
Молодец с127 !

Видно, что прочитал все, что нужно. Возразить нечего. А соглашаться стыдно. А вот мне не стыдно было "проявить незнание", когда я изучал теорию баз данных (и продолжаю изучать, конечно).
Я поэтому и не обижаюсь ни на кого. Ведь вся "критика" в мой адрес направлена не против моей личности или моего интеллекта. Оппоненты просто в такой форме сообщают мне, что я не знаю теорию баз данных, а они ЗНАЮТ. На это нельзя обижаться. Это нужно исправлять, пополняя свои знания.
И я нисколько не сомневаюсь, что многие участники двух "наших" тем весьма серьезно пополнили свои знания, хотя зачастую всячески (как, например, Andreww) демонстрируют, что и до этого все знали и понимали.
Желаю творческих успехов.
21 ноя 04, 14:59    [1123528]     Ответить | Цитировать Сообщить модератору
 Re: СУБД CACHE'  [new]
Андрей Леонидович
Guest
Извиняюсь:

P.S. А про "класс моделей" просто класс ! Вот такая вот "хорошо формализованная РМД".

Теперь буду знать: хорошо формализованный КЛАСС МОДЕЛЕЙ.
Каждая из которых, судя по всему, одинаково хорошо формализована.

Прав Рыжий кот. 34 года не срок. Еще мучиться и мучиться, чтобы потом, наконец, может быть получить простой доступ к данным...
21 ноя 04, 15:15    [1123544]     Ответить | Цитировать Сообщить модератору
 Re: СУБД CACHE'  [new]
Андрей Леонидович
Guest
Рыжий Кот !

Ваша беда (а в профессиональном плане - это действительно беда) заключается в том, что проблема-то решается гораздо быстрее, чем Вы думаете. И, продолжая придерживаться ортодоксальных позиций, Вы можете остаться на обочине. Я бы даже сказал - в кювете.
21 ноя 04, 16:00    [1123567]     Ответить | Цитировать Сообщить модератору
 Re: СУБД CACHE'  [new]
c127
Guest
2 Андрей Леонидович

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

Это опять только слова. А вот где бы все-таки ответы на мои вопросы посмотреть? Ну не отвечает Андрей Леонидович на вопросы, хоть тресни.
22 ноя 04, 02:25    [1123845]     Ответить | Цитировать Сообщить модератору
 Re: СУБД CACHE'  [new]
ops
Guest
Андрей Леонидович
Опс, прямо невозможно оторваться...
Каждый новый посетитель наступает на одни и те же грабли...

ops !

Вы правы: если реляционная технология будет неоптимальной и тормозной, то придется именно менять СУБД, причем на не реляционную.

;) как только станут появляться такие задачи в глобальных масштабах, то так и сделают. пока же, извините, рсубд хватает за глаза. а оосубд надо еще тестить и тестить. но, как показывает практика, все "ОО" по сравнению с остальным более тормозное, требует больше аппаратных ресурсов. хотя и проще в сопровождении (и то можно поспорить ;) ).
п.с.: а на первое мое сообщение комментарий по существу будет?
22 ноя 04, 06:33    [1123881]     Ответить | Цитировать Сообщить модератору
 Re: СУБД CACHE'  [new]
ops
Guest
Андрей Леонидович
И, продолжая придерживаться ортодоксальных позиций, Вы можете остаться на обочине. Я бы даже сказал - в кювете.

оптимистичный прогноз... Вы можете гарантировать, что разогнавшись при смене позиций не врежешься в принципиально непробиваемую стену?

наверное я плохо искал, но я так и не нашел, информацию по тому, как "многомерные данные" кеша хранятся в памяти и на носителях, какие общие принципы хранения и доступа. дайте кто-нибудь ссылку, плз...
то, что есть на www.intersystems.ru - проезд по ушам, прокатывающий может быть на руководстве, но не на технических специалистах.
22 ноя 04, 07:24    [1123912]     Ответить | Цитировать Сообщить модератору
 Re: СУБД CACHE'  [new]
Павел Воронцов
Member

Откуда: Новосибирск
Сообщений: 2402
Блог
Паноптикум.

Мне почему-то кажется, что у Андрея Леонидовича работа такая. Уж очень профессионально он всем мозги компостирует. А когда ему не удаётся прокомпостировать, он разостно заявляет, что мы продвинулись ещё дальше в понимании и желает успехов. Браво.

Андрей Леонидович, я могу использовать и такую терминологию, мне по барабану. Пусть будет Объект/Экземпляр, а не Класс/Объект (можно было бы ещё Класс/Экземпляр, тоже смешно). То, что Вы не понимаете, что экземпляр объекта Дата (или что там - День?) таки да, имеет атрибут, дело Ваше. Пусть. Теперь к Вашему примеру. У меня вопрос. А в чём тут счастье? Давайте пока отрешимся от прославлений или проклятий РМД и Вы нам просто покажете где тут всеобщий покой и нирвана. Ну вот хранятся в базе экземпляры этих объектов. Чудно. Каженный объект имеет ОИД. Великолепно. Всё это хранится в дереве (или нет? Не в дереве? Может не в этом суть, не в деревьях?). А дальше-то что?

Неужто i $$c($o,$a,$v) d ^P q ?!

Можно я сделаю предположение? Вы нам хотите что-то продать? Так назовите продукт! Мы все его купим, у всех будет единая технология и тогда (о счастье!) все наши системы смогут общаться совершенно спокойно, не боясь трудностей перевода и не нуждаясь в программистах.
22 ноя 04, 08:48    [1124014]     Ответить | Цитировать Сообщить модератору
 Re: СУБД CACHE'  [new]
Andrey K
Member

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

А выяснилось, что вы ничего не смыслите в балансировке этих самых деревьев (ссылку и конспективное изложение этих вопросов я привёл) и строго говоря в многопользовательской системе этот способ ХРАНЕНИЯ данных один из ХУДШИХ :)

Как вы любите в крайности кидаться. Вы не правы раз такой метод применяют для построения индексов (при чём достаточно широко) (и рассматривают во всех классических примерах) значит он не является худшим. Мне как разработчику грубоко по барабану, на самом деле как именно будет построено дерево... какая у него будет структура.. и как оно будет сбалансированно. Это действительно задача самого ядра БД я не должен над этим заморачиваться вообще! Важно как я собираюсь применять индексы построенные при помощи таких деревьев.
Ещё раз повторю я привел именно В-дерево как пример. :) И я не утверждал, что его использование будет наилучшим во всех случаях.

Andreww

Я попросил показать СПОСОБ ХРАНЕНИЯ НА НОСИТЕЛЕ, помните.
Вы начали что-то мямлить про три дерева, потом поняли какую фигню сморозили и переключились на объектную декомпозицию. Про которую вас НИКТО не спрашивал.

Вы действительно не просили но были следующие мнения что с БД нельзя работать на объектном уровне. Смотрите внимательно этот пост. Здесь dimon_n2000 и Павел Воронцов. https://www.sql.ru/forum/actualthread.aspx?bid=10&tid=31638&pg=10#1115848

Andreww

Я вас просил показать КАК ВЫ БУДЕТЕ ХРАНИТЬ этот объект, а не расписывать его иерархию наследования и методы. Забыли ? Слишком ВДУМЧИВО читали ? Ссылку привести ?

Да :) действительно читал вдумчиво но авторов перепутал. Так что извините. :)

Andreww

Да не просил я систему ОПИСЫВАТЬ. Я просил показать как такой ОБЪЕКТ может ХРАНИТСЯ НА НОСИТЕЛЕ в B-деревьях.

Да да. Извиняюсь. Никто не просил. Просто было мнение что систему нельзя так описать. Это было не ваше мнение.

По вашему вопросу:
Объект на объектном уровне может быть вобще не привязан ни к какому конкретному В-дереву (любому дереву)! Он может быть связан как с одним деревом так и с множеством. Что тут непонятного? Я вам сказал что такие атрибуты как "артикул", "цена", .... полюбому хранятся в разных делевьях. А вы мне сказали что это смешно.
У меня к вам встречный вопрос. Покажите как вы собираетесь хранить несколько атрибутов в одном дереве! На мой взгляд это то же самое что кластерный индекс в MSSQL или index organized table в Oracle ..... ТО ЕСТЬ ЭТО СПОСОБ УПОРЯДОЧЕННО ХРАНИТЬ ЗАПИСИ ТАБЛИЦЫ При такой организации хранения данных, дополнительные индексы нужны будут полюбому.

Покажите как вы собираетесь хранить атрибуты "артикул", "цена", ... в одном дереве. Что это за дерево такое?
22 ноя 04, 09:18    [1124066]     Ответить | Цитировать Сообщить модератору
 Re: СУБД CACHE'  [new]
Andrey K
Member

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

Покажите как вы собираетесь хранить атрибуты "артикул", "цена", ... в одном дереве. Что это за дерево такое?

Упорядочено хранить несколько атрибутов в одном дереве... Это круто. Покажите как вам это удаётся. ;) "иерархия" = "упорядоченность"?
22 ноя 04, 09:28    [1124096]     Ответить | Цитировать Сообщить модератору
 Re: СУБД CACHE'  [new]
Павел Воронцов
Member

Откуда: Новосибирск
Сообщений: 2402
Блог
Andrey K
Покажите как вы собираетесь хранить атрибуты "артикул", "цена", ... в одном дереве. Что это за дерево такое?
А я вот вслед за Andreww спрошу - а как Вы храните атрибуты в разных деревьях? Как Вы потом объект-то собираете? Мне правда интересно.
22 ноя 04, 09:47    [1124158]     Ответить | Цитировать Сообщить модератору
 Re: СУБД CACHE'  [new]
Gluk (Kazan)
Member

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

>Эрго иногда при вставке новых данных приходится перестраивать всё дерево (или большую его часть), чтобы дерево осталось сбалансированным? Так?

>У Б*-дерева приходится перестраивать три страницы. Все они на этот момент находятся в оперативной памяти.

Примерчик пожалуйста, вставка нового ключа в Btree глубиной скажем 20 с блокировкой всего трёх страниц при том, что все страницы дерева содержат максимально возможное число ключей. Мне любопытно, как тогда расшеплять родительские страницы если не до корня ? Или какой метод балансировки использовать ?


Согласен, слегка соврамши в запале. Но случаи эскалации расщеплений/слияний относительно редки, кроме того, незначительное увеличение размера страницы ЗНАЧИТЕЛЬНО уменьшает высоту дерева.
22 ноя 04, 09:57    [1124185]     Ответить | Цитировать Сообщить модератору
 Re: СУБД CACHE'  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
Andreww
>>Обычно меняется два-три блока. при колчиестве блоков в десяки тысяч, как вы понимаете - это мгновенно.

Т.е. вы рассматриваете Btree с количеством уровней 1,5 - 2 (тогда при вставке изменится 2-3 блока)?
Как в таком дереве хранить десятки миллионов ключей ? вы представляете накладные расходы в случае переливания ключей на полностью заполненом уровне в этом случае ? Размер страницы (порядок дерева) представляете ? Имхо, такое btree может оказаться много-много хуже простого связного списка. А массовое удаление из такого дерева может остановить всю систему и привести к огромному количеству считываний с диска (hint переливание ключей). Потому в реальных системах простые методы (такие как слияние и расщепления) никогда не используют, незнаю как там в Каше потому и интересуюсь.

Все переливания происходят со страницами УЖЕ ЗАГРУЖЕННЫМИ в оперативную память (Кнут прямо указывает, что с Б-деревьями лучше работать при наличии буферного кэша). Кроме того, как я уже сказал случаи роста/уменьшения дерева относительно редки.
22 ноя 04, 10:01    [1124196]     Ответить | Цитировать Сообщить модератору
 Re: СУБД CACHE'  [new]
Andrey K
Member

Откуда: Москва
Сообщений: 676
Павел Воронцов
Andrey K
Покажите как вы собираетесь хранить атрибуты "артикул", "цена", ... в одном дереве. Что это за дерево такое?
А я вот вслед за Andreww спрошу - а как Вы храните атрибуты в разных деревьях? Как Вы потом объект-то собираете? Мне правда интересно.

:) А вы перечитайте топик внимательно. Я уже об этом говорил. При чём не один раз. :)

Я тысячу раз пытаюсь объяснить, элементарную вещь. Повторять не буду. Всё очень просто.

Нельзя читать так невнимательно. :)
Нельзя читать так невнимательно. :)
Нельзя читать так невнимательно. :)
Нельзя читать так невнимательно. :)
Нельзя читать так невнимательно. :)

ТЕМ БОЛЕЕ ЧТО Я ПЕРВЫЙ ЗАДАЛ ВОПРОС. Давайте объясните сначала вы. А потом я может быть вам объясню... Тысячу первый раз.
22 ноя 04, 10:03    [1124202]     Ответить | Цитировать Сообщить модератору
 Re: СУБД CACHE'  [new]
U-gene
Member

Откуда: Москва. Россия
Сообщений: 1576
Коллега ЧАЛр
Причем здесь "значение" ? Это пройденный этап. U-gene уже "требовал" от меня использовать пару Класс/Объект. И я объяснил почему этого не следует делать. Мы используем пару Объект/Экземпляр.


Коллега ЧАЛ! Ну не надо настолько нагло передергивать! Я вам объяснял что одновременное использование терминов "класс", "объект" и "экземпляр объекта" - это глупость. Можно использовать либо пару "класс/объект", либо пару "объект/экземпляр объект", и по сути своей эти пары означают одно и тоже. Заметье, я согласен, что вторую пару тоже можно использовать, хотя это не принято широко.....И скажите мне, где это вы объяснили мне, что не надо делать? И какое отношение эти пары имеют к термину "значение"?

2 All.

Уважаемые господа! Не надо спорить с коллегой ЧАЛ! Не стоит это того....

PS На самом деле в старой доброй теории типов есть все - в том числе и всякие "новомодные" ОО-штучки. Нет только классов и объектов. Посему я бы на вашем месте пользовался терминами "тип", "переменная" и "значение" - так оно проще будет.

Удачи.
22 ноя 04, 10:03    [1124205]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 13 14 15 16 17 [18] 19 20 21 22 .. 24   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить