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

>То есть Вы несчастный (наверное единственный из участников той дискуссии) так и не прочитали эти страницы ?

Слова, слова... А ответа на вопрос все нет. Чем еще раз подтверждается неоднократно высказанное учатниками "той дискуссии" утверждение, что Андрей Леонидович на вопросы не отвечает. Хотя он сам постоянно утверждает обратное.

2 locky

>ЗЫ по легенде крупнейшая М сеть содержит 5000 серверов М. какой-то госпиталь, може быть даже массачусетский.

Врядли в массачусетском госпитале 5000 серверов. Максимум 3, а скорее 1.

2 vadiminfo

>Такое утверждение нуждается в серьезном обосновании, поскольку утверждения о постреляционности есть в источниках далеких от рекламы.
>А как же концепции? Ведь хочется понять про Кеша, раз про него у нас в стране говорят. Он декларируется как ООСУБД, а это наряду с ОРСУБД относят к постреляционным. Была эпоха реляционных. ... Вот должны появится тогда постреляционные. Но и среди ООСУБД есть разные подходы. Вот и хочется понять где Кэш среди других ООСУБД. Даже пока без относительно есть у него преимущества или нет. Тогда про недостатки и достоинсва будет легче выяснить что-то.


Опять начинается: постреляционные, ООСУБД, дореляционные. Сколько уже копий сломано. Дайте определения, увидите, сразу станет понятным кого куда относить и плюс еще снимется половина вопросов о преимуществах-недостатках. Кроме того можно будет не тепаться по-пусту, говорить предметно.
15 ноя 04, 04:12    [1104786]     Ответить | Цитировать Сообщить модератору
 Re: СУБД CACHE'  [new]
Andrey K
Member

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

1. Технологию хранения, как Вы ее понимаете, "определяют" РАЗРАБОТЧИКИ приложений, а не ПРОИЗВОДИТЕЛИ MUMPS. И это действительно отличает MUMPS от "реляционных" СУБД.

Глупость какая. :) Вы действительно не смогли объяснить людям в чем суть технологии Cache потому что сами её не понимаете. РАЗРАБОТЧИКИ ПРИЛОЖЕНИЙ НЕ ОПРЕДЕЛЯЮТ ТЕХНОЛОГИЮ ХРАНЕНИЯ!

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

2. "Декларативное" и "навигационное" программирование - это, конечно, не одно и то же. Разницу нужно понимать. А то, что приложения в MUMPS могут эффективно создаваться, развиваться и функционировать без SQL - это факт.

Ух ты. какими вы понятиями ... :) Дайте пожалуйса определения.

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

3. В ОСУБД (в том числе в ОСУБД на MUMPS) индексы являются полноценной частью данных (в отличие от "Р"СУБД), и о них как раз НУЖНО ДУМАТЬ.

Ещё раз... На образном уровне "глобаль" это та же самая "плоская таблица" только поля данных хранятся в ней в виде иерархических списков. Логические связи между "глобалями" аналогичны связям между "плоскими таблицами" - то есть они РЕЛЯЦИОННЫЕ. "Поле" (список) -это данные хранящиеся как кластерный индекс и "перекрёстные ссылки" (ключи). Поэтому поиск по таким веткам очень быстрый. после того как определены диапазоны вхождения параметров запроса (с учётом реляционной модели связей которая лежит в основе связей между ...) для каждой такой ветки берутся "перекрёстные ссылки" - над ними производится элементарная операция по вхождению "множеств" (логическое END). Выделяется множество соответствующее параметрам запроса. ... Затем происходит "компоновка строк".

Не нужно использовать подзапросы, виртуальные таблицы, объединения (связи реализованы в самой технологии), анализировать планы выполнения, ... => SQL не нужен. Само собой напрашивается использовать язык оперирующий объектами.

НЕ НУЖНО ДУМАТЬ ОБ ИНДЕКСАХ! (то есть выбирать где и какие индексы строить и думать как их использовать..... вы извиняюсь в тему не врубаетесть) О САМОЙ МОДЕЛИ ДАННЫХ ЕСТЕСТВЕННО НУЖНО ДУМАТЬ. Но модель данных при использовании такой технологии - тоже естественно описать объектно.

ASCRUS

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

Мы ведём дискусию. Если я не прав пусть, укажут где именно.
Я как мне кажется описал суть коротко, доступным и понятным языком. Так что даже человек со средним интелектом должен понять.
15 ноя 04, 09:13    [1104932]     Ответить | Цитировать Сообщить модератору
 Re: СУБД CACHE'  [new]
Andrey K
Member

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

ASCRUS

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

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

Если у него конечно есть.... те самые знания о которых вы говорите.
15 ноя 04, 09:18    [1104940]     Ответить | Цитировать Сообщить модератору
 Re: СУБД CACHE'  [new]
vadiminfo
Member

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

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

Что значит опять начинается? И не кончалось. И не мной придумано. Вы же не можете расчитывать на отказ от общепризнанного в литре из-за того, что Вам это не нравится.
У нас может и сломано, а в технолгиях БД ничего не сломано.
Иерархические, сетевые СУБД - до реляционные.
Вот краткие упрощенные определения, для меня достаточные, а Вы как хотите.
ООМД - Объектно-ориентированная модель данных - модель которая поддерживает те или иные элементы ООП. Объекты (от сущености отличаются идентификацией и наличием методов - моделирование поведения)Идентификацию, абстрагирование, инкапсуляцию, полиморфизм, иерархию классов. Отсутсвие общепринятой единой модели данных - недостаток, который не отменяет однако понятия ООМД.
ОРСУБД - поддержка ОРМД, ОРМД - расширение реляционной модели поддержкой элементов ООМД.
ООСУБД - ООМД, радикальный подход - отказ от реляционности.
В общем случае для проектировщика. Т.е. там якобы "в низу" и реляционная, но проектировщик якобы об этом "не знает" тоже, наверное, отноят к ООСУБД.
По крайней мере, здесь на форуме искали спецов на разработку на первом этапе таковой ("в низу" реляционной)
Хотя с другой стороны в ООСУБД претендуют на отсутствие различий в логическом и физическом. (Тогда и "в низу" не реляционная)
Постреляционные на сегодняшний момент: ООСУБД, ОРСУБД.
Но возможны и какие-то универсальные включающие элементы и др., например, ОРСУБД, включая элементы сетевых. MS говорит об универсальном сервере, как я здесь вычитал. Оракл включает, полуструктурированные XML, массивы, вложенные таблицы.
Не знаю на что Вы расчитываете в попытках отрицать очевидное. И какой в этом теперь смысл. Надо было лет 20 назад их останавливать на достигнутом. А теперь поздно.
Вы можете по прежнему не признавать их, пытаться сводить к реляционным, но это будет всего лишь радикальная точка зрения, которая на сегодняшний день не является доминирующей в технологиях БД. Литру приводил. Больше не буду.

В частности, в данной теме КЭШ. Она декларируется как ООСУБД. Так что же Вы тогда хотели? Если он не ООСУБД так и скажите. Кто он тогда? Ведь я его не нашел в литре по БД в разделах по ООСУБД.

Однако, есть разные подходы к созданию ООСУБД. И меня интересует Кэша подход. Тогда и пойму про него что-то.
15 ноя 04, 10:21    [1105099]     Ответить | Цитировать Сообщить модератору
 Re: СУБД CACHE'  [new]
Я и ёжик
Member

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

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

Да ладно я не понял, это не страшно, а ведь ещё Кодд, Дейт, Ульман и др.

Дейт: "В реляционной модели не рассматривается внутренний уровень систем баз данных, в частности внутренний уровень архитектуры ANSI/SPARC. В принципе в системе могут использоваться любые структуры хранения на внутреннем уровне. Единственным условием является то, что система должна «уметь» преобразовывать эти структуры хранения и представлять данные на концептуальном уровне в чистой табличной форме.".[1]

Дейт:"Идея реляционной модели применяется к внешнему и концептуальному уровням системы, а не к внутреннему уровню".[1]

Дейт:"Таким образом, обеспечение независимости данных – основная цель систем баз данных.
Независимость данных можно определить как иммунитет приложений к изменениям в структуре хранения данных и в методах доступа к данным, а это означает, что рассматриваемые приложения не зависят от любой конкретной структуры хранения и конкретных методов доступа".


Кодд : "Изначально ... реляционная модель ... рассматривалась как средство для освобождения пользователей от неприятностей, связанных с потребностью иметь дело с массой деталей представления хранимых данных". [2]

[1] К.Дж.Дейт Ввендение в системы баз данных. Шестое издание. Диалектика 1998.
[2] Codd, E.F. "Extending the Relational Database Model to Capture More Meaning." IBM Research Report RJ2599 (August 6th, 1979). Republished in ACM Transactions on Database Systems 4(4), December 1979.

Andrey K

Вы имеете представление, как данные хранятся на диске? (я имею ввиду реляционную СУБД - к примеру MSSQL) Если не знаете то разговаривать с вами не имеет смысла.

" к примеру MSSQL" я не знаю, по скольку работаю с Oracle, а периоды работы c предком MSSQL от Sybase были незначительны и фрагментарны, но даже я знаю ( в прочем как и Вы, чудя по след. сообщениям), что в нем есть как минимум 2-физических структуры организации хранения таблицы, в виде "кучи" и в виде B-дерева ( кластерный индекс), и изменить структуру в которой хранится таблица вы можете не меняя своего приложения и не меняя реляционную схему БД, в ней как была это таблица, так и осталась, в "реляционном" описании ничего не помянялось.
А есть ещё много других "физических" структур хранения, например для Oracle инедексный-клатер и хэш-кластер ( когда данные строк(и) нашей любимой таблички, хранятся вместе со связанными с ними по ключу кластеризации с ними данными строк(и) другой(их) таблиц в общем блоке( странице) БД ).
Ту же табличку мы можем запихнуть в Хэш-структуру ( для этого в Oracle, например, используется всё таже организация в виде хэш-кластера, но в блоках хранятся данные только одной таблицы).
Далее, некоторые поля строки таблицы , могут хранится вообще отдельно от других полей этой же строки таблицы,что часто применяется например для больших объектов (LOB), которые часто выгоднее хранить отдельно от остальных данных, в то время как в реляционной схеме это такие же поля таблицы как и все остальные.
Физическая структура хранения связана с реляционной структурой только в смысле - "что система должна «уметь» преобразовывать эти структуры хранения и представлять данные на концептуальном уровне в чистой табличной форме."(с) Дейт
15 ноя 04, 10:44    [1105178]     Ответить | Цитировать Сообщить модератору
 Re: СУБД CACHE'  [new]
Я и ёжик
Member

Откуда: СПб
Сообщений: 1815
Я и ёжик
( в прочем как и Вы, чудя по след. сообщениям)

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

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

Andrey K

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

Да ладно я не понял, это не страшно, а ведь ещё Кодд, Дейт, Ульман и др.

Дейт: "В реляционной модели не рассматривается внутренний уровень систем баз данных, в частности внутренний уровень архитектуры ANSI/SPARC. В принципе в системе могут использоваться любые структуры хранения на внутреннем уровне. Единственным условием является то, что система должна «уметь» преобразовывать эти структуры хранения и представлять данные на концептуальном уровне в чистой табличной форме.".[1]


Правильно выразился я совсем не корректно! Признаю это. Просто я неправильно сформулировал то что хотел сказать. Подловили ;) Но вы то поняли о чём я на самом деле хотел сказать? :)
15 ноя 04, 11:06    [1105273]     Ответить | Цитировать Сообщить модератору
 Re: СУБД CACHE'  [new]
Andrey K
Member

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

Дейт: "В реляционной модели не рассматривается внутренний уровень систем баз данных, в частности внутренний уровень архитектуры ANSI/SPARC. В принципе в системе могут использоваться любые структуры хранения на внутреннем уровне. Единственным условием является то, что система должна «уметь» преобразовывать эти структуры хранения и представлять данные на концептуальном уровне в чистой табличной форме.".[1]

Дейт:"Идея реляционной модели применяется к внешнему и концептуальному уровням системы, а не к внутреннему уровню".[1]

Дейт:"Таким образом, обеспечение независимости данных – основная цель систем баз данных.
Независимость данных можно определить как иммунитет приложений к изменениям в структуре хранения данных и в методах доступа к данным, а это означает, что рассматриваемые приложения не зависят от любой конкретной структуры хранения и конкретных методов доступа".


Кодд : "Изначально ... реляционная модель ... рассматривалась как средство для освобождения пользователей от неприятностей, связанных с потребностью иметь дело с массой деталей представления хранимых данных". [2]

Правильно так она и есть РЕЛЯЦИОННАЯ. О чём я и говорю. :)
А что такое постреляционная? (приставка типа супер-пупер? )
15 ноя 04, 11:11    [1105298]     Ответить | Цитировать Сообщить модератору
 Re: СУБД CACHE'  [new]
Павел Воронцов
Member

Откуда: Новосибирск
Сообщений: 2400
Блог
Во! Андрей Леонидович MUMPS появился! Теперь сюда буду ходить развлекаться...
15 ноя 04, 11:58    [1105565]     Ответить | Цитировать Сообщить модератору
 Re: СУБД CACHE'  [new]
Павел Воронцов
Member

Откуда: Новосибирск
Сообщений: 2400
Блог
автор
логическое END


Это находка, однозначно! Буду студентов на экзамене загружать.
15 ноя 04, 12:06    [1105604]     Ответить | Цитировать Сообщить модератору
 Re: СУБД CACHE'  [new]
Andrey K
Member

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


Это находка, однозначно! Буду студентов на экзамене загружать.

Адназначно. Ну не то что бы логическое Это йа тоже погорячился. (тут подрозумевалось операцыи со множествами и эта логическая операцыя применительно к ним) Идея то ясна? ;)
Дафайте до слов не бутем дойо....
А то йа скоро йоб....сь.
Пойду лучше за пивом схожу.
15 ноя 04, 12:21    [1105665]     Ответить | Цитировать Сообщить модератору
 Re: СУБД CACHE'  [new]
Андрей Леонидович
Guest
Andrey K !

Вам уже пытались объяснить, что "технология" физического хранения в MUMPS одна - B-дерево. Технология логического представления данных ("родная") тоже одна - индексированный массив (тоже "дерево").
Структуру глобалов и "технологию" логического представления в приложении определяет разработчик приложения. Конечно, Вы можете считать, что это (MUMPS) глупость...
Насчет "определений" и "индексов": не ленитесь, пожалуйста, продолжайте заниматься самообразованием.
15 ноя 04, 17:28    [1107023]     Ответить | Цитировать Сообщить модератору
 Re: СУБД CACHE'  [new]
Андрей Леонидович
Guest
Andrey K !

Посмотрел на даты в теме "Сравнение ... СУБД". Ваши коллеги за ДВА ГОДА (!) не смогли даже в MUMPS разобраться, не то что в Cache или ОСУБД. А среди них есть даже ПРЕПОДАВАТЕЛИ (!) теории баз данных...
А у Вас вроде бы такой боевой настрой. Дерзайте. Если уж совсем запутаетесь, поможем...
15 ноя 04, 17:40    [1107061]     Ответить | Цитировать Сообщить модератору
 Re: СУБД CACHE'  [new]
ASCRUS
Member

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

Посмотрел на даты в теме "Сравнение ... СУБД". Ваши коллеги за ДВА ГОДА (!) не смогли даже в MUMPS разобраться, не то что в Cache или ОСУБД. А среди них есть даже ПРЕПОДАВАТЕЛИ (!) теории баз данных...
А у Вас вроде бы такой боевой настрой. Дерзайте. Если уж совсем запутаетесь, поможем...

Самое в этом печальное Андрей Леонидович, что коллеги Андрея даже не приступали к разбирательствам с MUMPS, вот стоит он у меня 2-умя этажами ниже, даже и не подозреваю чего то там делает, только стоны админов периодически слышны - "когда же его поменяют на MSSQL или хотя бы Cache", а у меня до сих пор не возникло желания пойти и посмотреть хотя бы внешний вид этого чуда. Скажите, означает ли это, что я потерянный для общества человек и никудышний специалист, совсем не разбирающийся в разработке баз данных ?

P.S. Гм, может быть мне к психоаналитику обратиться, чтобы хотя бы понять, как я могу проектировать БД без знания MUMPS :) Судя по Фрейду и Вашим высказываниям нам всем наверное только кажется, что мы проектируем и все работает ... этакая обманчивая релляционная матрица :)
15 ноя 04, 17:51    [1107100]     Ответить | Цитировать Сообщить модератору
 Re: СУБД CACHE'  [new]
Андрей Леонидович
Guest
ASCRUS !

По-моему у нас с Вами никаких противоречий нет (точнее: почти нет, все-таки один раз были). Я уже говорил, что Вы, наверняка, хороший специалист в области РСУБД. И возможностей РСУБД, которую Вы хорошо знаете, Вам вполне достаточно. И, по-моему, у Вас и не было никогда желания ни с чем другим разбираться. Это вполне нормально. А у многих здесь такое желание есть, но мешает "агрессивный" настрой (корпоративная солидарность - мы, все-таки, на sql.ru). Вы, кстати, тоже этим грешите, иногда. Что особенно странно выглядит на фоне "не желания разбираться"...
Так что зря Вы реагируете на мои слова про самообразование, которые к Вам, как раз, не имеют никакого отношения.
15 ноя 04, 18:19    [1107185]     Ответить | Цитировать Сообщить модератору
 Re: СУБД CACHE'  [new]
Андрей Леонидович
Guest
ASCRUS !

Напоминаю так же, что "никудышным специалистом, совсем не разбирающимся в разработке баз данных", здесь назначили, как раз, меня. Так что и в этом плане у Вас все в порядке.
15 ноя 04, 18:33    [1107224]     Ответить | Цитировать Сообщить модератору
 Re: СУБД CACHE'  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
Андрей Леонидович
ASCRUS !

По-моему у нас с Вами никаких противоречий нет (точнее: почти нет, все-таки один раз были). Я уже говорил, что Вы, наверняка, хороший специалист в области РСУБД. И возможностей РСУБД, которую Вы хорошо знаете, Вам вполне достаточно. И, по-моему, у Вас и не было никогда желания ни с чем другим разбираться. Это вполне нормально. А у многих здесь такое желание есть, но мешает "агрессивный" настрой (корпоративная солидарность - мы, все-таки, на sql.ru). Вы, кстати, тоже этим грешите, иногда. Что особенно странно выглядит на фоне "не желания разбираться"...
Так что зря Вы реагируете на мои слова про самообразование, которые к Вам, как раз, не имеют никакого отношения.

Ну тогда все таки давайте общаться на равных, поставив между технологиями и специалистами равенство: "MUMPS = SQL" и отсюда будем плясать на равных. Просто весь аггресивный настрой проистекает в отношении Вас не потому, что у сайта название sql.ru и кто то даже в мыслях может покоробиться, что есть что то лучше, чем SQL, а потому, что Ваше поведение не однозначно и многие Ваши высказывания выглядят как "Вы ничего не знаете и не умеете, уперлись носом в свой SQL и не видите, что те же аналогичные задачи можно решить по другому и более эффективно". Я всегда на этом сайте высказывал и буду высказывать мысль, что на любую задачу существует множество, порой даже отрицающих друг друга решений и частенько сам пользуюсь этой аксиомой в работе, стараясь постоянно расширять свой кругозор и применять довольно простые, неожиданные и эффективные решения в стандартных и нестандартных задачах, но не помню ни разу, чтобы я ткнул носом кого либо из за того, что я в чем то знаю больше - мне больше доставляет удовольствие поделиться с друзьями и коллегами идеями и наработками, чем построить из себя "крутого" специалиста. Все присутствующие здесь коллеги относяться к той же категории и всегда готовы поделиться опытом или поучиться ему у других. Насчет Вас я так и не понял - с одной стороны Вы вроде как хотите обьяснить, с другой стороны Вы толком ничего и не обьясняете, начиная уходить глубоко в теорию, давая ссылки на собственные материалы и туманно отвечая на вопросы коллег. Если Вы действительно хотите обьяснить, чтобы Вас поняли, то Вам придется еще и послушать обьяснения других. Наверное не стоит забывать, что истина рождается только в споре равных. В данном случае же и спор не уместен - идет дисскусия и ее участники не должны строить из себя авторитетов, даже если они знают/считают, что прекрасно владеют предметом дисскуссии, лучше уж обьяснить 100 раз, чем сразу заявить, что чужое мнение ошибочно, а собственное истинно.
15 ноя 04, 18:42    [1107245]     Ответить | Цитировать Сообщить модератору
 Re: СУБД CACHE'  [new]
vadiminfo
Member

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

что коллеги Андрея даже не приступали к разбирательствам с MUMPS, вот стоит он у меня 2-умя этажами ниже, даже и не подозреваю чего то там делает, только стоны админов периодически слышны - "когда же его поменяют на MSSQL или хотя бы Cache", а у меня до сих пор не возникло желания пойти и посмотреть хотя бы внешний вид этого чуда.

Вы так и не стали смотреть на MUMPS? Я будь такая возможность теперь глянул бы. Потому что никак не могу въехать как он соотносится с Кэшем. И в целом понять про то, как создана эта Кэш, чтобы классифицировать ее внутри класса ООСУБД, если она таковая. Но тут говорят, что она не совсем ООСУБД. Тогда вроде ясно почему про нее нет в литре. Но с другой стороны говорят что ООСУБД. А MUMPS только сбивает с толку еще больше. Он не ООП. Тогда зачем про него вспоминать? Это язык не ООП, в который транслируется функции ООСУБД Кэш? Что это меняет, если только в Кэше не надо пользоваться им на прямую? Или Кэш это ОО MUMPS, подобно тому как С++ и С? Все это как-будто специально притушевывается. Я и в инете искал.
Говорят про В-деревья. Причем здесь это? Это есть и у реляционных. У Оракла есть объект - индекс организованная таблица. Хотите быстро читать, но иметь тормоза при вводе и проч ограниченя делайте такие таблы. Кроме того, при нек запросах индекс ничего не дает в плане производительности. Это не связано с логической моделью вообще никак. Это вопрос конкретных СУБД.
А самое главное чем может Кеш на что-то претендовать - ОО, обходится стороной или в скольз упоминается. Если Кэш не ООСУБД, то либо реляционный, либо дореляционный и думать ему о сравнении с ведущими СУБД явно рановато в первом случае или поздновато во втором. Существуеет еще море разных СУБД.
Вы бы не могли спросить у этих парней со 2 этажа, что они думают про все это?
15 ноя 04, 19:16    [1107307]     Ответить | Цитировать Сообщить модератору
 Re: СУБД CACHE'  [new]
ASCRUS
Member

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

что коллеги Андрея даже не приступали к разбирательствам с MUMPS, вот стоит он у меня 2-умя этажами ниже, даже и не подозреваю чего то там делает, только стоны админов периодически слышны - "когда же его поменяют на MSSQL или хотя бы Cache", а у меня до сих пор не возникло желания пойти и посмотреть хотя бы внешний вид этого чуда.

Вы так и не стали смотреть на MUMPS? Я будь такая возможность теперь глянул бы. Потому что никак не могу въехать как он соотносится с Кэшем. И в целом понять про то, как создана эта Кэш, чтобы классифицировать ее внутри класса ООСУБД, если она таковая. Но тут говорят, что она не совсем ООСУБД. Тогда вроде ясно почему про нее нет в литре. Но с другой стороны говорят что ООСУБД. А MUMPS только сбивает с толку еще больше. Он не ООП. Тогда зачем про него вспоминать? Это язык не ООП, в который транслируется функции ООСУБД Кэш? Что это меняет, если только в Кэше не надо пользоваться им на прямую? Или Кэш это ОО MUMPS, подобно тому как С++ и С? Все это как-будто специально притушевывается. Я и в инете искал.
Говорят про В-деревья. Причем здесь это? Это есть и у реляционных. У Оракла есть объект - индекс организованная таблица. Хотите быстро читать, но иметь тормоза при вводе и проч ограниченя делайте такие таблы. Кроме того, при нек запросах индекс ничего не дает в плане производительности. Это не связано с логической моделью вообще никак. Это вопрос конкретных СУБД.
А самое главное чем может Кеш на что-то претендовать - ОО, обходится стороной или в скольз упоминается. Если Кэш не ООСУБД, то либо реляционный, либо дореляционный и думать ему о сравнении с ведущими СУБД явно рановато в первом случае или поздновато во втором. Существуеет еще море разных СУБД.
Вы бы не могли спросить у этих парней со 2 этажа, что они думают про все это?

Гм, я думаю ничего админов спрашивать не буду, так как изначально знаю то, что они могут думать обо всем вышеперечисленном не вписывается в правила форумов sql.ru и им глубоко начхать на такие умные термины, как ООП, ООСУБД, B-Tree и т.д. Они всего лишь простые админы и им всего то нужно, чтобы банковское ПО работало надежно и точно как швейцарские часы, плюс с достаточной скоростью и легким сопровождением. Хотя бы то, что им приходиться ждать как минимум до 21-00, пока все уйдут с банка, чтобы остановить MUMPS и сделать бакуп уже не прибавляет им настроения, а рост размера БД, стремительно приближающийся к максимальной как они говорят отметке внушает им тихий ужас. Так что думаю можно себе представить что они могут думать по этому поводу.
16 ноя 04, 00:32    [1107567]     Ответить | Цитировать Сообщить модератору
 Re: СУБД CACHE'  [new]
c127
Guest
2 vadiminfo

>Что значит опять начинается? И не кончалось. И не мной придумано. Вы же не можете расчитывать на отказ от общепризнанного в литре из-за того, что Вам это не нравится.

Общепризнанное начинается с определения. А в противном случае это ничего не стоящия спекуляции. Например сейчас общерпизнанно, что Эйнштейн построил специальную теорию относительности. Но это утверждение неверно. Так сказать контрипример, что даже абсолютно общерпизнанное не всегда является истинным.

>Иерархические, сетевые СУБД - до реляционные.

Согласен, это корректное определение.

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

А что значит "те или иные"? Это получается один видит "те" элементы, а другой утверждает, что это совсем не те элементы, а в качестве определяющих нужно брать совсем иные. И тот и другой прав. Вот, например, оракл является полностью ООМД системой.

>Отсутсвие общепринятой единой модели данных - недостаток, который не отменяет однако понятия ООМД.

Но этот недосток отменяет единое понятие ООМД со всеми вытекающими. Всего-навсего.

>ООСУБД - ООМД, радикальный подход - отказ от реляционности.

Это или опечатка или определение немногим лучше определения объекта, которое дал Андрй Леонидович:"ОБЪЕКТ - все, что противостоит субъекту в его предметно-практической и познавательной деятельности". Все что нереляционное - то ООСУБД. И пользы от него столько же, а именно никакой.

Кстати получается все дореляционные системы есть ООСУБД.

>Не знаю на что Вы расчитываете в попытках отрицать очевидное.

Ни на что не рассчитываю, пытаюсь разобраться.

Вообще-то единственная проблема состоит в том, что очевидное при ближайшем рассмотрении оказывается неочевидным, а того и гляди ошибочным.

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

Судя по этому форуму эта точка зрения все-таки доминирующая в БД. Но это не важно. Литературу пока найти не удалось, но я продолжаю поиски. Довольно сложно найти на шару книгу выпущенную пол-года назад, а покупать за $120 неохота. В библиотеке она все время на руках. Может есть другие ссылки? А то технология вроде признана всеми и широко используется, а литературы по ее основаниям нет вообще, точнее есть одна толко что изданная книга.

>В частности, в данной теме КЭШ. Она декларируется как ООСУБД. Так что же Вы тогда хотели? Если он не ООСУБД так и скажите. Кто он тогда?

За неимением лучшего определения я полагаю, что ООСУБД это СУБД, основанная на ООМД. Так вот, если, по данному Вами же определению, объектами назвать то, что определено в последнем стандарте C++ и не меньше, то кеш безусловно не ООСУБД, поскольку не поддерживает всех свойств объектов (лень искать, но наверняка не поддерживает всего), а следовательно не основана на ООМД. А что оно тогда - это не мне решать. А если по тому же Вашему определению ООМД называть что-нибудь попроще, например то, что используется в самом кеше, то тогда это кеш скорее всего есть ООСУБД. Вот такое у нас замечательное определение ООСУБД.
16 ноя 04, 04:23    [1107648]     Ответить | Цитировать Сообщить модератору
 Re: СУБД CACHE'  [new]
Павел Воронцов
Member

Откуда: Новосибирск
Сообщений: 2400
Блог
Андрей Леонидович
Andrey K !

Посмотрел на даты в теме "Сравнение ... СУБД". Ваши коллеги за ДВА ГОДА (!) не смогли даже в MUMPS разобраться, не то что в Cache или ОСУБД. А среди них есть даже ПРЕПОДАВАТЕЛИ (!) теории баз данных...
А у Вас вроде бы такой боевой настрой. Дерзайте. Если уж совсем запутаетесь, поможем...


А был ли мальчик? Есть в чём разбираться? Вы ж ни на один вопрос не ответили внятно и прямо. Давайте я повторю ключевой вопрос:

Андрей Леонидович, что такое по вашему ключ? Дайте определение пожалуйста.
16 ноя 04, 08:11    [1107749]     Ответить | Цитировать Сообщить модератору
 Re: СУБД CACHE'  [new]
Andrey K
Member

Откуда: Москва
Сообщений: 676
hint - "Включить правую половину мозга"
Андрей Леонидович

Посмотрел на даты в теме "Сравнение ... СУБД". Ваши коллеги за ДВА ГОДА (!) не смогли даже в MUMPS разобраться, не то что в Cache или ОСУБД. А среди них есть даже ПРЕПОДАВАТЕЛИ (!) теории баз данных...
А у Вас вроде бы такой боевой настрой. Дерзайте. Если уж совсем запутаетесь, поможем...

Не волнуйтесь Андрей Леонидович. :) Теперь они поняли. Всё элементарно.
Запутались вы. Я и Ёжик такие умные цитаты от дядьки Дейта привёл, я оспаривать эти концепции не смею. А вот вы до сих пор не можете понять, что модель данных на самом деле РЕЛЯЦИОННАЯ используется в Cache. (на концептуальном внешнем уровне). Так же вы не поняли и саму технологию - и какие из неё вытекают следствия... что бы её понять нужно сделать сравнительный анализ - с технологией обычных РСУБД.

vadiminfo

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

Ясен перец. Но "мухи"(логика) отдельно от "котлет"(данные). (См. Вовка) Технология Cache позволяет отказаться от синтаксиса SQL впринципе. Вместо него можно использовать язык более подходящий под понятие ООП. (и этот язык в некоторой степени поддерживает цитирую "те или иные элементы ООП")

SQL делится на две части - DML и DDL (это методы)
Данные (это свойства)

работаем с объектом.... который работает с данными...

=> СУБД Cache условно попадает под понятие РЕЛЯЦИОННАЯ и ОБЪЕКТНАЯ.

2 Павел - :) Ключ или "перекрёстная" ссылка есть у каждой ячейки данных в Cache на уровне метаданных. ......да избыточность есть.... НО.....

это всё IMHO Интересно всё таки я описал Cache или придумал собственную технологию. Во втором сомневаюсь очень сильно. (описания я так и не нашёл)
16 ноя 04, 09:15    [1107826]     Ответить | Цитировать Сообщить модератору
 Re: СУБД CACHE'  [new]
ну я
Member

Откуда: Москва
Сообщений: 1276
Что-то, господа, вы меня запутали. Разве объекты не могут находиться в отношении друг с другом, в реляции? В принципе, реляции можно найти везде. Другое дело что с реляционными базами прочно ассоциируется понятие таблицы / свалки неких структурно одинаковых хреновин. Традиционные sql движки поддерживают простое структурирование, продвинутые - более сложное, совсем далеко задвинутые - вообще динамически самоопределяются (не пугайтесь, есть и такие).

Может кто-нибудь толком объяснить, почему база должна быть либо реляционной, либо объектной, либо деревянной? А не пофигу ли, как я на нее посмотрю?
16 ноя 04, 10:51    [1108134]     Ответить | Цитировать Сообщить модератору
 Re: СУБД CACHE'  [new]
Maksim UM
Member

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

Гм, я думаю ничего админов спрашивать не буду, так как изначально знаю то, что они могут думать обо всем вышеперечисленном не вписывается в правила форумов sql.ru и им глубоко начхать на такие умные термины, как ООП, ООСУБД, B-Tree и т.д. Они всего лишь простые админы и им всего то нужно, чтобы банковское ПО работало надежно и точно как швейцарские часы, плюс с достаточной скоростью и легким сопровождением. Хотя бы то, что им приходиться ждать как минимум до 21-00, пока все уйдут с банка, чтобы остановить MUMPS и сделать бакуп уже не прибавляет им настроения, а рост размера БД, стремительно приближающийся к максимальной как они говорят отметке внушает им тихий ужас. Так что думаю можно себе представить что они могут думать по этому поводу.

Где-то я уже видел на этом форуме Ваши слова о том, что кривыми руками
можно многое сделать...
MUMPS - это стандарт. Реализаций MUMPSа хватает, под разные платформы.
Я работал с MSM версией MUMPS под дос. около 8 лет без перерыва (круглосуточно) работает система в пейджинговой компании. комп - п166, 64мб, 2Гб
на MUMPSе было написано все - передача сообщений, обработка базы (отчеты, управление, настройка системы), обработка модемных входов, прием электронной почты... бэкапы делались постоянно и без перерыва в работе.
По скорости работы никогда не было притензий, даже в лучшие времена пейджинга.
Естественно, что технологии устаревают и старые MUMPS системы быле не расчитаны на работу с петабайтными системами.

2 Andrey K
Andrey K
Запутались вы. Я и Ёжик такие умные цитаты от дядьки Дейта привёл, я оспаривать эти концепции не смею. А вот вы до сих пор не можете понять, что модель данных на самом деле РЕЛЯЦИОННАЯ используется в Cache. (на концептуальном внешнем уровне). Так же вы не поняли и саму технологию - и какие из неё вытекают следствия... что бы её понять нужно сделать сравнительный анализ - с технологией обычных РСУБД.

Еще раз, данные в Cache хранятся в Б деревьях. Это не модель данных,
это способ хранения данных (алгоритм см. Кнут). Язык MUMPS позволяет работать с деревом напрямую: проходить по дереву, добавлять узлы с данными и тд... В Cache синтаксис языка MUMPS был расширен для работы с объектами (у них язык называется COS). Объектные расширения являются надстройкой над MUMPS и позволяют упростить задачу обработки данных.
Но возможность напрямую обращаться к данным осталась.
В Oracle, MSSQL и компания нельзя менять принципы физической организации хранения индексов, данных, можно только выбирать из предложенного компанией. В Cache можно изменить способ организации индексов или как будут храниться (сохраняться) и где данные. Плохо это или хорошо вопрос отдельный.
Что мне нравится в Cache - это все в одном, это и БД и сервер приложений. Все можно писать на одном языке. Приложение работающее через терминал, через HTML (CSP, не путать с MS CSP), SQL - все может быть реализовано на COS. На мой взгляд это удобно.
16 ноя 04, 11:47    [1108440]     Ответить | Цитировать Сообщить модератору
 Re: СУБД CACHE'  [new]
Павел Воронцов
Member

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

Может кто-нибудь толком объяснить, почему база должна быть либо реляционной, либо объектной, либо деревянной? А не пофигу ли, как я на нее посмотрю?


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

1) Реляционной модель данных назвали по имени математических объектов (relation, отношение), коими оперирует теория данных Кодда. Отношения не являются таблицами. Это математический объект, множество определённого рода. Каждое отношение выражает некий предикат формальной логики со свободными переменными на месте атрибутов. Сей термин "отношение" имеет мало общего со "связями" между чем бы то ни было.

2) Язык SQL не является реляционным в полном смысле этого слова, хотя и начинал разробатываться именно как таковой. Равно как и современные СУБД не являются реляционными (по разным причинам). На основе этого факта можно констатировать "провал" РМД, но лично меня от такого вывода удерживают очень многие факторы.

3) У меня ассоциацию со свалкой скорее вызовет гигабайтный XML документ (который суть иерархическое хранилище), чем правильно спроектированная база данных.

4) Никакой другой модели данных кроме реляционной не существует. Я имею в виду именно формально описанную модель. Все остальные "модели" либо неформальны, либо неполны, либо сводятся к реляционной.
16 ноя 04, 11:55    [1108475]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 4 5 6 [7] 8 9 10 11 .. 24   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить