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

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

Ну в таком случае Вам не составит труда указать где именно Вы ответили на вопрос который я задавал Вам 5 (пять!) раз:

(29 сен 04, 01:26 [994591])
c127> На каких страницах сжатого изложения Вашего доклада на семинаре или на каких страницах нашей дискуссии находятся эти самые 6 пунктов и два ограничения, о которых нужно высказать свое мнение?

А без этой ссылки - Вы просто пустозвон.
11 ноя 04, 22:54    [1100071]     Ответить | Цитировать Сообщить модератору
 Re: СУБД CACHE'  [new]
Андрей Леонидович
Guest
с127 !

Вы действительно стали задавать этот вопрос сражу же как я изложил этот свой вариант формализации РМД из этих 6 пунктов и двух ограничений. И действительно упорно задавали его раз пять. Как-будто не заметили то, что я написал. Даже Вашим (более внимательным, что ли) коллегам пришлось сообщать Вам об этих судьбоносных для Вас страницах. И они, конечно же, подчеркнули, что "там тоже бред". Ясное дело. Чего еще можно ждать от шизофреника и пустозвона, кроме бреда ?
11 ноя 04, 23:02    [1100087]     Ответить | Цитировать Сообщить модератору
 Re: СУБД CACHE'  [new]
Andrey K
Member

Откуда: Москва
Сообщений: 676
Андрей Леонидович
В том-то и дело, что не знают. Может быть теперь хоть кто-то "покопается" в теории баз данных, раз уж разрабатывает приложения, основанные на концепции баз данных.

А вы знаете?

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

:) Зря вы думаете что все вокруг идиоты. (скорее наоборот) Реляционная модель элементарна. Вы знаете что такое нормализация? Что такое 1,2 .. 5 нормальные формы представления данных?
Если для вас реляционные СУБД являются мифическими. то говорить с вами не о чем.

Андрей Леонидович
Все уже давно обосновано, смоделировано, создано, проверено в лабораториях и успешно эксплуатируется в виде серьезных приложений корпоративного уровня. Если Вы об этом не знаете, так займитесь самообразованием. Вы что же "даром" хотите обо всем "разузнать" на этом форуме ?

:) Конечно хочу. (форум собственно для чего?) Вы ведь говорите, даже самим разработчикам приложений под Cache -
"Может быть теперь хоть кто-то "покопается" в теории баз данных, раз уж разрабатывает приложения, основанные на концепции баз данных". Так объясните нам "глупым", саму технологию хранения данных
Или хотя бы ссылку дайте, где можно ознакомиться с этим "чудом" -
"Все уже давно обосновано, смоделировано, создано, проверено в лабораториях" хотелось бы понять саму модель хранения данных а так же увидеть результаты сравнительных лабораторных тестов применения иерархических по сравнению с реляционными данными.
В ваших "пустых" ответах я вижу пока что, только демагогию и пустозвонство.
12 ноя 04, 08:58    [1100339]     Ответить | Цитировать Сообщить модератору
 Re: СУБД CACHE'  [new]
Мои 5 копеек
Guest
Привет!

Решил слегка подкинуть фактов:

1. Если хотите узнать как в Cache хранятся данные - идем на google (или сразу sourceforge.net), набираем GT.M и смотрим open-source абсолютно аналогичной Cache СУБД (основное ограничение по сравнению с Cache - только *NIX платформы, да и на самом деле она не бесплатная).

2. Cache - это такой же GT.M, только с поддержкой объектов и SQL. И то и другое - это НАДСТРОЙКА над обычным MUMPS. Продавцы Cache' будут называть это Unified Data Access (не помню уже точно), но на самом деле любой объект/таблица Cache транслируется в обычный М-код. Например, если мы сказали
INSERT INTO TEST VALUES ('NAME1','NAME2')
SELECT TOP(1) FROM TEST (за неправильный SQL не пинать!), то на самом деле это оттранслируется в команды типа
INSERT:
S ^TestD(^I(^TestD))=$lb('NAME1','NAME2')
SELECT:
Q ^TestD($O(^TestD("")))

Так что не мучайтесь вопросом как Cache удается объединять всевозможные доступы - это все лажа. Есть хорошая релаизация MUMPS, а все остальное - драйвера доступа к данным.

Вы же не удивляетесь, что OLE DB можно написать и для Outlook Express и для Oracle. Также и cache' - есть данные в B деревьях, к ним написан доступ на языке М (ака MUMPS). А все отальыне примочки - объекты, SQL транслируются в этот язык.
12 ноя 04, 10:37    [1100674]     Ответить | Цитировать Сообщить модератору
 Re: СУБД CACHE'  [new]
Andrey K
Member

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

Также и cache' - есть данные в B деревьях, к ним написан доступ на языке М (ака MUMPS). А все отальыне примочки - объекты, SQL транслируются в этот язык.

:) Уточню ещё раз. (для тех кто не понял постановку задачи)

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

Для каких нибудь типовых задач по проектированию, - таких очень распространённых систем как ERP, B2B, B2C .... . Для которых сами "объекты данных" приложения очень многомерны. Для таких задач сторонники Cache говорят, что их СУБД превосходит обычные реляционные во много раз.

Не понятно на чём основывается это "чудесное" быстродействие, о котором говорят сторонники Cache, при работе с данными в таких В деревьях... вопросов очень много ... избыточность данных? ... как реализованны связи? ... целостность?
12 ноя 04, 11:15    [1100876]     Ответить | Цитировать Сообщить модератору
 Re: СУБД CACHE'  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
2 Мои 5 копеек
Спасибо за описание подхода в Cache.
Но MUMPS - это не язак БД. Он ведь не поддерживает управление тразакциями, паралельный доступ к данным сам по себе? Это один из универсальных языков. Или нет?
Кроме того, Cache задекларирована как ООСУБД. А MUMPS поддерживает ООП?
И почему они тогда не выбрали С++? Я просто ничего про MUMPS не знаю, но он благодаря Cache становится более известным.
Тут в другой теме приводилась СУБД у которой платформа Cache???!!!
Т.е. у всех обычных платформа - ОС, а там другая СУБД. Т.е. взять прогу - написать свои команды (а лучше графический интерфейс), отранслировать в Оракловые и сказать, что это новая СУБД на платформе Оракл. И париться не надо, а потом сказать что это лучше самого Оракл.
12 ноя 04, 11:27    [1100950]     Ответить | Цитировать Сообщить модератору
 Re: СУБД CACHE'  [new]
locky
Member

Откуда: Харьков, Украина
Сообщений: 62034
>Кроме того, Cache задекларирована как ООСУБД. А MUMPS поддерживает ООП?
маленький алаверды
MUMPS не обязан поддерживать ООП, как его не обязан поддерживать Pascal.
Pascal - не поддерживает, Object Pascal - поддерживает. Возможности разные, языковые конструкции схожие, т.е. OP содержит в себе Pascal, но не наоборот.

Posted via ActualForum NNTP Server 1.1

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

Откуда: Москва
Сообщений: 1276
vadiminfo
Но MUMPS - это не язак БД. Он ведь не поддерживает управление тразакциями, паралельный доступ к данным сам по себе? Это один из универсальных языков. Или нет?

В sql есть операторы commit, rollback, start transaction, в mumps есть команды tcommit, tstart, trollback. Который из этих языков поддерживает управление транзакциями сам по себе?
12 ноя 04, 11:37    [1100999]     Ответить | Цитировать Сообщить модератору
 Re: СУБД CACHE'  [new]
locky
Member

Откуда: Харьков, Украина
Сообщений: 62034
>Тут в другой теме приводилась СУБД у которой платформа Cache???!!!
>Т.е. у всех обычных платформа - ОС, а там другая СУБД.
как нонича в Каше - не знаю, а вот с М не всё так просто. если мне память не изменяет на PDP-11 М стоял в качестве ОС - такой вот "сам себе режиссер". более того, все внутренние утили для М (я работал с MSM 3.11 (по моему)) написаны на М.

Posted via ActualForum NNTP Server 1.1

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

Откуда:
Сообщений: 56
Вот тут ответы на некоторые вопросы, связанные с MUMPS.
http://emanual.ru/download/678.html

Информация там старая, поэтому про Cache ничего нет, а вот про MUMPS - ответы на три десятка вопросов.
12 ноя 04, 11:38    [1101009]     Ответить | Цитировать Сообщить модератору
 Re: СУБД CACHE'  [new]
Andrey K
Member

Откуда: Москва
Сообщений: 676
jvvjvv
Вот тут ответы на некоторые вопросы, связанные с MUMPS.
http://emanual.ru/download/678.html

Информация там старая, поэтому про Cache ничего нет, а вот про MUMPS - ответы на три десятка вопросов.


Однако по интересующему меня вопросу нашёл только это


10. Насколько быстр M?

При сравнению с Ораклом М приблизительно в шесть раз быстрее.
Digital Standard MUMPS непрерывно устанавливает рекорды
производительности транзакций.
По сравнению с другими языками, наподобие Basic'a, COBOL'a, Fortrana'a,
приводятся оценки, что М где-то в пять раз быстрее и программы на нём
пишутся раза в три быстрее. Если базы маленькие - выигрыш меньше -
где-то раза в два. Но с увеличением тактовой частоты процессоров, разрыв
увеличивается.8-)
По сравнению с семейстовом DBf-FOX, и др. М без инструментария несколько
проигрывает в скорости разработки, при наличии инструментария -
совершенно без разницы, зато М выигрывает в скорости при:
1) если число пользователей базы >1
2) если величина базы >1 Mбайта
(данные приблизительны и без расчёта на подгонку программ)


На счётах, что ли считали?

Давайте методику и реальные опыты с конкретными моделями!
12 ноя 04, 11:43    [1101043]     Ответить | Цитировать Сообщить модератору
 Re: СУБД CACHE'  [new]
jvvjvv
Member

Откуда:
Сообщений: 56
>>10. Насколько быстр M?
.....
.....

Да, действительно. Такого рода постановки вопроса и ответы на вопросы действительно выглядят странно...
12 ноя 04, 11:46    [1101061]     Ответить | Цитировать Сообщить модератору
 Re: СУБД CACHE'  [new]
locky
Member

Откуда: Харьков, Украина
Сообщений: 62034
>>10. Насколько быстр M?
>Да, действительно. Такого рода постановки вопроса и ответы на вопросы
>действительно выглядят странно...

когда-то я переводил телефонный справочник сначала из Clarion на FP, а затем на М.
М работал, а все прочие нервно курили в сторонке :-)
так шта... в некоторых случаях видимо М побыстрее чем некоторые (не будем тыкать пальцем). А в некоторых - помедленнее, 100%. на задачу глядеть надо. и на описание тестов, коих, дейстивтельно в ссылке не было.

Posted via ActualForum NNTP Server 1.1

12 ноя 04, 12:04    [1101155]     Ответить | Цитировать Сообщить модератору
 Re: СУБД CACHE'  [new]
Мимопроходящий
Member

Откуда: бурятский тундрюк, эсквайр
Сообщений: 32896

Привет, locky!
Ты пишешь:

locky
>>>10. Насколько быстр M?
>>Да, действительно. Такого рода постановки вопроса и ответы на вопросы
>>действительно выглядят странно...

l> когда-то я переводил телефонный справочник сначала из Clarion на FP, а затем на М.
l> М работал, а все прочие нервно курили в сторонке :-)

У верблюда как-то спросили: "А чё у тебя шея такая кривая?!"
Он вздохнул и ответил: "А что у меня прямое?.."
Твой "опыт" с телефонным справочником демонстрирует только то, как ты решал задачу.
Ничего более.

--
With best regards, Мимопроходящий.

Posted via ActualForum NNTP Server 1.1

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

Откуда: Харьков, Украина
Сообщений: 62034
>Твой "опыт" с телефонным справочником демонстрирует только то, как ты решал задачу.
>Ничего более.
очень может быть. но я ж написал кучу отмазок/ограничений и т.д., не правда ли?
хотя... ну что может быть проще телефонного справочника? и почему индексный поиск на FP оказался медленнее прямого перебора в М?
почему М на 382DX 40 x4Mb оказался быстрее чем Oracle Х на P100х8MbхSCO? ручки? может быть. на той же задаче? Ах, орацлу надо было больше железа? согласен. но и писал ведь: в зависимости от задачи, в кою могет входить также ограничение на железо
а по железу М жуть какой неприхотливый. вышеупомянутая 386DX 40 тянула 8 терминалов и не морщилась. кто такое исчо могет?

Posted via ActualForum NNTP Server 1.1

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

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

MUMPS не обязан поддерживать ООП, как его не обязан поддерживать Pascal.
Pascal - не поддерживает, Object Pascal - поддерживает. Возможности разные, языковые конструкции схожие, т.е. OP содержит в себе Pascal, но не наоборот.

Я не настаиваю на обязанностях поддерживать, но меня интересовал факт, поодерживает или нет. Это для того чтобы лучше себе представлять о подходах к созданию Кэшем ООСУБД. Есть какие-то известные подходы и есть примеры ООСУБД, а про КЕш не нашел. Вот и хотел его как-то соотнести с теми что известны. Тогда бы на их примере узнал о концепциях в свете общих подходов БД
ну я

В sql есть операторы commit, rollback, start transaction, в mumps есть команды tcommit, tstart, trollback. Который из этих языков поддерживает управление транзакциями сам по себе?

Я ничего не утверждал а спрашивал только. Т.е. mumps язык БД? Поскольку sql однозначно язык БД. У mumps есть DDL и DML? В каких типах СУБД он применяется в качестве языка БД? Иерахических, Реляционных? А лучше и название СУБД. Кэш считает его своим языком БД или говорит что у него другой, а mumps это так - детали реализации?
Просто видел о том, что он перечислен наряду с другими универсальными (наприме, C++), в которых поддерживается возможность встривать инструкции SQL. И подкмал, что он универсальный, а не БД.
В эитх вопросах нет подвоха? Просто хочу понять как соотносится Кэш с другими ООСУБД.

jvvjvv

Вот тут ответы на некоторые вопросы, связанные с MUMPS.

Спасибо за инфу. Буду читать.
12 ноя 04, 13:25    [1101572]     Ответить | Цитировать Сообщить модератору
 Re: СУБД CACHE'  [new]
Andrey K
Member

Откуда: Москва
Сообщений: 676
locky
хотя... ну что может быть проще телефонного справочника? и почему индексный поиск на FP оказался медленнее прямого перебора в М?


Мысли вслух.

Допустим, что в М нет плоских таблиц в реально, но они наверняка пристуствуют виртульно (было бы нелепо мыслить иначе т.к. реляционная модель и табличное представление данных приведённое к 5 нормальной форме единственно верное - будем считать это как математически доказаный факт)

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

=> индекс в прямом смысле слова для таких веток не нужен впринципе! Другое дело для больших веток использовать bitmap. (который занимает гораздо меньше места)

=> поиск по любому критерию таблицы будет близок к 100% эффективности!

=> основной вопрос в том как реализовать связь собственно между ячейками одной строки "виртуальной таблицы". (эта проблема решается вероятно с помощью добавления дополнительных ключей к каждой ячейке? по которым в свою очередь тоже нужно стороить индекс? ... иначе как брать связанные значения?) => вот тут тупик (нужно моделировать и проводить опыты)

==> ВЫВОД ещё один но очень важный. В основе современной М. лежит всё та же ФУНДАМЕНТАЛЬНАЯ РЕЛЯЦИОННАЯ МОДЕЛЬ!!!!!! (М это та же х;%ня только вид сбоку)

IMHO

Кто ещё выскажет мысли по данному вопросу? :) Я прав или нет в своих догадках?
12 ноя 04, 13:30    [1101600]     Ответить | Цитировать Сообщить модератору
 Re: СУБД CACHE'  [new]
Andrey K
Member

Откуда: Москва
Сообщений: 676
Техногогия действительно интересная.

Вот теперь и теряйся в догадках кто пошёл по более правильному пути те кто использовал плоские таблицы и записи или те кто ...

Нужно смотреть для конкретных моделей данных, которых может быть очень много. И вероятно у каждой технологии будут как плюсы так и минусы.

Время покажет.
12 ноя 04, 13:37    [1101653]     Ответить | Цитировать Сообщить модератору
 Re: СУБД CACHE'  [new]
locky
Member

Откуда: Харьков, Украина
Сообщений: 62034

==> ВЫВОД ещё один но очень важный. В основе современной М. лежит всё та же ФУНДАМЕНТАЛЬНАЯ РЕЛЯЦИОННАЯ МОДЕЛЬ!!!!!! (М это та же х;%ня только вид сбоку)

а может быть так?
==> ВЫВОД в основе современной М и современных РСУБД лежат схожие "Программа=Структура данных+Алгоритм"? а?

а то мы сейчас договоримся до того, что в основе всё равно лежит ассемблер (который там действительно лежит).
о! кстати.... как вам такое: М лежит в основе ООП? была такая библиотечка для BP - Turbo Vision - окошки, кнопки, меню + всякое разное. В М с этим делом очень бедно было, по крайней мере тогда, когда я с ним работал. Ну, и перегнал урезанный TV на М. Включая наследование, переопределяемые методы и т.д. очень удобно вышло, аднака. оказалось, что в М есть все нужные функции и т.д. для хранения свойств, методов, списков методов и т.д., которые нужны для реализации ООП. вот чего не было - private/public, это да....

Posted via ActualForum NNTP Server 1.1

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

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

==> ВЫВОД ещё один но очень важный. В основе современной М. лежит всё та же ФУНДАМЕНТАЛЬНАЯ РЕЛЯЦИОННАЯ МОДЕЛЬ!!!!!! (М это та же х;%ня только вид сбоку)

а может быть так?
==> ВЫВОД в основе современной М и современных РСУБД лежат схожие "Программа=Структура данных+Алгоритм"? а?

:) Может быть. Говорю "ФУНДАМЕНТАЛЬНАЯ РЕЛЯЦИОННАЯ МОДЕЛЬ" - подразумеваю 5 нормальная форма представления данных. А списки М это => это производная... стедствие... (ЭТО СПОСОБ ХРАНИТЬ ДАННЫЕ ТЕХ ЖЕ ПЛОСКИХ ТАБЛИЦ).

Всё относительно. Но сначало было ... и было оно ... (См. Библия)
12 ноя 04, 14:02    [1101784]     Ответить | Цитировать Сообщить модератору
 Re: СУБД CACHE'  [new]
vadiminfo
Member

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

данных приведённое к 5 нормальной форме единственно верное - будем считать это как математически доказаный факт

Это почему единственно верное? Математически или не математически доказано скорее что не единственный.
С одной стороны подавление избыточности выше 3НФ, если таковая имеется, приводит к проблемам полной характеризации функциональных зависимомтей в схеме и является сложной задачей.
С другой упоминается некоея 6 нормальная форма Фагина (если не ошибаюсь), но она плохо поддается формализации. Но то что 5НФ максимально подавляет избыточность не доказано. Иными словами критериев самой опримальной схемы не выработано. Т.е. это больше искусство проекитровщика. На практике же допускается денормализация даже и по 3НФ ради оптимальности системы в целом.
Впрочем, я думаю, что это не имеет особого значения в данной теме.
12 ноя 04, 14:50    [1102059]     Ответить | Цитировать Сообщить модератору
 Re: СУБД CACHE'  [new]
Я и ёжик
Member

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

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

Нельзя посмотреть, то чего нет в принципе. Реляционные модель ЛОГИЧЕСКАЯ,
данные не хранятся в реляционных структурах, а представляются пользователю в виде таковых, нет реляционных дисковых накопителей и деревянных:) тоже.
На физическом уровне реляционные таблицы могут хранится в виде тех же B-деревьев (например Index Organized Table в Oracle, или кластерный индекс в MS-SQL), в Хэш-структурах, в виде куче, в виде кластеризованных структур и.т.д.
12 ноя 04, 15:43    [1102384]     Ответить | Цитировать Сообщить модератору
 Re: СУБД CACHE'  [new]
Мимо пробегал....
Guest
Согласен.

Добавлю также, что исходя из реляционной молеи все операции выполняются мгновенно. Я серьезно. :) Все эти болтовня "РСУБД работают медленно - следовательно, рел. модель плоха" сравни "костер горит плохо - следовательно, формула окисления неверна".
12 ноя 04, 16:20    [1102659]     Ответить | Цитировать Сообщить модератору
 Re: СУБД CACHE'  [new]
jvvjvv
Member

Откуда:
Сообщений: 56
Вот нашел пару ссылок на сайты сделанные на CSP
[url=http://cyber.mephi.ru/ ]http://cyber.mephi.ru/ [/url]

http://goldring.msk.ru/csp/goldring/h.csp

Обе практически неживые - очень медленный отклик.
Может, конечно, канал плохой, а может и еще чего.
12 ноя 04, 16:40    [1102756]     Ответить | Цитировать Сообщить модератору
 Re: СУБД CACHE'  [new]
jvvjvv
Member

Откуда:
Сообщений: 56
Что то не сработало. Ссылки такие:

1 http://cyber.mephi.ru

и

2 http://goldring.msk.ru
12 ноя 04, 16:45    [1102789]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 4 [5] 6 7 8 9 10 .. 24   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить