Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 [2] 3   вперед  Ctrl      все
 Re: Постреляционные СУБД  [new]
Сергей Арсеньев
Member

Откуда:
Сообщений: 4118
vadiminfo
тогда как сетевая их должна, скорее всего, допускать.

С чего бы? Ведь сеть как известно в узких кругах сеть это связанный ориентированный граф без циклов.
30 май 13, 10:59    [14368626]     Ответить | Цитировать Сообщить модератору
 Re: Постреляционные СУБД  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
Сергей Арсеньев
С чего бы? Ведь сеть как известно в узких кругах сеть это связанный ориентированный граф без циклов.

Ну в узких, может быть.
Впрочем, все равно, одного нокукайкла для сетевой недостаточно. Там нужен, скорее всего, другой принци организации данных и система запросов. Первые какие-то там коллекции, а вторая типа навигацуионная. Тада как в Оракле ассоциативная.
30 май 13, 12:42    [14369479]     Ответить | Цитировать Сообщить модератору
 Re: Постреляционные СУБД  [new]
Сергей Арсеньев
Member

Откуда:
Сообщений: 4118
vadiminfo
Там нужен, скорее всего, другой принци организации данных и система запросов.

Термины "реляционная","иерархическая" и т.п. относятся к модели реального мира, а не к физической модели. Вопрос оптимального соответствия это вторичный вопрос.

Что касается современных СУБД по этому я и отношу их к классу гирбидных (сочетающих разные подходы, мегакомбайны и т.п.).

Просто Ваша фраза
vadiminfo
придут на смену реляционным

несколько устарела, они уже пришли, только этого никто не заметил. Примерно как смартфоны пришли на замену мобильным телефонам. Хорошо еще если не как с часами из Детей шпионов.
30 май 13, 13:08    [14369658]     Ответить | Цитировать Сообщить модератору
 Re: Постреляционные СУБД  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
Сергей Арсеньев
Термины "реляционная","иерархическая" и т.п. относятся к модели реального мира, а не к физической модели. Вопрос оптимального соответствия это вторичный вопрос.

Все таки в технологиях БД они относятся к логическим МД. Иерархические относятся к дореляционным: господствовали до появления реляционных. В настоящее время продолжается судя по всему эпоха реляционных. Попытки ее потеснить предпринимались и, возможно, иногда казалось вот вот потеснят. Но, видимо, пока что-то не срастается в этом плане.



Сергей Арсеньев
несколько устарела, они уже пришли, только этого никто не заметил. .

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

Да и фраза не моя: Кашина как минимум: "Постреляционная СУБД Каша". Мне чужих заслуг не надо.
30 май 13, 21:40    [14372712]     Ответить | Цитировать Сообщить модератору
 Re: Постреляционные СУБД  [new]
mad_nazgul
Member

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


Она настанет, когда под постреляционными БД будет математическая теория "мощностью" не менее, чем реляционная алгебра. :-)
31 май 13, 07:28    [14373359]     Ответить | Цитировать Сообщить модератору
 Re: Постреляционные СУБД  [new]
Сергей Арсеньев
Member

Откуда:
Сообщений: 4118
mad_nazgul
постреляционными БД будет математическая теория "мощностью" не менее, чем реляционная алгебра. :-)

Ну а если рассматривать под постреляционными то, что ими называется, то алгебра у них вообще не менее мощная - ибо та же самая. :)
Алгебре атомарность, как бы, фиолетова - функционал от функционала написать не сложно.
31 май 13, 09:14    [14373652]     Ответить | Цитировать Сообщить модератору
 Re: Постреляционные СУБД  [new]
Сергей Арсеньев
Member

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

Просто Вы считаете, по привычке, Oracle,Postgres,MsSql,DB2 реляционными. А это, как я уже писал выше, не совсем так.
31 май 13, 09:18    [14373669]     Ответить | Цитировать Сообщить модератору
 Re: Постреляционные СУБД  [new]
mad_nazgul
Member

Откуда:
Сообщений: 5824
Сергей Арсеньев
mad_nazgul
постреляционными БД будет математическая теория "мощностью" не менее, чем реляционная алгебра. :-)

Ну а если рассматривать под постреляционными то, что ими называется, то алгебра у них вообще не менее мощная - ибо та же самая. :)
Алгебре атомарность, как бы, фиолетова - функционал от функционала написать не сложно.


Ну как бы, только в функциональных ЯП используется теоретический потенциал алгебры.
В постреляционных я только вижу какие-то эмипирические "пожелания". <:o)
31 май 13, 12:07    [14374831]     Ответить | Цитировать Сообщить модератору
 Re: Постреляционные СУБД  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
Сергей Арсеньев
Просто Вы считаете, по привычке, Oracle,Postgres,MsSql,DB2 реляционными.

Местоимение Вы, наверное, следовало написать с маленькой буквы, поскольку получается что якобы только я так считаю. Что несколько не точно, поскольку как минимум Оракл так считает:
Вот в справке 11.2: The relational model is the basis for a relational database management system (RDBMS). ....Oracle Database is an RDBMS.


Сергей Арсеньев
А это, как я уже писал выше, не совсем так.

Ну Вы пытались отнести Оракл и к иерархическим и сетевым. И вообще свое понимание какое-то терминов:

Сергей Арсеньев
Термины "реляционная","иерархическая" и т.п. относятся к модели реального мира, а не к физической модели.


Это действительно не привычно.

В частности, идея о том что Оракл иерархическая БД или отнесение терминов к "модели реального мира" слишком выходит за рамки привычного в литературе по БД а , возможно, и рационального.
31 май 13, 18:31    [14377400]     Ответить | Цитировать Сообщить модератору
 Re: Постреляционные СУБД  [new]
AlexandrPlus
Member

Откуда:
Сообщений: 7887
Сергей Арсеньев
mad_nazgul
постреляционными БД будет математическая теория "мощностью" не менее, чем реляционная алгебра. :-)

Ну а если рассматривать под постреляционными то, что ими называется, то алгебра у них вообще не менее мощная - ибо та же самая. :)
Алгебре атомарность, как бы, фиолетова - функционал от функционала написать не сложно.


наверно термин "постреляционные" уместен, так как новых реляционных СУБД, которые имели бы
такое же прикладное значение, какое у популярных современных, уже наверно не будет

они будут существовать и будут развиваться, дополняясь, но их явно потеснят в областях деятельности, где применяются СУБД
13 июн 13, 22:11    [14430823]     Ответить | Цитировать Сообщить модератору
 Re: Постреляционные СУБД  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
AlexandrPlus
они будут существовать и будут развиваться, дополняясь, но их явно потеснят в областях деятельности, где применяются СУБД


И буквы вроде все знакомые, но тайная мысль, вложенная в предложение, непонятна... Последствия курения Neo4j?
13 июн 13, 22:43    [14430915]     Ответить | Цитировать Сообщить модератору
 Re: Постреляционные СУБД  [new]
AlexandrPlus
Member

Откуда:
Сообщений: 7887
pkarklin
AlexandrPlus
они будут существовать и будут развиваться, дополняясь, но их явно потеснят в областях деятельности, где применяются СУБД


И буквы вроде все знакомые, но тайная мысль, вложенная в предложение, непонятна... Последствия курения Neo4j?


Через сколько лет RDBMS начнут менять на новые?
Невероятно? То есть это всё - игрушки как Пролог, например.
Не будет никогда? Они не будут лучше никогда.
Будет, но частично. Как, например, проекты многие переписали с Delphi зачем, но многие не видят ни смысла, ни пользы переписывания с Delphi, а также еще и начинают проекты на Delphi, видя многие
явные плюсы, чего нет у других.
13 июн 13, 23:34    [14431084]     Ответить | Цитировать Сообщить модератору
 Re: Постреляционные СУБД  [new]
mad_nazgul
Member

Откуда:
Сообщений: 5824
AlexandrPlus
Через сколько лет RDBMS начнут менять на новые?
Невероятно? То есть это всё - игрушки как Пролог, например.
Не будет никогда? Они не будут лучше никогда.
Будет, но частично. Как, например, проекты многие переписали с Delphi зачем, но многие не видят ни смысла, ни пользы переписывания с Delphi, а также еще и начинают проекты на Delphi, видя многие
явные плюсы, чего нет у других.


Delhpi - это продукт одной конторы, поэтому это не показатель.
RDBMS, в частности SQL - это стандарт.
Такой же как например HTML.
Вспомните какой был HTML 1.0 и что сейчас есть в HTML 5.
Стандарт SQL не стоит на месте, он развивается.
Кроме того, каждый производитель SQL-сервера дополняет своими "фичами", которые могут повторять некоторые "фичи" NoSQL.

NoSQL, же это yе стандарт, т.е. каждый производитель делает свое ни совместимое ни с чем.
Т.е. любая NoSQL больше похожа на Delphi, т.е. вероятность смерти выше, чем у SQL.
14 июн 13, 07:05    [14431577]     Ответить | Цитировать Сообщить модератору
 Re: Постреляционные СУБД  [new]
AlexandrPlus
Member

Откуда:
Сообщений: 7887
mad_nazgul
AlexandrPlus
Через сколько лет RDBMS начнут менять на новые?
Невероятно? То есть это всё - игрушки как Пролог, например.
Не будет никогда? Они не будут лучше никогда.
Будет, но частично. Как, например, проекты многие переписали с Delphi зачем, но многие не видят ни смысла, ни пользы переписывания с Delphi, а также еще и начинают проекты на Delphi, видя многие
явные плюсы, чего нет у других.


Delhpi - это продукт одной конторы, поэтому это не показатель.
RDBMS, в частности SQL - это стандарт.
Такой же как например HTML.
Вспомните какой был HTML 1.0 и что сейчас есть в HTML 5.
Стандарт SQL не стоит на месте, он развивается.
Кроме того, каждый производитель SQL-сервера дополняет своими "фичами", которые могут повторять некоторые "фичи" NoSQL.

NoSQL, же это yе стандарт, т.е. каждый производитель делает свое ни совместимое ни с чем.
Т.е. любая NoSQL больше похожа на Delphi, т.е. вероятность смерти выше, чем у SQL.


замечу про Delphi - это таки более IDE (исходно было) для языка Pascal (далее Object Pascal, а далее
почему-то решили именем IDE назвать как бы новый язык, но кроме примочек и прибамбасов к Object Pascal ничего не было - то есть это новые версии Object Pascal (Это как бывшие институты вдруг решили
называться университетами)), а компиляторов Pascal много разных на разных платформах и IDE были.
Вот сейчас набирает обороты FreePascal с IDE Lazarus. То есть у Object Pascal еще одна IDE.

И SQL - не модель данных, а язык запросов.
К многим неRDBMS (то есть noSQL - не очень удачно названо, но SQL - более звучно и поэтому прижилось) реализован как язык запросов в качестве дополнения к своему как бы нативному (первому) и SQL (может быть не совсем полный по стандарту). Вроде как реализация SQL на других платформах.
14 июн 13, 08:15    [14431643]     Ответить | Цитировать Сообщить модератору
 Re: Постреляционные СУБД  [new]
mad_nazgul
Member

Откуда:
Сообщений: 5824
AlexandrPlus
замечу про Delphi - это таки более IDE (исходно было) для языка Pascal (далее Object Pascal, а далее
почему-то решили именем IDE назвать как бы новый язык, но кроме примочек и прибамбасов к Object Pascal ничего не было - то есть это новые версии Object Pascal

Delphi имеет отношение к Pascal точно так же как JavaScript к Java. :-)
Уже Turbo Pascal с Pascal'ем было много расхождений.
По поводу Delphi читайте дедушку Виннера.
Он был очень не доволен, что сделали с его Pascal'ем Borland.

AlexandrPlus
(Это как бывшие институты вдруг решили
называться университетами)), а компиляторов Pascal много разных на разных платформах и IDE были.


Это было давно и не правда ;-)
Это если не вспоминать 8-битные компьютеры.
На PC - был только один коммерческий компилятор - Turbo Pascal.
Который плавно перерос в Delphi.
И это был не IDE а ЯП, т.к. имел столько "нововведений", что даже совместимости снизу вверх почти не было.

AlexandrPlus
Вот сейчас набирает обороты FreePascal с IDE Lazarus. То есть у Object Pascal еще одна IDE.


Проект FreePascal и Lazarus изначально был на направлен на ПОЛНОЕ копирование Turbo Pascal и Delphi.
Кстати в том же FreePascal есть "настройки компиляции" - ObjectPascal и Delphi.
Т.е. они их различают ;-)


AlexandrPlus
И SQL - не модель данных, а язык запросов.


Модель данных - RMD.
SQL - ЯП построенный на модели RMD.

AlexandrPlus
К многим неRDBMS (то есть noSQL - не очень удачно названо, но SQL - более звучно и поэтому прижилось) реализован как язык запросов в качестве дополнения к своему как бы нативному (первому) и SQL (может быть не совсем полный по стандарту). Вроде как реализация SQL на других платформах.


Возьмем для примера PostgreSQL который поддерживает стандарт SQL99 (и часть "фишек" из более поздних стандартов).
Так вот PostgreSQL на любой платформе поддерживает стандарт SQL99 - полностью. Хоть на мейнфрейме, хоть на ADSL-роутере.

С остальными SQL-серверами та же самая история. Любой из них поддерживает определенную версию SQL.

А вот если взять FoxPro, то он не является SQL.
Хотя и поддерживает некоторые элементы SQL.
14 июн 13, 09:32    [14432019]     Ответить | Цитировать Сообщить модератору
 Re: Постреляционные СУБД  [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
mad_nazgul
По поводу Delphi читайте дедушку Виннера.
Вирта может?
14 июн 13, 09:59    [14432133]     Ответить | Цитировать Сообщить модератору
 Re: Постреляционные СУБД  [new]
AlexandrPlus
Member

Откуда:
Сообщений: 7887
не буду оффтопить про Pascal

mad_nazgul
AlexandrPlus
И SQL - не модель данных, а язык запросов.


Модель данных - RMD.
SQL - ЯП построенный на модели RMD.


все же тогда наверно в IBM просто хотели создать удобный язык запросов к своей реляционной СУБД DB2 (
первые названия - System R, ...)
14 июн 13, 10:32    [14432292]     Ответить | Цитировать Сообщить модератору
 Re: Постреляционные СУБД  [new]
mad_nazgul
Member

Откуда:
Сообщений: 5824
SergSuper
mad_nazgul
По поводу Delphi читайте дедушку Виннера.
Вирта может?


Да. Прошу прощения.
14 июн 13, 13:03    [14433305]     Ответить | Цитировать Сообщить модератору
 Re: Постреляционные СУБД  [new]
mad_nazgul
Member

Откуда:
Сообщений: 5824
AlexandrPlus
все же тогда наверно в IBM просто хотели создать удобный язык запросов к своей реляционной СУБД DB2 (
первые названия - System R, ...)


Почти.
В основе ЯП SQL лежит реляционная алгебра.
Это очень мощная "модель". Соответственно SQL и получился с одной стороны простым, с другой стороны гибким.
Альтернатив до сих пор я не вижу.
Например xBase то же был ЯП для реляционных БД.
Но сравнивать xBase и SQL, как-то лестно для xBase ;-)
14 июн 13, 13:07    [14433328]     Ответить | Цитировать Сообщить модератору
 Re: Постреляционные СУБД  [new]
Адмiнiстратор
Member [заблокирован]

Откуда: Pikosec.Com
Сообщений: 49
Слабо на простом языке решить такую задачу ? 14429118
14 июн 13, 13:54    [14433670]     Ответить | Цитировать Сообщить модератору
 Re: Постреляционные СУБД  [new]
mad_nazgul
Member

Откуда:
Сообщений: 5824
Адмiнiстратор
Слабо на простом языке решить такую задачу ? 14429118


Хорошая задачка...
Была на лабораторной по Prolog'у :-)
По идее ее так же не сложно решить на Lisp'е (но точно не знаю, т.к. Lisp не рассматривал никак)

На SQL тоже можно, но чуть сложнее - через рекурсивный запрос, т.к. нужно строить "путь" до конца/цикла, а потом искать пути соответствующей размерности.
14 июн 13, 15:56    [14434527]     Ответить | Цитировать Сообщить модератору
 Re: Постреляционные СУБД  [new]
AlexandrPlus
Member

Откуда:
Сообщений: 7887
mad_nazgul
AlexandrPlus
все же тогда наверно в IBM просто хотели создать удобный язык запросов к своей реляционной СУБД DB2 (
первые названия - System R, ...)


Почти.
В основе ЯП SQL лежит реляционная алгебра.
Это очень мощная "модель". Соответственно SQL и получился с одной стороны простым, с другой стороны гибким.
Альтернатив до сих пор я не вижу.
Например xBase то же был ЯП для реляционных БД.
Но сравнивать xBase и SQL, как-то лестно для xBase ;-)


Вот это, имхо, исторически спорный вопрос.
Сперва у СУБД был язык на основе, так называемых, исчисления кортежей.
И потом они его совершенствовали. Насколько им помогли теоретические
наработки в реляционной алгебре Кодда и Ко - неизвестно. Но потом они стали единым.
То есть вопрос типа - что раньше было: курица или яйцо.Картинка с другого сайта.
14 июн 13, 16:12    [14434597]     Ответить | Цитировать Сообщить модератору
 Re: Постреляционные СУБД  [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
mad_nazgul
Адмiнiстратор
Слабо на простом языке решить такую задачу ? 14429118


Хорошая задачка...
Была на лабораторной по Prolog'у :-)
По идее ее так же не сложно решить на Lisp'е (но точно не знаю, т.к. Lisp не рассматривал никак)

На SQL тоже можно, но чуть сложнее - через рекурсивный запрос, т.к. нужно строить "путь" до конца/цикла, а потом искать пути соответствующей размерности.
Вы учитываете что тип родственных связей тоже надо как-то хранить и настраивать? я лично не представляю как тогда такую задачу решать
14 июн 13, 16:13    [14434602]     Ответить | Цитировать Сообщить модератору
 Re: Постреляционные СУБД  [new]
Адмiнiстратор
Member [заблокирован]

Откуда: Pikosec.Com
Сообщений: 49
Надо будет когдато написать большой пост о недостатках SQL его кривости и невразумительности.
Начал бы я с того, что такие базы непомерно раздуты. 50% в базе это айдишники, служебные данные базы.
Много служебных таблиц, исторических, хранящих изменения и тд.
Потом благодаря РМД данные не лежат централизовано, они разнесены по разным таблицам, что усложняет к ним доступ.
Приходится писать мегаджоины которые мегамедленно выполняются.

Традиционный SQL имеет ряд костылей, некоторые из них:
СТЕ - костыль для реализации иерархий в СУБД
FTS - костыль для полнотекстового поиска
EAV - костыль для организации гибкой структуры базы

и тд.
14 июн 13, 16:26    [14434675]     Ответить | Цитировать Сообщить модератору
 Re: Постреляционные СУБД  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
Адмiнiстратор
Надо будет когдато написать большой пост о недостатках SQL его кривости и невразумительности.
Начал бы я с того, что такие базы непомерно раздуты. 50% в базе это айдишники, служебные данные базы.
Много служебных таблиц, исторических, хранящих изменения и тд.
Потом благодаря РМД данные не лежат централизовано, они разнесены по разным таблицам, что усложняет к ним доступ.
Приходится писать мегаджоины которые мегамедленно выполняются.

Традиционный SQL имеет ряд костылей, некоторые из них:
СТЕ - костыль для реализации иерархий в СУБД
FTS - костыль для полнотекстового поиска
EAV - костыль для организации гибкой структуры базы

и тд.

Начало не очень удалось, скорее всего. Возможно, только про соединения что-то можно оставить, и то переделав как-то текст.
Впрочем, недостатки давно описаны в литературе.
Но, видимо, есть достоинства. Которые делают их во многих случаях наиболее успешными по сравнению с другими. Иначе бы, наверное, реляционная эпоха давно закончилась.
14 июн 13, 18:26    [14435179]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 [2] 3   вперед  Ctrl      все
Все форумы / Сравнение СУБД Ответить