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

Откуда:
Сообщений: 9365
Maksim UM
2 vadiminfo
vadiminfo
Хотел наконец-то узнать побольше про Кэша. Но он опять ускальзает. Про деревья мы может что-то и увидели, а лес в целом пока окутан туманом.


Попробую еще раз. Вот ссылка на документацию по Cache, где описана физическая структура хранения (а также логическая):
platinum.intersystems.com/csp/docbook/DocBook.UI.Page.cls?
KEY=GGBL_structure#GGBL_C10862
Хотя подозреваю, что сразу же начнется охаивание (после прочтения документации или без ;) такого способа хранения.


Немножко не густо, да ?
Написать то можно все что угодно :)
22 ноя 04, 15:17    [1125848]     Ответить | Цитировать Сообщить модератору
 Re: СУБД CACHE'  [new]
vadiminfo
Member

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

Попробую еще раз. Вот ссылка на документацию по Cache, где описана физическая структура хранения (а также логическая):
platinum.intersystems.com/csp/docbook/DocBook.UI.Page.cls?
KEY=GGBL_structure#GGBL_C10862
Хотя подозреваю, что сразу же начнется охаивание (после прочтения документации или без ;) такого способа хранения.



Ну я не вижу пользы в охаивании даже если мне что-то и не нравится.
Для себя просто отмечу.
Другое дело отдельные недостатки, которые, как я верю, есть у всего. В том числе и Оракла и Рел модели. (Я Ораклист). Если приписывают недостаки, которых как, мне кажется, нет, то отрицать это есть польза: при этом ведь тоже идет изучение вопроса..
Документацию читать это одно. А узнать концепцию от специалистов этого продукта - это другое. Например, я не уверен, что стоит мне отсылать кого-то к доке по ОРаклу, если он хочет узнать какие-то главные вещи про него.
Так как на эту доку нужно тратить прилично.
Меня, например, интересует - что есть М? Как он соотносится с СУБД? У него все ф-ии традиционного СУБД? Он поддерживает иерахическую модель данных? Тут специалисты говорято то да, то нет. Если нет, то какую(кие)?
Кэш - надстройка над М?. Сам Кэш поддерживает ООМД и РМД? Как они сосуществут с иерархической, над которыми он надстройка? Отображаются в нее как-то или что? Можно, наример, разрабатывать на Кэше БД, а потом просто работать с этой БД, только с М?
22 ноя 04, 15:28    [1125910]     Ответить | Цитировать Сообщить модератору
 Re: СУБД CACHE'  [new]
Maksim UM
Member

Откуда: SPb
Сообщений: 432
vadiminfo

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

Меня, например, интересует - что есть М?
Опять же я давал ссылку. M[UMPS] - это технология, концепция. Включает БД и язык M, и все это стандарт.
vadiminfo
Как он соотносится с СУБД?
Язык M (COS) содержит функции для работы с БД. Cache - СУБД.
vadiminfo
У него все ф-ии традиционного СУБД?
Сложный вопрос. Что значит все?! Созданеие, управление, мониторинг БД и др. есть.
vadiminfo
Он поддерживает иерахическую модель данных? Тут специалисты говорято то да, то нет. Если нет, то какую(кие)?

Что Вы понимаете под "иерахическую модель"? тогда я скажу, поддерживает или нет? Только просьбы, тоже не отсылать меня к документации.
vadiminfo
Кэш - надстройка над М?
Cache - это продукт - СУБД реализующая стандарт M + некоторые расширения (включая ОО).
vadiminfo
Сам Кэш поддерживает ООМД и РМД?
Да.
vadiminfo
Как они сосуществут с иерархической, над которыми он надстройка? Отображаются в нее как-то или что?
Да, отображается. Если коротко, то поумолчанию (можно переопределять) в одном глобале с суррогатным ключем, хранятся данные, а в другом индексы со ссылкой на ключ.
vadiminfo
Можно, наример, разрабатывать на Кэше БД, а потом просто работать с этой БД, только с М?
Не совсем понятен вопрос. Но можно варьировать все технологии доступа.
22 ноя 04, 15:55    [1126047]     Ответить | Цитировать Сообщить модератору
 Re: СУБД CACHE'  [new]
Алимов Игорь
Member

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

Меня, например, интересует - что есть М?

М или точнее ISO M это в первую очередь язык программирования, который вылупился из MUMPS (Massachusetts general hospital Utility Multi Programming System) . Кроме того это база данных и даже операционная система.
vadiminfo

Как он соотносится с СУБД? У него все ф-ии традиционного СУБД? Он поддерживает иерахическую модель данных? Тут специалисты говорято то да, то нет. Если нет, то какую(кие)?

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

Кэш - надстройка над М?.

Была с свое время такая система MSM (Micronetics Systems MUMPS) конкретная реализация языка MUMPS, фирмы Micronetics. Достаточно неплохой продукт. Фирма Intesystems купила Micronetics и стала дальше развивать продукт и этот продукт называется Cache' (именно так с апострофом, произносится Каше c ударением на второй слог)
vadiminfo

Сам Кэш поддерживает ООМД и РМД?

А что это такое ?
vadiminfo

Как они сосуществут с иерархической, над которыми он надстройка?

См. предыдущий ответ - Это не надстройка.
vadiminfo

Отображаются в нее как-то или что? Можно, наример, разрабатывать на Кэше БД, а потом просто работать с этой БД, только с М?

Разрабатывать можно практически все, но приоритет составляют классические задачи базы данных.
22 ноя 04, 15:58    [1126063]     Ответить | Цитировать Сообщить модератору
 Re: СУБД CACHE'  [new]
Andreww
Member [заблокирован]

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

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

Это вы не правы, обявляя метод хранения в деревьях ОДНИМ ИЗ ЛУЧШИХ (мало кто его использует, Oracle например только недавно добавил его в свою СУБД).

>>Это действительно задача самого ядра БД я не должен над этим заморачиваться вообще! Важно как я собираюсь применять индексы построенные при помощи таких деревьев.

Именно ! Золотые слова. Вы должны прекрасно понимать, что добавление в Дерево занимает некоторое время и приводит к блокировкам, удаление тоже. Поэтому злоупотреблять индексами не стоит. Детали же интересны специалистам.

>>Ещё раз повторю я привел именно В-дерево как пример. :) И я не утверждал, что его использование будет наилучшим во всех случаях.

Ваша задача как разработчика, понимать, что в некоторых случаях дерево не выгодно а иногда и вредно. Как продвинутый разработчик, вы должны понимать, что иногда INDEX FULL SCAN хуже чем TABLE FULL SCAN т.к. алгоритмы обхода дерева всегда чуть сложнее и менее оптимальны чем списка или кучи.
А хранение в дереве (за редким исключением) крайне опасная затея, чреватая блокировками и тратой ресурсов, а вы объявили её ОДНОЙ ИЗ САМЫХ ОПТИМАЛЬНЫХ т.е. как разработчик вы собрались её использовать.

>>По вашему вопросу:
>>Объект на объектном уровне может быть вобще не привязан ни к какому конкретному В-дереву (любому дереву)!

И где же он в этом случае хранится ? Несчастный непривязанный объект ? То вы говорите, что хранить данные надо в деревьях и это
ОДИН ИЗ САМЫХ ОПТИМАЛЬНЫХ СПОСОБОВ. Теперь оказывается что он может быть не привязан и храниться где-то в сундучке :)

>>Он может быть связан как с одним деревом так и с множеством. Что тут непонятного?

Мне тут всё непонятно. Я спрашиваю как хранить объект в дереве, вы говорите : это три объекта, они хранятся в трёх деревьях,а ещё объект может быть не связан с деревом.

>>Я вам сказал что такие атрибуты как "артикул", "цена", .... полюбому хранятся в разных делевьях.

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

>>А вы мне сказали что это смешно.
Вы считаете ваши объяснение не смешными :) ?

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

Я и не собирался в одном дереве всё хранить. Ноборот старался вас от этого предостеречь.
Как поступить для оптимального поиска-выборки ? Очень просто. В специально организованном списке (куче) хранить сам объект.
Желательно, что-бы на указатель на элемент этого списка (идентификатор) однозначно проецировался на адресное пространство носителя.
При желании (для ускорения поиска и\или выборки) по нужным мне атрибутам строить соответствующие структуры, для ускорения поиска - Bдеревья, B*деревья, Битовые карты, Хэш-списки и т.п.
Скажу вам по секрету именно так поступают в Oracle-e,Firebird-e и других современных базах данных, да и не только в них и уже давольно давно.
Невзирая на то, что М-системе уже 200 лет и коллега ЧАЛ провозгласил падение реляционной теории а Andrey K обявил хранение в Б-деревьях едва-ли не самым оптимальным :)
22 ноя 04, 16:08    [1126083]     Ответить | Цитировать Сообщить модератору
 Re: СУБД CACHE'  [new]
Andrey K
Member

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

Andreww

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


Andreww

Я вас просил показать КАК ВЫ БУДЕТЕ ХРАНИТЬ этот объект, ....


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

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


Что вы всё зубы заговариваете. Флейма уже на несколько страниц развели. Было утверждение что несколько атрибутов хранятся в одном дереве! Покажите как!?
22 ноя 04, 16:09    [1126086]     Ответить | Цитировать Сообщить модератору
 Re: СУБД CACHE'  [new]
Алимов Игорь
Member

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


Что вы всё зубы заговариваете. Флейма уже на несколько страниц развели. Было утверждение что несколько атрибутов хранятся в одном дереве! Покажите как!?

Например так:
^dbo.KLADRWD("1")=$LB("","0100000000000","0100","","Адыгея","79000000000","Респ","0","00")
Это классификатор адресов Росии первая строка.
22 ноя 04, 16:16    [1126112]     Ответить | Цитировать Сообщить модератору
 Re: СУБД CACHE'  [new]
Алимов Игорь
Member

Откуда: Москва
Сообщений: 25
Алимов Игорь
Andrey K
[


Что вы всё зубы заговариваете. Флейма уже на несколько страниц развели. Было утверждение что несколько атрибутов хранятся в одном дереве! Покажите как!?

Например так:
^dbo.KLADRWD("1")=$LB("","0100000000000","0100","","Адыгея","79000000000","Респ","0","00")
Это классификатор адресов Росии первая строка.

А вот описание класса:
Class dbo.KLADRW Extends %Persistent [ ClassType = persistent, DdlAllowed, Owner = _SYSTEM, SqlRowIdPrivate, SqlTableName = KLADRW, StorageStrategy = Default, TimeChanged = "59841,40829.118376", TimeCreated = "59841,40829.116699" ]
{

Parameter EXTENTSIZE = 166775;

Index PKKladrw On CODE;

Property CODE As %Library.String(MAXLEN = 13) [ SqlColumnNumber = 4 ];

Property GNINMB As %Library.String(MAXLEN = 4) [ SqlColumnNumber = 6 ];

Property INDEX As %Library.String(MAXLEN = 6) [ SqlColumnNumber = 5 ];

Property NAME As %Library.String(MAXLEN = 40) [ SqlColumnNumber = 2 ];

Property OCATD As %Library.String(MAXLEN = 11) [ SqlColumnNumber = 8 ];

Property SOCR As %Library.String(MAXLEN = 10) [ SqlColumnNumber = 3 ];

Property STATUS As %Library.String(MAXLEN = 1) [ SqlColumnNumber = 9 ];

Property UNO As %Library.String(MAXLEN = 2) [ SqlColumnNumber = 7 ];

}
22 ноя 04, 16:18    [1126133]     Ответить | Цитировать Сообщить модератору
 Re: СУБД CACHE'  [new]
Andreww
Member [заблокирован]

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

У Кнута безусловно всё верно и правильно. Только в практической реализации всё чуточку сложнее :

- размер страницы фиксирован и невелик относительно общего кол-ва ключей (как правило связан с блоком диска и размером ключа).

- Из-за небольшого размера страницы трудно нармально органи

- Нежелательно размазывать страницы по всей поверхности диска

и самое противное (откуда и берутся основные дисбалансировки) существуют массовые вставки и массовые удаление (я думаю вы в своей практике с этим сталктвались не раз). Когда в таблицу добавляется\удаляется много данных с близкими по значеню ключами (а давайте пересчитаем отчётный период) в этом случае конечно спасает обращение ключа но оно не всегда возможно. Например, операция пересчитать остатки (платежи, и т.п.) за весь месяц может вызвать удаления-изменения значительной части таблицы если использовать для балансировки склейку\расщепление придётся использовать их построчно (т.к. эти алгоритмы не умеют работать с разбалансированным деревом) "неширокие" уровни будут довольно часто заполняться одинаковыми и расщепление-слейка будет идти по самому неоптимальному маршруту.

Тут чаще надо использовать либо модификации склейки расщепления и т.д.
22 ноя 04, 16:22    [1126147]     Ответить | Цитировать Сообщить модератору
 Re: СУБД CACHE'  [new]
Gluk (Kazan)
Member

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

Насколько я помню, в смысле балансировки Б-дерева, индексы Oracle всегда остаются сбалансированными. При массовых delete/insert индексы становятся "разреженными", но они все также сбалансированы в смысле глубины Б-дерева. Мнения относительно НЕОБХОДИМОСТИ перестроения таких индексов имеются разные. Кайт, к примеру высказывался, что это не необходимо.
22 ноя 04, 16:27    [1126168]     Ответить | Цитировать Сообщить модератору
 Re: СУБД CACHE'  [new]
Andrey K
Member

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

>>Я вам сказал что такие атрибуты как "артикул", "цена", .... полюбому хранятся в разных делевьях.

Вы, вообще-то сказали, что я нихрена в "технологии" не разобрался и это три разных объекта и что мне надо "вдумчивее читать".

Да вы просто ёбн...тый человек. Я не говорил что это три разные объекта! Я такого не говорил! Я говорил что они хранятся в трёх разных деревьях. А вы сказали что это смешно! Ху...ню лепите!
Отказываетесь от своих слов.

Andreww

....а Andrey K обявил хранение в Б-деревьях едва-ли не самым оптимальным :)

Идите СЮДА
И включите колонки погромче. Для вас есть звуковое сопровождение.

2 Алимов Игорь: Да мне на.... не нужно описание класса! Покажите как данные на носитель пишутся в одно дерево
22 ноя 04, 16:29    [1126176]     Ответить | Цитировать Сообщить модератору
 Re: СУБД CACHE'  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
И размером страницы, кстати в Oracle можно управлять. Начиная с 9i для каждого табличного пространства индивидуально.
22 ноя 04, 16:29    [1126178]     Ответить | Цитировать Сообщить модератору
 Re: СУБД CACHE'  [new]
ну я
Member

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

К мампсам относятся системы, выполняющие процессы. Практически всегда это серверные процессы. Что они исполняют - пишется на языке М. Для неспециалиста этот язык - примерна та же ахинея что и перл. В языке есть единственный тип данных - дерево. Язык имеет встроенные команды для транзакций, запуска процессов и операций с устройствами ввода-вывода. Драйвера писать правда нельзя. Исключение - драйвера для принтеров: есть конторы которые при получении нового принтера сами пишут программы, которые формируют нужные эскейп-последовательности. Деревянные переменные могут храниться - если первый символ имени ^, то хранится. Это видят все процессы. Если нет ^, то это локальная переменная, у каждого процесса своя. Есть развитые средства синхронизации (блокировки).
Та часть которая работает с хранимыми деревьями и соотносится с субд. Остальная - что-то вроде сервера приложения. Декларация переменных отсутствует - запись в несушествующую переменную приводит к ее созданию. Устройство переменной примерно такое (для неспециалистов):
есть корень, например varname, это корневой узел. В него може быть записано или не записано значение в виде последовательности байтов до 32кила. У любого узла могут быть дочерние, например varname(1), varname("sss"). Здесь 1 и sss - значения индекса. В значениях varname(1) и varname("sss") также могут быть записаны или не записаны данные. Если в узле данных нет и в его всех дочерних узлах данных нет, то и самого узла нет.
Присутствует мощная встроенная на уровне стандарта библиотека функций работы со значениями и деревьями. Все операции для локальных и хранимых деревьев одинаковы. Очень мощная косвенность, например "взять значение переменной, имя которой в этой переменной".
Как примерно традиционно хранятся данные:
1) вариант с разделителями
^operations(1000)="120.34~Moscow~~wind"
Как это может быть прочитано - есть нечто что хранится в глобале ^operations, с разделителем тильда, имеет идентификатор 1000 в первом поле 120.34, во втором Moscow, в третьем пустая строка, в четвертом wind.
2) с деревянным хранением
^operations(1000,"summ")=120.34
^operations(1000,"city")="Moscow"
^operations(1000,"target")=""
^operations(1000,"category")="wind"
Схему хранения можно варьировать как хочешь - система не будет этому ни способствовать ни препятствовать. Что тут считать объектом - это как самому программисту захочется. Например, пусть есть документ, в котором есть строки
^docs(id) - например здесь ничего не храним.
^docs(id,"caption")="Типа заголовок"
^docs(id,"stroki") - например тут общее число строк
^docs(id,"stroki",12) - отсюда пойдет 12-я строка
^docs(id,"stroki",12,"naimen") - наименование 12-й строки
и так далее как захочется. Удаление командой kill узла означает удаление и всех его дочерних - так что при удалении узла ^docs(123) например удалятся и все его строки. Строки можно хранить отдельно, ссылаясь на них из документа. Повторюсь - система никак не будет ни препятствовать этому ни способствовать, что как хранить - решаем сами. Во втором случае строкам можно приписать сквозную идентификацию, можно составную, например сквозная:
^docstroki(12345,"naimen")="..." - строка номер 12345 среди всех строк всех документов
составная
^docstroki(123,12,"naimen")="..." - у 123 документа 12-я строка
Как в этом хозяйстве ишшут - также как в других базах, поддерживая индексные структуры, например индекс по полю city может выглядеть как
^ioperations("city","Moscow",1000)=""
Может быть несколько записей у которых city равен Moscow, например
^ioperations("city","Moscow",1002)=""
^ioperations("city","Moscow",1004)=""
^ioperations("city","Moscow",1007)=""
Для получения идентификаторов (в нашем случае 1000, 1002, 1004, 1007) используем функцию $order, которая возвращает значение следующего индекса у последнего заданного. Если начать с пустой строки - вернет первый, если не нашла - вернет пустую строку. Порядок выдачи - так называемая индексная сортировка - если строка является строковым представлением числа, то сравниваются как числа, иначе как строки, если одна является числом, а другая нет, то сначала число.
Есть еще куча всяких встроенных функций и команд оперирующих деревом, например merge - слияние.
Это про то, что и как хранится. Какая модель на этом будет реализована - реляционная, объектная или какая еще - дело программиста. Вообще говоря. Но есть в штатном дистрибутиве средства sql и объектов. Ими можно не пользоваться, написать свои. Они - лишь как вариант реализации sql и объектов.
Как М соотносится с СУБД - позволяет написать свою СУБД (прямой доступ), или быть базисом для самописных или штатных (из дистрибутива) средств sql или объектов. Прияем штатные средства позволяют натянуть и объекты и таблицы (в понимании производителя) на одни и теже глобали.
Наличие или отсутствие индекса и возможность его использования определяется механизмом - этому механизму нужно объявить что индекс есть и какова его структура. Тот же sql несмотря на наличие самих индексных данных не будет их использовать пока мы не объявим что они есть в неких внутренних метаданных этого движка. Если пишем сами - то можем придумать свои метаданные или не придумать - просто считать, что индекс заданной структуры ведется.

Теперь расскажите мне, в свою очередь, что такое иерархическая модель данных. Возможно, я смогу ответить, является ли внутренний механизм хранения дерева готовой реализацией иерархической модели или понадобится накрыть слой хранения еще каким-то программным слоем. Для объектного и табличного сразу скажу - это надстройки над обычным М, которые превращают запросы sql и объектный синтаксис в обычные команды и функции М. Так же, по-моему, можно надстроить еще что угодно.
22 ноя 04, 16:29    [1126180]     Ответить | Цитировать Сообщить модератору
 Re: СУБД CACHE'  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
Может быть я не прав, но по моему массовые оскорбления участников форума со стороны одного ... не должны игнорироваться модераторами :(
22 ноя 04, 16:30    [1126182]     Ответить | Цитировать Сообщить модератору
 Re: СУБД CACHE'  [new]
Алимов Игорь
Member

Откуда: Москва
Сообщений: 25
Gluk (Kazan)
Может быть я не прав, но по моему массовые оскорбления участников форума со стороны одного ... не должны игнорироваться модераторами :(

я тоже так считаю.
22 ноя 04, 16:34    [1126196]     Ответить | Цитировать Сообщить модератору
 Re: СУБД CACHE'  [new]
Andrey K
Member

Откуда: Москва
Сообщений: 676
Gluk (Kazan)
Может быть я не прав, но по моему массовые оскорбления участников форума со стороны одного ... не должны игнорироваться модераторами :(

Искажение фактов это тоже оскорбление.
22 ноя 04, 16:36    [1126211]     Ответить | Цитировать Сообщить модератору
 Re: СУБД CACHE'  [new]
Andrey K
Member

Откуда: Москва
Сообщений: 676
Andrey K
Gluk (Kazan)
Может быть я не прав, но по моему массовые оскорбления участников форума со стороны одного ... не должны игнорироваться модераторами :(

Искажение фактов это тоже оскорбление.

Наглая ложь это тоже оскорбление.
22 ноя 04, 16:37    [1126223]     Ответить | Цитировать Сообщить модератору
 Re: СУБД CACHE'  [new]
Алимов Игорь
Member

Откуда: Москва
Сообщений: 25
Если вас действительно интересует вопросы хранения данных в MUMPS, рекомендую почитать:
Джон Левкович "Все о языке програмирования и системе MUMPS" Глава 11 "Нюансы MUMPS" Там организация глобальных массивов достаточно подробно описана.
22 ноя 04, 16:40    [1126234]     Ответить | Цитировать Сообщить модератору
 Re: СУБД CACHE'  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
Andrey K
Andrey K
Gluk (Kazan)
Может быть я не прав, но по моему массовые оскорбления участников форума со стороны одного ... не должны игнорироваться модераторами :(

Искажение фактов это тоже оскорбление.

Наглая ложь это тоже оскорбление.


Голословное обвинение. Пальцем ткните Уважаемый.
22 ноя 04, 16:44    [1126254]     Ответить | Цитировать Сообщить модератору
 Re: СУБД CACHE'  [new]
Andrey K
Member

Откуда: Москва
Сообщений: 676
Gluk (Kazan)
Andrey K
Andrey K
Gluk (Kazan)
Может быть я не прав, но по моему массовые оскорбления участников форума со стороны одного ... не должны игнорироваться модераторами :(

Искажение фактов это тоже оскорбление.

Наглая ложь это тоже оскорбление.


Голословное обвинение. Пальцем ткните Уважаемый.


НЕТ НЕ ГОЛОСЛОВНОЕ. Тыкаю вас носом.

Это РАЗ
https://www.sql.ru/forum/actualthread.aspx?bid=10&tid=31638&pg=16#1122271

Это ДВА
https://www.sql.ru/forum/actualthread.aspx?bid=10&tid=31638&pg=16#1122283
22 ноя 04, 16:51    [1126294]     Ответить | Цитировать Сообщить модератору
 Re: СУБД CACHE'  [new]
Andreww
Member [заблокирован]

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

>>Насколько я помню, в смысле балансировки Б-дерева, индексы Oracle всегда остаются сбалансированными.

И это большой плюс Ораклу.
Задача не из лёгких.


>>При массовых delete/insert индексы становятся "разреженными", но они все также сбалансированы в смысле глубины Б-дерева.

Интересно как они это делают.Может сводят к бинарным деревьям, может как то модифицируют слейку, но, имхо, обычная слейка-расщепление массовые вставки-удаления обслужить не в состоянии т.к. работает только с вставкой\удалением каждого ключа по-отдельности и (опять же имхо) к разряжению дерева не приводит, а поддерживает наилучший балланс и насыщенность очень ресурсоёмкой ценой.
Об этом я и пытался сказать. Вроде мы друг-друга понимаем.

Впрочем Oracle закрытая система и остаётся только строить догадки, можно попробовать Metalink протрясти, только долго это, но уже стало интересно.
Если ссылкой на алгоритм балансировки с металинка располагаете, не сочтите за труд, кинте на мыло (мыло есть в профиле).


>>Мнения относительно НЕОБХОДИМОСТИ перестроения таких индексов имеются разные. Кайт, к примеру высказывался, что это не необходимо.

Если дисковое пространство позволяет, то может и не надо перестраивать. Не видя алгоритма сказать сложно, но Кайту стоит верить, практика сильная вешь. Можно ещё спросить dimon_2000n с форума на sql.ru, он вроде говорил, что он не глупее всех "дядек" :)


2 Andrey K


Как сохранить объект (запись, структуру, кортеж) в B*(B)-дереве смотрите у Кнута, Кормена и в других букварях.

Кратко : выбрали один из атрибутов в качестве ключа, в листьях (если Btree) храним связный список из объектов - никаких проблем до настоящего момента это ни у кого не вызывало.

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

Странная для преподавателя (я уж не говорю - для профессионала) суетливость. Ничего я не собираюсь никому продавать. Пожалуйста, ведите дискуссию корректно, и не смешивайте все в кучу.
Был Ваш вопрос про объекты без характеристик (в Вашей терминологии, сначала - без свойств, потом - без атрибутов).
Я на него четко ответил. ЧЕТКО ОТВЕТИЛ.
22 ноя 04, 17:54    [1126613]     Ответить | Цитировать Сообщить модератору
 Re: СУБД CACHE'  [new]
Андрей Леонидович
Guest
U-gene !

Спасибо за поправку. Вы правы по определению.
Простите, если сможете.
Хотя про Класс и ООП я объяснил. Но здесь я всегда "несу бред и нагло передергиваю". Про ЭТО я уже объяснил в отдельном сообщении...
А я Вашу статью про Вашу модель данных читаю с удовольствием. Жаль, что Вы "ушли" от дискуссии...
Удачи.
22 ноя 04, 17:59    [1126627]     Ответить | Цитировать Сообщить модератору
 Re: СУБД CACHE'  [new]
Андрей Леонидович
Guest
ops !

Опять странное непонимание исторического контекста. Это дореляционных ОСУБД "хватает за глаза". И все уже протестили давно...

А Ваше "первое сообщение" это:

"если это допускается - почему бы и нет..."

?

Подтвердите, и, конечно, комментарий будет.
22 ноя 04, 18:02    [1126640]     Ответить | Цитировать Сообщить модератору
 Re: СУБД CACHE'  [new]
Андрей Леонидович
Guest
ops !

То есть, когда Вы выбирали СУБД для разработки приложений, Вы анализировали как в разных СУБД данные физически хранятся в памяти, и именно поэтому выбрали, например, MS SQL вместо Oracle (или наоборот) ?
22 ноя 04, 18:04    [1126648]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 15 16 17 18 19 [20] 21 22 23 24   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить