Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 4 5 [6] 7 8 9 10 .. 24   вперед  Ctrl
 Re: СУБД CACHE'  [new]
Andrey K
Member

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

С другой упоминается некоея 6 нормальная форма Фагина (если не ошибаюсь), но она плохо поддается формализации. Но то что 5НФ максимально подавляет избыточность не доказано. Иными словами критериев самой опримальной схемы не выработано.

Почему не выработанно? На практике ведь используют. Давайте мыслить реалиями и будем условно относить всё, что не доказано, то есть не реализовано на текущем уровне развития технологии и науки, к облати фантастики. ;)

Я и ёжик

Нельзя посмотреть, то чего нет в принципе. Реляционные модель ЛОГИЧЕСКАЯ,
данные не хранятся в реляционных структурах, а представляются пользователю в виде таковых, нет реляционных дисковых накопителей и деревянных:) тоже.

Любую матетатическую (логическую) модель можно реализовать на пракитке, если технология того позволяет. Не будем спорить на эту тему. Вы меня не поняли. Я говорю о ТЕХНОЛОГИИ, основывающейся на математической модели.

Я и ёжик

На физическом уровне реляционные таблицы могут хранится в виде тех же B-деревьев (например Index Organized Table в Oracle, или кластерный индекс в MS-SQL), в Хэш-структурах, в виде куче, в виде кластеризованных структур и.т.д.

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

=> индекс в прямом смысле слова для таких веток не нужен впринципе! не совсем это хотел сказать... они возможно сами строятся по принципу кластерного индекса

Ссылку даст кто нибудь с подробным описанием технологии?
12 ноя 04, 16:49    [1102807]     Ответить | Цитировать Сообщить модератору
 Re: СУБД CACHE'  [new]
jvvjvv
Member

Откуда:
Сообщений: 56
Вот еще одна

http://www.lab3it.com/

и тоже не работает.
12 ноя 04, 16:57    [1102849]     Ответить | Цитировать Сообщить модератору
 Re: СУБД CACHE'  [new]
Я и ёжик
Member

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

Я говорю о ТЕХНОЛОГИИ, основывающейся на математической модели.

Дак зачем Вы тогда предлагаете сравнить производительность доступа к физической-структуре B-дерева, с ЛОГИЧЕСКОЙ реляционной моделью, которая ПРИНЦИПИАЛЬНО отделена от физической модели и физически может хранится как угодно?

Andrey K

Обсуждается конкретная задача.

Конкретная задача сравнения огурцов с параходами? Огурцы зеленые, параходы плавают.
Andrey K

Невербальное общение это сложно, я пытаюсь, сказать одно, а вы читаете другое, думаете третее а пишите вобще четвёртое. Давайте идти друг другу навстречу и пытаться понять друг друга. :)

Да легко, скажите наконец, то что пытались сказать, и мы постараемся это понять.
12 ноя 04, 17:10    [1102899]     Ответить | Цитировать Сообщить модератору
 Re: СУБД CACHE'  [new]
MasterZiv
Member

Откуда: Питер
Сообщений: 34709
CACHE ничем не лучше и не хуже. Обычная база данных. Ничем принципиально не отличается. Непринципиально отличается тем, что там есть языки, отличные от SQL.
12 ноя 04, 18:41    [1103180]     Ответить | Цитировать Сообщить модератору
 Re: СУБД CACHE'  [new]
Andrey K
Member

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

Дак зачем Вы тогда предлагаете сравнить производительность доступа к физической-структуре B-дерева, с ЛОГИЧЕСКОЙ реляционной моделью, которая ПРИНЦИПИАЛЬНО отделена от физической модели и физически может хранится как угодно?

НЕТ! ОНА ПРИНЦИПИАЛЬНО НЕ ОТДЕЛЕНА! КАК УГОДНО ХРАНИТЬСЯ НЕ МОЖЕТ! Напрямую связана с тем как данные хранятся на диске. - ЭТО И ЕСТЬ ТЕХНОЛОГИЯ. Вы этого что до сих пор не поняли? Вы хоть немного поняли из моего сообщения "Мысли вслух:". Вы имеете представление, как данные хранятся на диске? (я имею ввиду реляционную СУБД - к примеру MSSQL) Если не знаете то разговаривать с вами не имеет смысла.

MasterZiv

CACHE ничем не лучше и не хуже. Обычная база данных. Ничем принципиально не отличается. Непринципиально отличается тем, что там есть языки, отличные от SQL.

И вы тоже не поняли о чём идёт разговор. Демагогию разводите и путозвонство. Если по существу не можете сказать, то лучше молчите. Ваш пост ни о чём. Абсолютно ни о чём. Вы это понимаете?

P.S. Для флейма и болтови есть форум "Просто трёп". А здесь серьёзные вещи обсуждаются. Думайте перед тем, как запостить очередное безсодержательное сообщение.

12 ноя 04, 19:36    [1103260]     Ответить | Цитировать Сообщить модератору
 Re: СУБД CACHE'  [new]
vadiminfo
Member

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

Почему не выработанно? На практике ведь используют. Давайте мыслить реалиями и будем условно относить всё, что не доказано, то есть не реализовано на текущем уровне развития технологии и науки, к облати фантастики. ;)

К сожалению, это факт, что не выработано. Есть понятие полной схемы. Но там требуется 3НФ. Потому что НФБК имеет проблемы с навязыванием схеме функциональных зависимомстей. Т.е. проектировщик стоит перед выбором. Подавлять избыточность или иметь возможность навязывать функциональные зависимости схеме с помощью выделения ключей. Теория только может помочь в оценке последствий. На практике производителями СУБД упоминается 3НФ. Даже на каком-то экзамене Микрософта про это есть. Что-то вроде:"Какую нормальную форму MS рекомендует применять?" Правильный ответ 3НФ. По-моему это по Access инетовский экзамен какой-то. Меня коллеги спрашивали, потому запомнил. Более того, считается, что после нормализации в серьезном проекте должна быть денормализация. Например, вычислимые поля выгодее вычислять во время занесения записи, чтобы потом быстрее работал запрос. Но такие поля часто транзитивно зависят от ключа.
Опытные, да и не опытные проектировщики вообще опускают этап нормализации, насколько я видел.
Про 4НФ, а тем более 5НФ вообще можно услышать от преподов, что они от лукавого. Т.е. они к практике имеют относительно маленькое отношение.
Ну и кроме того, нарушение 4НФ и 5НФ, наверное, врядли часто встречается на практике, если схема находится в 3НФ. Правда, это мое предположение.
12 ноя 04, 20:17    [1103292]     Ответить | Цитировать Сообщить модератору
 Re: СУБД CACHE'  [new]
c127
Guest
2 Андрей Леонидович
>с127 !

Вы действительно стали задавать этот вопрос сражу же как я изложил этот свой вариант формализации РМД из этих 6 пунктов и двух ограничений. И действительно упорно задавали его раз пять. Как-будто не заметили то, что я написал. Даже Вашим (более внимательным, что ли) коллегам пришлось сообщать Вам об этих судьбоносных для Вас страницах. И они, конечно же, подчеркнули, что "там тоже бред". Ясное дело. Чего еще можно ждать от шизофреника и пустозвона, кроме бреда ?


Вы еще плагиатора забыли, кроме шизофреника и пустозвона.

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

Как в таком случае понимать утверждение: "Андрей Леонидович>Я на все вопросы подробно ответил (т.е. УЖЕ ответил. прим с127). С многочисленными, подробными цитатами на русском и английском языках"? Правильно - ложное утверждение. Даже на простые вопросы Андрей Леонидович не отвечает.

2 locky

>вышеупомянутая 386DX 40 тянула 8 терминалов и не морщилась. кто такое исчо могет?

Sybase ASA 6.5. Правда в 8M озу, но там еще и повербилдеровский клиент одновременно крутился. Подозреваю что в четырех бы тоже все было ок. А какая была операционка в 4M?
13 ноя 04, 01:27    [1103668]     Ответить | Цитировать Сообщить модератору
 Re: СУБД CACHE'  [new]
locky
Member

Откуда: Харьков, Украина
Сообщений: 62034
>>вышеупомянутая 386DX 40 тянула 8 терминалов и не морщилась. кто такое исчо могет?
>Sybase ASA 6.5. Правда в 8M озу, но там еще и повербилдеровский клиент одновременно
> крутился. Подозреваю что в четырех бы тоже все было ок. А какая была операционка в 4M?

вах, я же говорю "терминалов"! это значит, что у юзера стояла такая штучка, называлась кажется VT100 или как то так - монитор зелено-черный с клавой и ничо более. а выполнялось всё для этих 8-ми юзверей как раз на во той 386.
операционка была MS DOS 6.2

ваще то М - достаточно клёвая штука, в некторых моментах значительно превосходящая все остальные. Правда, когда я увидел как к MSM прикрутили SQL - хорошо шо сидел, а то бы брякнулся на пол :-(.
ЗЫ по легенде крупнейшая М сеть содержит 5000 серверов М. какой-то госпиталь, може быть даже массачусетский.


Posted via ActualForum NNTP Server 1.1

13 ноя 04, 13:36    [1103869]     Ответить | Цитировать Сообщить модератору
 Re: СУБД CACHE'  [new]
Andrey K
Member

Откуда: Москва
Сообщений: 676
Подготовка куба olap для последующего анализа => это деномализация?

Разумеется что для представления информации в нужной пользователю форме из реляционного хранилища данных требуется время на обработку информации. Зависит от ТЕХНОЛОГИИ ханения. (это то что мы обсуждаем собственно!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!)

Суть в другом нормализация - это единственно правильное решение для хранения многомерных данных! С ЦЕЛЬЮ УМЕНЬШИТЬ ОБЪЕМ ХРАНИМЫХ ДАННЫХ НА ФИЗИЧЕСКОМ НОСИТЕЛЕ. Насколько эта модель будет соответствовать 5-й нормальной форме - для любой и существующих СУБД зависит только от разработчика.

(в Cache "глобаль" - это всего лишь аналог "плоской таблицы" - только столбцы этой таблицы хранятся, как иерархические списки! при этом для идентификации отдельной строки такой "виртуальной таблицы" используются (ключи) "перекрёстные ссылки") - Исходя из этого можно сделать очень много выводов! Это суть технологии Cache! IMHO

Технология Cache просто другая впринципе. Все что они сделали это - реализовали свой алгоритм хранения данных "плоской таблицы". Это ТЕХНОЛОГИЯ! и возможно что для большинства реальных задач - эта технология действительно превосходит. (Тут нужно лабораторное исследование...)

P.S. Очень жаль что люди с многолетним опытом разработки приложений для Cache. Не понимают суть технологии с которой они работают. (делаю этот вывод потому, что никто так и не смог объяснить ...) Не отчаивайтесь ;) в ваших руках действительно очень мощный инструмент. Цифры... даже взятые с потолка .... тоже имеют значение. Возможно ваша технология действительно лучше.... Но это нужно доказать.
13 ноя 04, 14:10    [1103901]     Ответить | Цитировать Сообщить модератору
 Re: СУБД CACHE'  [new]
Andrey K
Member

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

Цифры... даже взятые с потолка .... тоже имеют значение. Возможно ваша технология действительно лучше.... Но это нужно доказать.

:) Да гворят .. Очень вероятно, что так и есть. Сейчас верю, что для очень широкого круга задач производительность Chache может в несколько раз превосходить.

Доказательства должны быть. Кто знает, где можно посмотреть результаты исследований?
13 ноя 04, 14:47    [1103928]     Ответить | Цитировать Сообщить модератору
 Re: СУБД CACHE'  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
>Подготовка куба olap для последующего анализа => это деномализация?
Денормализация не при подготовке куба, а при проектировании OLTP базы. Т.е. измения структуры БД, которые приводят к нарушению 3НФ.

>Суть в другом нормализация - это единственно правильное решение для хранения многомерных данных! С ЦЕЛЬЮ УМЕНЬШИТЬ ОБЪЕМ ХРАНИМЫХ ДАННЫХ НА ФИЗИЧЕСКОМ НОСИТЕЛЕ. Насколько эта модель будет соответствовать 5-й нормальной форме - для любой и существующих СУБД зависит только от разработчика.
Нормализация все-таки понятие реляционных БД. В OLAP есть как минимум два подхода к тому как хранить многомерные данные ROLAP - в таблицах реляционных БД и MOLAP - специальный формат для многомерных данных. (Оракл, например, оба позволяет риализовать) О нормализации можно говорить в ROLAP - там есть два типа схем - Звезда - без нормализации и Снежинка с нормализацией (Оракл рекомендует первую если нет особо веских причин для второй).
Нормализация и в реляционных БД применяется в первую очередь ни С ЦЕЛЬЮ УМЕНЬШИТЬ ОБЪЕМ ХРАНИМЫХ ДАННЫХ НА ФИЗИЧЕСКОМ НОСИТЕЛЕ, поскольку она есть все-таки аспект логического проектирования, а не физического. Она нужна для устранения аномалий ввода и удаления, а также снятия проблем контроля избыточности.
И в общем случае нормализация имеет право увеличить объем, поскольку предполагает декомпозицию таблиц и появление дополнительных столбцов (для соединения).
С другой стороны снижение объема на носителе может дотигаться сжатиями данных, например, гораздо эффективней, чем нормализацией. Или специальными настройками таблиц, управляющими способом заболнения блоков и т.д. Т.е. нормализация даже если и применяется для снижения требований к ресурсам носителя, то не является ни единствееным, и даже в общем случае ни главным средством решения этой задачи.
Соответствие 5 нормальной форме не есть критерий оптимольности схемы. Так она может противоречить полноте схемы. Если она была бы критерием, то возможно, были процедуры автоматической проверки схемы в любом состоянии на соответствие 5 нормальной форме. Хотя такая проверка является NP - полной задачей. Т.е. даже проверка НФБК - NP - полная задача.
У Акцесс есть, например, проверка на 3НФ.
13 ноя 04, 17:09    [1104044]     Ответить | Цитировать Сообщить модератору
 Re: СУБД CACHE'  [new]
Андрей Леонидович
Guest
Приятно оказаться в одной компании "демагогов" и "пустозвонов" с "Я и ежик". А всего лишь невинно объяснял человек, что есть логическая модель данных, а есть способ физической организации данных...

А Andrey K молодец ! Начал все-таки разбираться самостоятельно. Первое предположение о "технологии" хранения данных в Cache вышло комом, но на то оно и первое...
13 ноя 04, 17:14    [1104048]     Ответить | Цитировать Сообщить модератору
 Re: СУБД CACHE'  [new]
Андрей Леонидович
Guest
с127 !

Да, да еще плагиатор и идиот... Очень плодотворная дискуссия...
То есть Вы несчастный (наверное единственный из участников той дискуссии) так и не прочитали эти страницы ?
13 ноя 04, 17:16    [1104050]     Ответить | Цитировать Сообщить модератору
 Re: СУБД CACHE'  [new]
Андрей Леонидович
Guest
Нормализация используется при проектировании базы данных независимо от используемой модели данных. Просто технология нормализации в объектной БД естественнее, чем в "реляционной". Ее целью, конечно, не является уменьшение объема данных. А денормализация неизбежна практически для любого крупного приложения, и не зависит от того используется OLAP в приложении (наряду с OLTP) или нет.
13 ноя 04, 17:30    [1104056]     Ответить | Цитировать Сообщить модератору
 Re: СУБД CACHE'  [new]
Andrey K
Member

Откуда: Москва
Сообщений: 676
Андрей Леонидович

Начал все-таки разбираться самостоятельно.

Да. Но пока что нормального описания в интернете не нашёл. (может плохо искал) Дайте ссылку. Можно англоязычную. (Меня именно технология интересует)

Андрей Леонидович

Первое предположение о "технологии" хранения данных в Cache вышло комом, но на то оно и первое...

Почему комом? Зато описал понятно в двух словах самое главное. :) Где я ошибся?
Я понимаю что выполнение запросов, журнал транзакций, блокировки. При такой технологи основанны совершенно на других алгоритмах, нежели в традиционных реляционных СУБД. Они сложнее.. Возможно поэтому до сих пор полнофункционально не реализована репликация... думаю это дело времени.

Повторю:

- БАЗА ДАННЫХ ВСЁ РАВНО РЕЛЯЦИОННАЯ (постреляционность - это рекламная фишка)

- НАСКОЛЬКО МОДЕЛЬ ДАННЫХ БУДЕТ СООТВЕТСВОВАТЬ 5НФ В ЛЮБОМ СЛУЧАЕ ЗАВИСИТ ТОЛЬКО ОТ РАЗРАБОТЧИКА

- ПОЛУЧЕНИЕ ДАННЫХ ДЛЯ ОТОБРАЖЕНИЯ КОНЕЧНОМУ ПОЛЬЗОВАТЕЛЮ ИЗ ЛЮБОГО РЕЛЯЦИОННОГО ХРАНИЛИЩА - ПОЧТИ ВСЕГДА СВЯЗАННА В ОПРЕДЕЛЁННОЙ СТЕПЕНИ С ДЕНОРМАЛИЗАЦИЕЙ

- ПРИНЦИПИАЛЬНОЕ ОТЛИЧИЕ CACHE - ЭТО САМА ТЕХНОЛОГИЯ ХРАНЕНИЯ ДАННЫХ

"ОБЪЕКТ" - Это очень .... понятие. "Таблица" - это "объект". :)
- ПОЭТОМУ НЕ ВИЖУ РАЗНИЦЫ КАКОЙ ЯЗЫК ИСПОЛЬЗОВАТЬ SQL ИЛИ ...

-ОГРОМНЫЙ ПЛЮС!!!!!!!!!! В CACHE ДЕЙСТВИТЕЛЬНО НЕ НУЖНО ДУМАТЬ ОБ ОРГАНИЗАЦИИ ИНДЕКСОВ! (мечта любого администратора БД)

Очень интересная и перспективная технология.
14 ноя 04, 11:50    [1104384]     Ответить | Цитировать Сообщить модератору
 Re: СУБД CACHE'  [new]
Andrey K
Member

Откуда: Москва
Сообщений: 676
Подумал ещё немного.

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

План выпоннения всегда один
1 - проверка ветвей соответствующих параметрическим критериям запроса (происходит очень быстро! т.к. => каждая ветвь построена как кластерный индекс)
2 - компоновка результатов строк выборки т.е. тех связанных значений которые не были параметрами самого запроса (происходит относительно долго. ??? тут вероятно применяютс bitmap индексы ("для перекрёстных ссылок" а не для самих данных) и другие алгоритмы оптимизации) => чем меньше таких значений тем выше скорость... и наоборот
14 ноя 04, 14:05    [1104433]     Ответить | Цитировать Сообщить модератору
 Re: СУБД CACHE'  [new]
ASCRUS
Member

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

Повторю:

- БАЗА ДАННЫХ ВСЁ РАВНО РЕЛЯЦИОННАЯ (постреляционность - это рекламная фишка)

- НАСКОЛЬКО МОДЕЛЬ ДАННЫХ БУДЕТ СООТВЕТСВОВАТЬ 5НФ В ЛЮБОМ СЛУЧАЕ ЗАВИСИТ ТОЛЬКО ОТ РАЗРАБОТЧИКА

- ПОЛУЧЕНИЕ ДАННЫХ ДЛЯ ОТОБРАЖЕНИЯ КОНЕЧНОМУ ПОЛЬЗОВАТЕЛЮ ИЗ ЛЮБОГО РЕЛЯЦИОННОГО ХРАНИЛИЩА - ПОЧТИ ВСЕГДА СВЯЗАННА В ОПРЕДЕЛЁННОЙ СТЕПЕНИ С ДЕНОРМАЛИЗАЦИЕЙ

- ПРИНЦИПИАЛЬНОЕ ОТЛИЧИЕ CACHE - ЭТО САМА ТЕХНОЛОГИЯ ХРАНЕНИЯ ДАННЫХ

"ОБЪЕКТ" - Это очень .... понятие. "Таблица" - это "объект". :)
- ПОЭТОМУ НЕ ВИЖУ РАЗНИЦЫ КАКОЙ ЯЗЫК ИСПОЛЬЗОВАТЬ SQL ИЛИ ...

-ОГРОМНЫЙ ПЛЮС!!!!!!!!!! В CACHE ДЕЙСТВИТЕЛЬНО НЕ НУЖНО ДУМАТЬ ОБ ОРГАНИЗАЦИИ ИНДЕКСОВ! (мечта любого администратора БД)

Очень интересная и перспективная технология.

Гм, я честно говоря так и не понял, что же Вас конкретно интересует - интересная и перспективная в теории технология или как она на текущий момент времени на самом деле работает на практике. Хотя, если Вы считаете что между обьектом Cache и таблицой РСУБД можно ставить равенство и поэтому можно SQL равноценно заменить языком Cache - может Вам действительно без разницы. Однако хочу заметить, что повышенным болдовым тоном Вы разговариваете с участниками форума совсем за зря - Вам никогда не приходила в голову мысль, что они поболее Вашего знают ? :)
14 ноя 04, 15:36    [1104483]     Ответить | Цитировать Сообщить модератору
 Re: СУБД CACHE'  [new]
vadiminfo
Member

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

- БАЗА ДАННЫХ ВСЁ РАВНО РЕЛЯЦИОННАЯ (постреляционность - это рекламная фишка)

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

- НАСКОЛЬКО МОДЕЛЬ ДАННЫХ БУДЕТ СООТВЕТСВОВАТЬ 5НФ В ЛЮБОМ СЛУЧАЕ ЗАВИСИТ ТОЛЬКО ОТ РАЗРАБОТЧИКА

Что дает утвердение тоже пока не ясно. Что дает зависимомсть о соответствии схемы 5НФ от разработчика? Если бы зависела не только от него, то что бы это меняло? Не ясна и абсолютизация 5НФ.

автор

"ОБЪЕКТ" - Это очень .... понятие. "Таблица" - это "объект". :)
- ПОЭТОМУ НЕ ВИЖУ РАЗНИЦЫ КАКОЙ ЯЗЫК ИСПОЛЬЗОВАТЬ SQL ИЛИ ...

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

-ОГРОМНЫЙ ПЛЮС!!!!!!!!!! В CACHE ДЕЙСТВИТЕЛЬНО НЕ НУЖНО ДУМАТЬ ОБ ОРГАНИЗАЦИИ ИНДЕКСОВ! (мечта любого администратора БД)

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

автор

Очень интересная и перспективная технология.

А вот тут то все только и начинается. Что это за технолгия (претендующая на помтреляционность)? Это ООСУБД? Как она соотносится с другим - прописанными в лит-ре. Какой подход у нее?
Если как Вы говорите у нее сама БД реляционная, а она поддерживает ООП для моделирования данных, то это одно. А если она на самом деле настройка над MUMPS, то это другое.
Я пока узнал, MUMPS язык ориентированный на работу с БД, но не язык БД.
Он не ООП. У него есть перманентность - он может постоянно сохранять данные в структарах типа многомерных массивов.
Тут дальше не ясно. MUMPS для CACHE это типа С для Оракла - средство реализации СУБД или что-то большее? На самом деле у CACHE какая-то своя ООМД модель, с библиотекой классов? Но это все транслируется в MUMPS?Или это какой-то API объкноориентированный для MUMPS? Или что? Играет роль для понимания CACHE знание о том, что он на MUMPS и какую? Или нет? Мало ли на каком языке разработано СУБД? Или это важно в данном случае?
Почему про него так много у нас в стране, а в толстых книгах по БД в разделах про ООСУБД не просто встретить? Мне пока не удалось.
Мне бы очень хотелось это узнать.
14 ноя 04, 15:41    [1104489]     Ответить | Цитировать Сообщить модератору
 Re: СУБД CACHE'  [new]
Andrey K
Member

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

Хотя, если Вы считаете что между обьектом Cache и таблицой РСУБД можно ставить равенство и поэтому можно SQL равноценно заменить языком Cache - может Вам действительно без разницы.

Условно да. Да считаю что можно заменить. Что без разницы? :)

ASCRUS

Однако хочу заметить, что повышенным болдовым тоном Вы разговариваете с участниками форума совсем за зря - Вам никогда не приходила в голову мысль, что они поболее Вашего знают ? :)

:) Болдовый не значит повышенный. Скорее увереным. Конечно приходила. Не принимайте близко к сердцу. :)

vadiminfo

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

Покажите где. Что это вобще такое постреляционность? :)
14 ноя 04, 16:27    [1104524]     Ответить | Цитировать Сообщить модератору
 Re: СУБД CACHE'  [new]
Andrey K
Member

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

Вы считаете что между обьектом Cache и таблицой РСУБД можно ставить равенство

Условно можно ставить. Эта связь реализована внутри самой технологии Cache.
ASCRUS

...поэтому можно SQL равноценно заменить языком Cache.

SQL (со всеми своими конструкциями.. объединениями .. различными планами выполнения запросов...) в Cache не нужен впринципе ... это другая совершенно технология.
14 ноя 04, 16:56    [1104549]     Ответить | Цитировать Сообщить модератору
 Re: СУБД CACHE'  [new]
Андрей Леонидович
Guest
Andrey K !

1. Технологию хранения, как Вы ее понимаете, "определяют" РАЗРАБОТЧИКИ приложений, а не ПРОИЗВОДИТЕЛИ MUMPS. И это действительно отличает MUMPS от "реляционных" СУБД.
2. "Декларативное" и "навигационное" программирование - это, конечно, не одно и то же. Разницу нужно понимать. А то, что приложения в MUMPS могут эффективно создаваться, развиваться и функционировать без SQL - это факт.
3. В ОСУБД (в том числе в ОСУБД на MUMPS) индексы являются полноценной частью данных (в отличие от "Р"СУБД), и о них как раз НУЖНО ДУМАТЬ.
14 ноя 04, 17:34    [1104568]     Ответить | Цитировать Сообщить модератору
 Re: СУБД CACHE'  [new]
Андрей Леонидович
Guest
MUMPS - первый стандартный интегрированный язык баз данных, а не "язык, ориентированный на работу с БД".

В Cache реализована не "своя" ООМД, а ОМ, соответствующая "стандарту" ODMG. В Cache Objects полноценно не поддерживаются связи между объектами (как и в подавляющем большинстве других ООСУБД), и я бы не стал называть Cache "объектной" (или "объектно-ориентированной"). Конечно, разработчики Cache в этом "не виноваты" - они достаточно строго поддерживают стандарты ODMG.

MUMPS - фундамент Cache, и это, конечно, "играет роль" (мягко говоря).
14 ноя 04, 17:42    [1104572]     Ответить | Цитировать Сообщить модератору
 Re: СУБД CACHE'  [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
Столько умных слов, а хоть бы кто привел пример какой-нибудь задачи где можно было бы показать преимущества "постреляционности"
14 ноя 04, 18:16    [1104587]     Ответить | Цитировать Сообщить модератору
 Re: СУБД CACHE'  [new]
Андрей Леонидович
Guest
MUMPS - дореляционная технология. Конечно, в свое время мы такой анализ проводили, так как "реляционная" технология выглядела заманчиво. Сейчас я не могу даже придумать какую-нибудь гипотетическую задачу, чтобы показать преимущество "реляционной" технологии над дореляционной, объектной технологией.
14 ноя 04, 18:32    [1104598]     Ответить | Цитировать Сообщить модератору
 Re: СУБД CACHE'  [new]
vadiminfo
Member

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

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

А как же концепции? Ведь хочется понять про Кеша, раз про него у нас в стране говорят. Он декларируется как ООСУБД, а это наряду с ОРСУБД относят к постреляционным. Была эпоха реляционных. У реляционных признаются некоторые недостатки. Обычно приводятся примеры со специальными приложениями типа геоинформационных и т.д. где эти недостаки могут проявтиться. Вот должны появится тогда постреляционные. Но и среди ООСУБД есть разные подходы. Вот и хочется понять где Кэш среди других ООСУБД. Даже пока без относительно есть у него преимущества или нет. Тогда про недостатки и достоинсва будет легче выяснить что-то. А отдельную задачу можно и про клипера найти где он лучше Оракла и MS SQL вместе взятых: комп 286 опреационка Дос - создать БД для одного юзера.
14 ноя 04, 22:14    [1104714]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 4 5 [6] 7 8 9 10 .. 24   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить