Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 10 11 12 13 14 [15] 16 17 18 19 .. 83   вперед  Ctrl
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
osse
Member

Откуда: Н-ск
Сообщений: 162
2SergSuper:
Про "доску, висящую на стене криво" там тоже неплохо задвинуто )
И про то что иерархическая модель не мененее "математическая" чем реляционная т.к. дерево это тоже математическое понятие.

А "cust_id integer REFERENCES Customers" - наверное все таки лучше и правильнее как есть, т.к. REFERENCES определяет в первую очередь ограничение на значения столбца cust_id.
2 июн 04, 16:12    [717031]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Андрей Леонидович
Guest
Уважаемые коллеги !

Обсуждение "технических вопросов" в такой форме абсолютно бесполезно - это объективная реальность. Чтобы это понять достаточно полистать страницы этой дискуссии. Вот простой пример по свежим следам. Мечтой и теоретиков, и практиков баз данных всегда был интегрированный язык баз данных. Mumps - это первый стандартный изначально интегрированный язык баз данных (в двадцатилетних муках к такому статусу приближается SQL). Мало того, что об ЭТОМ никто не сказал, так еще и что изменилось от того, что я это сказал ? Уважаемый с127, что изменилось в Ваших представлениях от того, что я это сказал ? Что изменится от того, что я дам Вам ссылки на статьи, где это написано ? А если я дам Вам такую странную ссылку: К.Дейт. Введение в системы баз данных. Прочитав эту книгу, я еще раз убедился, что реляционная модель - это шаг назад, а SQL бесполезен для доступа к данным. Почему ? Да потому, что у меня есть определенный багаж знаний. И все КЛЮЧЕВЫЕ знания, буквально перевернувшие мое понимание баз данных, я получил непосредственно от людей, которым я безумно благодарен. И благодаря этим знаниям я вижу, что К.Дейт допускает некорректные, мягко говоря, высказывания, чтобы у читателей сложилось впечатление, что в реляционной модели данных есть какой-то смысл. Я совершенно не стремлюсь осчастливить своими знаниями человечество. Мне важно, чтобы мои знания помогали людям, которые мне верят, и за которых я отвечаю. И мне действительно безразличен объем рынка Cache (безуслово очень небольшой по сравнению с рынком реляционных систем). Мне важно, чтобы в Cache был бы хорошо реализован MUMPS. И он там, к счастью, реализован хорошо.
Если я ЗДЕСЬ скажу, например, что более 90% чтений данных из базы данных в типичных приложениях OLTP составляют:
1) прочитать конкретный атрибут конкретного кортежа конкретного отношения;
2) прочитать ВСЕ кортежи отношения B, связанные с конкретным кортежем отношения A.
Это что-нибудь изменит ? Да нет. ЗДЕСЬ я все равно останусь маргиналом, специалистом из советского НИИ, человеком с неправильными детородными органами и, наконец, плохим докладчиком (а если без полунамеков - никудашным специалистом). Потому что людям, использующим реляционные СУБД, очень трудно поверить в то, что SQL бесполезен, и я их прекрасно понимаю.
А когда я лично кому-то из вас буду показывать как работают приложения без SQL, как написан код, буду рисовать на листе бумаги схемы, и мы будем смотреть друг другу в глаза, то есть общаться по-человечески, мы очень быстро поймем друг друга.
Я проявил максимальную открытость: опубликовал свои фамилию, имя, отчетсво, место работы, телефон. Вот еще мой адрес: andrey_chernyshev@informx.ru.
Искренне благодарен всем, кто отреагировал (в любой форме) на мои сообщения.
2 июн 04, 17:41    [717354]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
Вот так вот круто :) Не то что мы, глупые и длинные запросы пишем, которые все равно не работают:
автор

"Запас компактности" рассмотрим на примере: записать во все Заказы, сделанные в этом году (позже 31 декабря 1998 года) Покупателями из Города London, Дату заказа 1 января 1999 года:

- если нет индекса по Дате заказа для привязанных к Покупателю Заказов:

n ea,ez
s ea="" f s ea=$$O^%cpad("A",3,"London",ea) q:ea="" d
.s ez="" f s ez=$$OC^%cpadc("A","Z",1,ea,ez) q:ez="" i
$$G^%cpgd("Z",ez,2,"",1)>19981231 d U^%cpuh("Z",ez,2,19990101)
.q
q

- если есть индекс:

n ea,ez,dt
s ea="" f s ea=$$O^%cpad("A",3,"London",ea) q:ea="" d
.s dt=19981231 f s dt=$$OZ^%cpadi("A","Z",1,ea,2,dt) q:dt="" s
ez="" f s ez=$$O^%cpadi("A","Z",1,ea,2,dt,ez) q:ez="" d
U^%cpuh("Z",ez,2,19990101)
.q
q

Общепринятые преимущества:

1) один язык программирования;
2) компактность программы при "простых" "запросах";
3) ясная семантика.


Тоже неплохое и смелое высказывание:
автор
Более того в любой реляционной СУБД предусмотрено множество ПРЯМЫХ указаний программиста "оптимизатору" (в данном контексте логично использовать кавычки): использовать такой-то индекс, использовать полное сканирование таблицы, соединять таблицу именно таким-то методом.



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

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

Ну с такими идеологами - в добрый путь. Будем все дружно ждать СУБД "Нового поколения", думаю уже не долго осталось :)
2 июн 04, 17:49    [717385]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
jvvjvv
Member

Откуда:
Сообщений: 56
"Всякая лягушка СВОЕ болото хвалит" - так было, есть и будет.
2 июн 04, 18:14    [717469]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
ну я
Member

Откуда: Москва
Сообщений: 1276
Честно говоря, ссылочку на доклад дал я.
Ну очень уж хочется свести два мира, идеологов мампсистов и sql-щиков, чтобы раз уж хают друг друга, то и разбирались бы друг с другом, кто там круче. Чтобы технарям мозги не парили крутостью оптимизаторов, плоскостью таблиц и кудрявостью глобалов.
От себя - вот представил себе, приду сейчас к ребятам с распечатанной парой тыщ топиков навскидку из форума по mssql, и скажу - все, господа, теперь переходим на другую систему. Теперь будем жить с оптимизатором, однако. Но при этом у нас будут для начала вот такие вот проблемсы, и мы ничего не сможем сделать кроме того как скакать вокруг этого с бубнами и убеждать друг друга что заказчику будет легко найти спеца по этой куче бубнов и убедив в этом же заказчика он будет нам благодарен за такую возможность по гроб жизни.
Ой, ну не надо думать, что кашисты - такие уж дремучие и кондовые фанаты, что мы живем строго в таинственных НИИ, общаемся на таинственном языке и ничего больше не знаем. Знаем и про оптимизаторы, и про базы, и про принципы. И мы вовсе не имеем ничего против независимости программ от физического размещения данных. И мы вовсе не против оптимизаторов. Вот только в комплекте с оптимизаторами идет такое чудо, которое никак нельзя изменить. А мампсы работают как холодильники - главное чтобы сервер был в розетку включен. Остальное исправимо и не так уж это сложно, как пугают зависимостью программ от хранения данных. А разговоры про какие-то там модели - это для умных, а нам бы то что работает. Вы думаете, почему есть столько обсуждения проблем mssql и oracle, и столь мало обсуждения проблем mumps? Фичи, которыми хвалятся эти товарищи при выпуске новых версий, на мампсах ручками делаются за месяц-другой (а то и меньше) и забываются. Лично мне диковато было в свое время настраивать почту в mssql - для этого понадобился целый Exchange. А делов-то послать текст на заданный порт. И такую возможность (и остальные) я должен считать достижением и удобством и благосклонностью производителя? А не пошел бы этот производитель своей дорогой? С оптимизатором.
2 июн 04, 18:23    [717489]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Я и ёжик
Member

Откуда: СПб
Сообщений: 1815
Уважаемый Андрей Леонидович, извините, но мне кажется не очень корретным, обрмлять сообщения высказываниями "Уважаемые...." и искренне Ваш", а в середине высказывать мысль, да что вам, что то говорить всё равно не поймете идиоты...

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

А вот про выпады в стороны "вас всех" хочется всё таки сказать:
Андрей Леонидович
Что изменится от того, что я дам Вам ссылки на статьи, где это написано ?

Те кому интересно смогут их прочитать, многие смогут понять, некотрые проанализировать, изменить свои взгляды или укрепить их, только и всего.
Но разве это плохо?

Андрей Леонидович
И все КЛЮЧЕВЫЕ знания, буквально перевернувшие мое понимание баз данных, я получил непосредственно от людей, которым я безумно благодарен. И благодаря этим знаниям я вижу, что К.Дейт допускает некорректные, мягко говоря, высказывания, чтобы у читателей сложилось впечатление, что в реляционной модели данных есть какой-то смысл.

Ну дак и откройте знания, дайте и другим просветится. Ну нет у меня возможности за ради встречи на час с Вами тащится в Москву.
А рисовать можно в общем не только на бумаге...

Андрей Леонидович
Это что-нибудь изменит ? Да нет. ЗДЕСЬ я все равно останусь маргиналом, специалистом из советского НИИ, человеком с неправильными детородными органами и, наконец, плохим докладчиком (а если без полунамеков - никудашным специалистом).

Вам так важно кем Вы останетесь ЗДЕСЬ? Да давайте произведем Вас в "Великие Просвитители" или в "Свет Баз Данных", можно и правильные детородные органы приплести, это поможет Вам больше внимание уделять фактам и теориям а не обсуждению "поймут меня эти идиоты или нет". Да не важно даже если один идиот поймет а десять задумаются и то хорошо.

С уважением идиот Я и животное Ёжик. ( ToKisa <пёс> mail.ru )
2 июн 04, 18:36    [717532]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Andreww
Member [заблокирован]

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

Если вы приведённую статью читали, то уже боюсь даже предположить,
что вы там 20 лет изучали.

2 ну я

Учите математику, она РУЛЕЗ.

Итак статья


1.2. Гипотезы и модели


Будут больше интересны философам и лингвистам, попробуем сразу прочитать про модели.


….

Какова подоплека создания Коддом так называемой "реляционной модели" [1] ?

Рассмотрим два множества

S1 (1,7,30)
S2 (красный,синий)

Их смысл не имеет значения для реляционной модели (то есть для математики).


Базовым понятием реляционной модели является декартово произведение



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


(например, первой операцией обработки запроса SELECT в SQL, конечно в теоретическом плане, является вычисление декартова произведения таблиц, перечисленных в инструкции FROM).


Что ещё за SELECT и кто такой SQL ? При чём тут реляционная модель ?


Декартово произведение множеств S1 и S2 даст следующий результат:

….

Эта операция может быть полезна для:

- проектирования и предсказания объектов (то есть такой объект - объект с такими характеристиками - может существовать);
- развития творческого воображения (черный снег, двигатель внутреннего тушения и т.п.).


Таких «полезностей» можно навыдумывать очень много, только к формальному аппарату реляционной модели они не имеют никакого отношения.



Каждая строка "таблицы" R называется кортежем (это строгий математический термин). А сама "таблица" - отношением.


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


В рассмотренных примерах с множествами S1,S2,S3 и отношениями R и Q уже предполагается, что мы ставим математическое понятие "кортеж" (математика у Кодда ПЕРВИЧНА) в соответствие некому гипотетическому объекту (пока еще непонятно какому).


Какому ещё объекту, тому который противостоит субъекту ? Автором «уже предполагается» ? Читателю должно быть непонятно ? Кто и когда поставил кортеж в соотношение некоему объекту ? В результате операций над множествами S1, S2, S3 получили отношения R и Q они могут быть и некоторыми объектами, а могут быть и столь любимым автором «чёрным снегом». Автор забывает, что он находится не на «филосовском базаре», а предоставляет формальное описание модели, а за фразы «уже предполагается» с экзамена (не по философии) выгоняют в шею.


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


Смысл начинает придаваться исключительно автором в его воображении. Абзацем ранее было непонятно какому объекту.


Кодд как бы сказал: давайте так представлять мир, чтобы над его объектами можно было бы совершать математические операции.


Всё таки наверное предметную область, а не мир, правда ?


Сначала он уточнил, что отношение - это ПОДМНОЖЕСТВО декартова произведения.


Вне сомнений, но мне кажется всё таки уточнил это не Кодд, теория множеств была придумана задолго до него.


Первый шажок к гипотезе 1: существует объект (1,красный,зима), но не существует (1,красный,лето).


Ещё одна неправильная предпосылка – это ПОДМНОЖЕСТВО, может включать в себя оба множества из декартова произведения. (Вторая или даже первая лекция из теории множеств). И кроме эквисоединения, на которое автор намекает словами (красный,лето) есть ещё неэквисоединение, пересечение, объединение, и прочее.


Затем Кодд пишет (считайте, для простоты, что домен - это колонка таблицы): "Обычно [? - И.И.] один из доменов данного отношения имеет величины, которые уникальны для каждого кортежа отношения".

На этом неформальном и не соответствующем действительности высказывании Кодда собственно и закачивается алгебра, то есть заканчивается


Обычно, действительно уникально, но не всегда, о чём и говорит Кодд.



РЕЛЯЦИОННАЯ МОДЕЛЬ и начинается МОДЕЛЬ ДАННЫХ Кодда, суть которой заключается


Не полезу, в дебри МОДЕЛИ ДАННЫХ, там всё ещё хуже, намного хуже.
Вот так "спИцИлисты" допустив пару тройку ошибок в формальном описании
("уже понятно",подмножество) начинают критиковать, но не реляционную модель, а непонятную модель Кодда-Чернышева, которая, строго говоря, неформализована и конечно же является плохой.

Кстати больше никаких формальных описаний в статье (докладе) не приводится, а обещали как минимум несколько (судя по заголовку).
2 июн 04, 18:38    [717537]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Andreww
Member [заблокирован]

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

Очепяточка - вместо "на самом деле подмножество декартова произведения двух объектов называется бинарным отношением, есть ещё унарное и n-арное" следует читать "на самом деле подмножество декартова произведения двух множеств называется бинарным отношением, есть ещё унарное и n-арное"

Прошу прощения (тяжко без научного редактора ).
2 июн 04, 18:42    [717545]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
Андрей Леонидович
Обсуждение "технических вопросов" в такой форме абсолютно бесполезно - это объективная реальность.

Если исходить из того что MUMPS - идеальная среда, а SQL бесполезен - то да, обсуждать нечего.
Но если приводить какие-то факты - то бывает очень даже полезно. Например почти 90% того что я знаю об Оракле я узнал отсюда. Согласен что я о нем всё равно очень мало знаю, но я хоть лучше вижу недостатки MSSQL и вижу куда стремиться развитие СУБД.

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

А чё за проблемсы то? Почту можно было бы и на mssql свою написать, чтоб в порт текст посылала, можно и не писать, а поискать в Инете библиотечки.
Еще что?
2 июн 04, 18:44    [717553]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Alexander_Chepack
Member

Откуда: London
Сообщений: 22649

И все КЛЮЧЕВЫЕ знания, буквально перевернувшие мое понимание баз данных, я получил непосредственно от людей, которым я безумно благодарен. И благодаря этим знаниям я вижу, что К.Дейт допускает некорректные,


А воду по телефону не заряжаете? Или по фотографиям порчу не снимаете?
2 июн 04, 19:22    [717645]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
ну я
Member

Откуда: Москва
Сообщений: 1276
2 SergSuper
А чё за проблемсы то?

Да вот почитываю посты (уважаемого мной, кстати) ASCRUS, так мягко говоря волосы шевелятся - как ни проблема так решение в смене версии или вообще продукта. Одно есть в одном сервере, другое в другом. Ситуация неудовлетворительная по сравнению с возможностью просто добавить что нужно самому. На мой взгляд это и есть проблема, просто звучать она может по-разному. Вы же прекрасно понимаете, что если автомат (речь о рантайме и его функциональности) не в курсе что делать кроме того что он умеет (или понимает), то шаг влево - шаг вправо - это либо нельзя либо жутко неэффективно либо левой ногой через голову. Скажем, мне весьма импонирует работа программистов МС над версией двухтысячника. Сделано много, но что же было у пользовавшихся семеркой... Но отдельные фичи, которые в sql - движке могут быть реализованы только на уровне ядра, могут появиться только у них, нам же останется только ждать сервис паков и следующих версий и так по кругу. Затыки есть практически у всех реализаций, кстати говоря, не только у МС. Возьмите те же глюки в оптимизаторах когда они не видят индексов при уровне вложения селектов выше какого-то магического числа или кардинально меняют план выполнения при смене числа альтернатив в выражении where column in (...). Не будем меряться на простых запросах - они отрабатываются нормально. Я говорю о тех, когда приходится тюнить запросы длительное время и настоятельно убеждать оптимизатор. Вместо того, чтобы просто написать что нужно там ему сделать приходится писать фактически то же самое но на еще более египетском языке и надеяться, что это ему и дальше поможет. В свое время оракл, кстати, ввел таблицы объектов как самостоятельный тип именно по причине того что это было проще сделать, и "присоветовать" мигрировать на вложенные таблицы, чем устранить проблему оптимизатора на вложенных запросах. А что проблемсы решаемы, я в курсе. Вопрос только нафига они мне.
2 июн 04, 19:52    [717682]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
ну я
Да вот почитываю посты (уважаемого мной, кстати) ASCRUS, так мягко говоря волосы шевелятся - как ни проблема так решение в смене версии или вообще продукта. Одно есть в одном сервере, другое в другом. Ситуация неудовлетворительная по сравнению с возможностью просто добавить что нужно самому.

Спасибо за уважание. Но все таки хочу заметить, что на связке ASA9 + PB9 я сижу уже второй год и никаких дерганий в сторону других продуктов/решений не наблюдается. Только честно качаю и ставлю каждый месяц Express Bag Fix, а уж что там идет не только исправление найденных (в том числе и мной) ошибок, но и расширение функциональности, так это только хорошо. Добавили новые возможности OLAP, после удовлетворительных тестов я включил их в свой проект, плохо что ли грохнуть огромную ХП с кучей запросов и использованием времянок, и переписать все одним запросом для расчета нарастающих и коэффициентов по группам за периоды :) Так же думаю никто не будет жаловаться на то, что вместе с патчем добавили новые алгоритмы для оптимизатора, позволяющие ему еще умнее и быстрее выполнять запросы. Всегда приятно, установив патч, выполнить без каких либо изменений с моей стороны сложную логику на сервере за более короткое время с более удачным планом запроса :)

Так вот для своих задач я на 100% доволен ASA и полностью обеспечен требуемой производительностью, функциональностью и гибкостью этой СУБД. Не хватает только событий на DDL, но это с жиру и больше для себя, чем реальных проектов. Так что не знаю, где там чего дописать руками можно, я раньше тоже чего только руками не делал (даже собственную файл-серверную СУБД уже на обьектах для TP 5.5), но как то вот сейчас не хочется :) Наверное это от того, что раньше я рассуждал как программист, а сейчас на все это смотрю с точки зрения архитектора и точно знаю, что при желании ручками можно много чего написать и даже запустить, вот только по любому криво это работать будет и чем дальше по времени, тем сложнее что то "свое" будет состыковать с новыми направлениями и технологиями.

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

Я например уже не первый раз встречаюсь с ситуацией, когда есть огромная консолидированная база на Оракле и куча удаленных точек, где не то что администратора Оракла, а интернета не найдешь. Крутиться там все как обычно на Clipper или FoxPro, естественно никого уже не устраивают различное сочетание кусочков программ, в сочетании с ручным трудом юзеров. Хотят переделать. Предлагаю им рассмотреть, как вариант, БД удаленных офисов переложить на ASA, мотивируя это нулевым администрированием, не уступающим PL/SQL ее WatcomSQL, гетерогенными репликациями, способными даже в оффлайн общаться с Ораклом, низкими аппаратными требованиями, надежностью и т.д.. И что Вы думаете - отказываются даже рассмотреть этот вариант только потому, что ASA очень мало стоит (думаю обьяснять не надо почему). Начинают бубнить, что лучше уж мы каналы связи протянем, спутник запустим, веб-решения через модем сделаем, склонируем достаточное кол-во админов и т.д. Так что скоро по всей России я думаю будут одни администраторы Оракла, раз его так массово ставят куда надо и не надо, наверное даже на дальнем Севере :)
2 июн 04, 23:12    [717839]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
c127
Guest
2 osse

>И про то что иерархическая модель не мененее "математическая" чем реляционная т.к. дерево это тоже математическое понятие.

Так все, что реализовано на компьютере, есть "математическое понятие". Но дело в том, что для того, чтоб хоть как-то использовать достоинства математики необходимо В ЯВНОМ ВИДЕ сформулировать математические основания. Неявные формулировки не прокатывают.

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

>Уважаемый с127, что изменилось в Ваших представлениях от того, что я это сказал ?

То что Вы тут сказали об РСУБД и М-системах есть Ваши заключения (выводы), без посылок и доказательств, и по-моему нельзя обвинять человека в том, что он не желает принимать на веру Ваши выводы только на основании того, что Вы потратили на них 20 лет жизни (что тоже требуется принять на веру без доказательства).

>Что изменится от того, что я дам Вам ссылки на статьи, где это написано ?

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

>А если я дам Вам такую странную ссылку: К.Дейт. Введение в системы баз данных. Прочитав эту книгу, я еще раз убедился, что реляционная модель - это шаг назад, а SQL бесполезен для доступа к данным.

Очень хорошо, но это Вы как-то обосновали шаг назад, а вот шаг вперед пока висит в воздухе. А вдруг этот шаг назад как раз и есть лучшее решение?

В девятнадцатом году наша страна стояла на краю экономической пропасти, а в двадцатом сделала большой шаг вперед. (С)

Так что вместо того чтоб тратить силы на длинные посты, дали бы пару ссылок, за двадцать лет исследований их наверняка у Вас накопилось предостаточно, и вопрос бы прояснился.
3 июн 04, 01:59    [717936]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Зл0й
Member

Откуда: Северная Калифорния
Сообщений: 686
Я вообще не понимаю зачем мампсы городить? Если так уж сильно падает производительность, из-за того что данные лежат в "куче" (heap-organized table) ну так положить их в структуру, где они хранятся упорядоченно (index-organized table). Я использую Оракловую терминологию, но Sybase/MS SQL вроде тоже позволяют кластерные индексы строить. Это хоть и не то же самое, но в конечном счете на производительности отражается примерно так же. Этот трюк (укладывание данных по порядку) еще в дореляционных мэйнфреймовых системах применялся. Никакого особого новомодного-революционного изобретения тут нет. Сей подход имеет как достоинства так и недостатки. В реляционныой СУБД Оракл, где физическая модель отделена от логической я одну и ту же таблицу могу реализовать как:

1. heap-organized
2. heap-organized с различными индексами
3. heap-organized с индексом по всем колонкам (частный случай 2)
4. index-organized
5. index-organized с дополнительными индексами (Оракл 9 и новее)
6. другими способами (различные кластеры итп.)

Причем я могу играться с физической организацией как угодно, пока не добъюсь нужной мне производительности. И код приложения мне при этом трогать не потребуется, если оно грамотно написано. Вот за что ваш покорный слуга любит реляционную модель. Я - "практичный сукин сын" (С).

Так что хранить данные в b* деревьях я и в Оракле могу. Зачем городить специальную СУБД для этого? И зачем смешивать логическую модель с физической?

Кстати, "гениальная идея" об отделении логической структуры от физической процветает и в объектно-ориентированном программировании. Интересующимся советую почитать "Design Patterns Elements of Reusable Object-Oriented Software" Erich Gamma [et. al]

Кстати, для сведения уважаемым кэшистам: SQL - язык с точки зрения реляционной модели "ущербный". А "правильный" аппарат - реляционное исчисление и реляционная алгебра. Так что недостатки SQL могут объясняться (и объясняются тем же Дэйтом) как возникшие вследствие отхода от реляционной модели. А вовсе не как недостаток самой модели.
3 июн 04, 02:26    [717944]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
2 ну я
Вот у США госдолг больше чем у нас и проблем у них поболее наверное, но это же не значит что мы их богаче.
До каких-то проблем еще и дорасти надо.

А я бы лучше работал и на MS SQL 4 чем работать с записями.
3 июн 04, 14:53    [719654]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
tchingiz
Member

Откуда:
Сообщений: 39052
Злой>
SQL - язык с точки зрения реляционной модели "ущербный". А "правильный" аппарат - реляционное исчисление и реляционная алгебра. Так что недостатки SQL могут объясняться (и объясняются тем же Дэйтом) как возникшие вследствие отхода от реляционной модели. А вовсе не как недостаток самой модели
Злой>
критика Дейтом SQL это его не удовольствие, что sql возвращает повторяющиеся кортежи (отход от множестве) или есть еще претензии?
имхо, Дейт недоволен был реализацией sql, а не "самим sql".
Мне интересно, у меня почему то сложилось впечатление, что на реляционной алгебре писать легче. без относительно к реализации, в том смысле, что если пользоваться языком как средством записи.
5 июн 04, 00:34    [724005]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
vadiminfo
Member

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

А я пробовал: одна таблица (2 поля - integer и varchar2) со 100 mln записями.
Так вот - простой select с where по varchar2 - и Cache 5 выигрывает у oracle 9i. Выигрыш во времени порядка 5%.

Можно сравнить oracle 9i с oracle 9i на одном компе и один будет выигрывать более чем на 5%. Я однажды сравнивал 8i с 9i и первый выигрывал, пока не выяснилось, что при импорте сравниваемой таблы блоки заполнялись так, что их просто было больше в табле на 9i. Когда исправил и стал сравнивать с одинаковым числом блоков 9i стал выигрывать. Поэтому такие сравнения нуждаются в проверке, а лучше присутствия специалистов фирмы.
Кроме того, это ворос реализации СУБД, а не вопрос модели данных. Т.е. нужно доказывать, что объективная модель данных быстрее по своей природе на таких компах, которые существуют сегодня.
Насколько мне известно - реляционная модель данных не адекватна для некоторых ПО. Например, Геоинформационных систем. Но там где она адекватна она имеет слишком большие преимущества: лушее мат. обоснование, простоту моделирования и т.д. И это одна из проблем для объектноориентированных, если она претендует на повсеменное использование. Разработчики реляционных пошли по пути объектно-реляционных СУБД. Кто выиграет сегодня говорить рано, но если выиграет объектноориентированая модель, то это произойдет не скоро, исходя из истории развития СУБД.
7 июн 04, 02:48    [724880]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
c127
Guest
2 vadiminfo
>Насколько мне известно - реляционная модель данных не адекватна для некоторых ПО. Например, Геоинформационных систем.

Очень даже адекватна, просто нужно БД строить адекватно и все будет очень хорошо.

Для того чтобы доказать, что решение на другой модели лучше чем на реляционной, необходимо эту другую модель как минимум строго записать. А это как раз и не сделано. Так что сравнивать пока не с чем.
7 июн 04, 07:54    [724940]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
vadiminfo
Member

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

Очень даже адекватна, просто нужно БД строить адекватно и все будет очень хорошо.

Известно, что существуют недостатки реляционной модели, которые признаются и ее сторонниками: семантическая перегруженность, существование запросов, не выразимых в реляционной алгебре (транзитивное замыкание) и т.д. Ясно, что затолкать реальный мир в таблицы не всегда просто. Поэтому сторонники реляционных моделей смотрят в сторону объектно-реляционной модели данных. В частности, Оракл назывет себя объектно-реляционной СУБД. Хотя, конечно, объектное в нем больше используется для программирования, а не хранения данных, если не обращать внимания на interMedia, Spatial. Кроме того, существует понятие полуструктурированных моделей данных - XML (т.е. не все огранивается сравниваемыми здесь моделями). Производители реляционных СУБД и их включают в частности Оракл. Кроме того, существуют модели данных для хранилищ данных - мультиразмерные БД (звезда, снежинка) используются для OLAP и тоже включаются впроизводителями РСУБД, в частности Оракл. Я, думаю, что сегодня корректно сравнивать модели в плане победы сложно.
Для победы у новой модели нужно какое-то очевидное преимущество от всех других, иначе просто не преодолеть инерцию. Реляционные победили предшественников наличием эффективных средств быстрого извлечения информации – языков типа SQL. И хотя они были значительно медленнее на тот момент, это преимущество решило их коммерческий успех.
Да и в случае победы ООМД производители РСУБД могут не просто переключиться на них, но и обеспечить перенос данных туда - миграцию, а инстоляций ведь море. А мы с ними проскочим - еще не известно насколько это актуально для разработчиков.
7 июн 04, 11:03    [725306]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
U-gene
Member

Откуда: Москва. Россия
Сообщений: 1576
Сил нет это читать...

автор
...реляционная модель данных не адекватна...


Те кто так пишет, сами неадекватно понимают что такое "модель данных". Напомню, что модель данных - это множество типов, множество операций и множество ограничений целостности данных.... И ВСЁ!!! Требовать от нее адекватности (или неадекватности) - все рано, что требовать адекватности у алфавита и правил грамматики.

автор
Ясно, что затолкать реальный мир в таблицы не всегда просто


Ну почему никто не требует адекватности у оперативной памяти или у компа? Ведь та же фигня - есть множество типов (всякие байты, целочисленные, с плавающей точкой), есть набор опереаций (реализуемых процессором), есть некие ограничения (например ссылки не может выходить за грницы адресов). И все это реализовано в железе..... (дык реляционная модель реализована в математике, что ИМХО в силу своей однозначности будет пожелезнее любого компутерного железа....) но ведь никто не говорит, что комп - неадекватый, и что "затолкать реальный мир в ОЗУ не всегда просто".... УЖЕ ЗАТОЛКАЛИ, хотя ОЗУ вообще одномерно (это я тем, кто воспронимает отношения как "двумерные" таблицы, что есть ошибка). И ничего другого такого математически-железного как рел. модель пока не предложено.

В общем не надо выдумывать того, чего нет. Тот факт, что Кодд и другие описывая рел.модель предлагают некие осмысленные примеры (например у Дейта это БД заказов, кочующая из одной его публикации в другую) дык это только.... мммм..... для наглядности. То есть если бы он вместо осмысленных имен (поставщик, деталь и т.д.) обозвал бы их A, B.... и т.д., то реляционная модель от этого никак не пострадала бы и не изменилась. Ну есть в рел. модели имена, можем мы вкладывать в них некий смысл.... но это не значит , что рел. модель на этот смысл как то претендует.
7 июн 04, 12:14    [725536]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
vadiminfo
Member

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

Напомню, что модель данных - это множество типов, множество операций и множество ограничений целостности данных.... И ВСЁ!!!

Не типов а структуры данных в общем случае.
Это не исключает естественных требований к ее адекватности (выразительности). Собственно без этого понятие модели может быть не достаточно полезным. По крайней мере этому придается значение. в частности, всегда существовали попытки создать более адекватные модели. Их более 300, но большинство академические - не нашли коммерческой реализации. Я уже не говорю, что модели делятся на инфологические и датологические. Первые из которых откровенно стремятся к максимальной адекватности без учета компьютерных структур. Вторые, к которым относится и реляционная модель, учитывают комп структуры, в частноcти программирование (SQL) и соответственно преобретают ограничения. Например, оказываются в классе сильнотипизированных моделей, но выигрывают в операциях и т.д.
Если отказаться от адекватности, то может реляционная модель и не имеет пока альтернатив. Но вряд ли от этого требования откажутся.


автор
Ну почему никто не требует адекватности у оперативной памяти или у компа?

Вообще - требуют. Известно, что Фон Нейманоские машины лучше походят для расчетов, а не обработки информации. Предпринимались попытки создания машин с ассоциативной памятью или большой оперативной памятью и т.д.
Можно вообще вспомнить, что существуют попытки создать базы знаний, которые потребуют не только своих моделий, но вычислительных систем. Так, если не обращать внимания на нейронные сети, о все компы - алгоритмические. А понадобятся системы искусственного интеллекта.
7 июн 04, 13:01    [725752]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
vadiminfo
Member

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

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

Это семантичность модели. Она тоже имеет большое значение. Так одним из недостатков реляционной является семантическая перегруженность (я писал выше). В частности, для реализации связи многие ко многим в реляционной модели приходится использовать ассоциаоивные отношения, которые не соответствуют никаким объектам реального мира. Но адекватность включеат в себя большее, чем семантичность. Например, в геоинфрмационной системе или системе документов придется хранить изображения или тексты. Однако, с точки зрения реляционной модели каждое такое изображение или текст - одно неделимое значение - знак. В то время как они содержут в себе много информации (знаков).
7 июн 04, 13:48    [725985]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
vadiminfo
В частности, для реализации связи многие ко многим в реляционной модели приходится использовать ассоциаоивные отношения, которые не соответствуют никаким объектам реального мира. Но адекватность включеат в себя большее, чем семантичность.

А как-нибудь по-русски можно?
Я например не вижу никаких противоречий в хранении текста или изображения для элементов карты.

А понадобятся системы искусственного интеллекта.

Память всё равно останется линейной :)
7 июн 04, 14:20    [726105]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
Про перегруженность:
Есть наприме оборудование и есть помещения в которых это оборудование расположено. В одном помещении может быть много разного оборудования, но и оборудование может приналежать разным помещениям. Для выражения связи в реляционной модели придется создать еще одну таблу с первичными ключами оборудования и помещений. Но этой табле ничего не соответствует в реальном мире.
Про изображения. Хранить то можно, но как одно значение - неделимое. Но в модели еще есть операции и ограничения целостности. Например, нужно получать информацию о возможных маршрутах на основе анализа местности. Но у реляционной модели для этого ничего нет. Но ведь это все избитые истины. Они не оспариваются сторонниками реляционной модели. Потому и появилость понятие объектно-реляционной модели.
7 июн 04, 14:39    [726181]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Wadim
Member

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

vadiminfo

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


Соответсвует. Правда потрогать нельзя, если вы это имеете ввиду. :)
Этой таблице соответсвует факты (таблица фактов) того что оборудование находится в определенном помещении
7 июн 04, 15:01    [726265]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 10 11 12 13 14 [15] 16 17 18 19 .. 83   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить