Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 16 17 18 19 20 [21] 22 23 24 25 .. 27   вперед  Ctrl
 Re: недостатки иерархических баз  [new]
Зл0й
Member

Откуда: Северная Калифорния
Сообщений: 686
MX -- ALEX


Процедуры поиска в Императивных пишем один раз !
и навсегда


Ага, а теперь представьте что таких задач у вас не одна.

Вот я только что запустил скрипт посчитавший количество различных селектов в одном релизе относительно небольшого приложения. Их было 596. Количество апдэйтов и инсертов я не считал ибо лень. Селект пишется и отлаживается гораздо быстрее чем процедура с циклами. Поэтому программеров на PL/SQL учат так: если можно решить задачу одним SQL запросом, ее нужно решать одним запросом.

Про то что "пишется один раз" вы рассажите кому-то кто никогда на Коболе и Клиппере с Фоксом не писал. Заодно расскажите как ваша процедура будет обрабатывать конкурентный доступ к данным когда данные которые вы читаете одновременно кто-то может пытаться изменить.
25 июл 08, 21:49    [5988596]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
Бред
Guest
Зл0й
MX -- ALEX


Процедуры поиска в Императивных пишем один раз !
и навсегда


Ага, а теперь представьте что таких задач у вас не одна.

Вот я только что запустил скрипт посчитавший количество различных селектов в одном релизе относительно небольшого приложения. Их было 596. Количество апдэйтов и инсертов я не считал ибо лень. Селект пишется и отлаживается гораздо быстрее чем процедура с циклами. Поэтому программеров на PL/SQL учат так: если можно решить задачу одним SQL запросом, ее нужно решать одним запросом.

Про то что "пишется один раз" вы рассажите кому-то кто никогда на Коболе и Клиппере с Фоксом не писал. Заодно расскажите как ваша процедура будет обрабатывать конкурентный доступ к данным когда данные которые вы читаете одновременно кто-то может пытаться изменить.

Ага, не одна. Миллионы): Именно поэтому и пишем один раз - мы же не сумасшедшие): Очень хорошо, что "посчитали селекты в релизе". Еще бы не мешало посмотреть на них повнимательнее - может дойдет. Нет, все-таки правильно я Вам посоветовал писать еще и оптимизатор для каждого приложения. И обязательно разрабатывать, для начала, специальный диалект PL/SQL):
25 июл 08, 21:57    [5988614]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
Зл0й
Member

Откуда: Северная Калифорния
Сообщений: 686
Бред

Ну что же Вы опять отвлеклись от веса Сидорова в килограммах?):

Для протстых задач все уже встроенно в СУБД оракл:
Comment on column my_schema.my_table 'incarcerated persons';

Comment on column my_schema.my_table.my_column 'weight in kilograms';
Вся эта информация доступна через клиент-серверный и веб-интерфейс. Если требуется что-то посложнее, то поверх РСУБД ставится система для управления метаданными. Чем сложнее задача - тем более навороченная система ставится. Благо есть большой выбор.

Бред

Рыдайте на здоровье, тем не менее оптимизация действительно давно обсуждалась, и никаких других выводов и быть не могло):

ссылку в студию.

Бред

А Вы не теряйтесь в догадках, а ответьте хотя бы на один конкретный вопрос, причем для этого ответа не нужны никакие "ссылочки", а нужно лишь набраться мужества):

ссылку в студию.

Бред

Плохо, что Вам ничего не понятно про ОСУБД и ООСУБД (на основе ООП). При чем здесь mumps. Эта среда не поддерживает никакой модели данных, и предназначена для создания СУБД - стыдно этого не знать):

Перефразируя вас: Ассемблер - это язык не предназначенный для написания программ, а язык предназначенный для того чтобы в него транслировать программы написанные на языке высокого уровня. Сами-то поняли что написали?

Бред

У меня никогда не было и нет никакой конторы):
Все формально и строго. Мне надоело "давать ссылочку", тем более, что примеры все перед Вами. Не отвлекайтесь, пожалуйста. Если нужно, уточните сколько я Вам должен заплатить, чтобы Вы не дурачились):

Вам не надоело, а вы ее не даете, потому что ее нет и быть не может. См. стр 603-613 "OLAP Solutions" Eric Thomsen, 2е издание. Предупреждаю сразу, что для того чтобы понять эти 10 страниц нужно понимать что такое каноническая логика, исчисление предикатов 1го и 2го порядков и теория множеств.

Бред

Будет Вам про все, и про оптимизаторы (у несчастных "сломавшихся" разработчиков IDMS не было среды разработки СУБД, так же, как и у несчастных разработчиков "Р"СУБД), и про навигаторы, и про "конкурентные транзакции".

где будет и когда?

Бред

Заканчивайте с этим детским лепетом - Вы же серьезный человек - ввязались в разговор о семантике данных, так давайте уж - разговаривайте):

Начнем с определений? Мы уже поднимали вопрос о семантике, я помнится даже приводил определение. После чего был сделан вывод что семантика-таки в РСУБД есть. Схема отношения это логическая формула, которая истина для всех кортежей (tuples). Что позволяет нам гарантировать непротиворечивость данных.

Бред

Не отвлекайтесь, пожалуйста, от нашего с Вами разговора о системах восстановления навигации и смысла данных, утраченных в РБД.

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

Бред

Пожалуйста, расскажите на рассмотренных примерах о нескольких связях между двумя объектами и просто о Весе, кг): Чего Вы стесняетесь-то - Вы же не виноваты в этих кошмарных "современных" архитектурах. Правильно?

Реляционная модель не оперирует объектами и связями между ними. Ставьте и формализуйте задачу на естественном (русском, английском, французском или арабском - выбор за вами) языке, мы вам предложим реляционное ее решение. Причем я берусь гарантировать что решение любой нетривиальной задачи по автоматизации предприятия сделанное на базе Oracle + ERP софт + Microstrategy будет разработано быстрее, в эксплуатации дешевле, поддерживается проще, масштабируется на два порядке лучше чем сделанный на коленке самопал поверх каши.

Мне некогда заниматься изобретением велосипедов, мне надо деньги зарабатывать.
25 июл 08, 23:58    [5988912]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
Зл0й
Member

Откуда: Северная Калифорния
Сообщений: 686
Бред

Ага, не одна. Миллионы): Именно поэтому и пишем один раз - мы же не сумасшедшие): Очень хорошо, что "посчитали селекты в релизе". Еще бы не мешало посмотреть на них повнимательнее - может дойдет.

Данные в селектах разные, из разных источников. Вы планируете все данные свалить в одну кучу и написать некоторое количество процедур для работы с данными "на все случаи жизни". Видел я такое решение, называется AFS система для учета банковских кредитов, используется в нескольких крупных американских банках. Все данные пишутся вложенными записями сложной структуры в 4 файла. Написано в 70х годах прошлого века, поэтому так и сделано. Когда Wells Fargo сливался с Norwest (один использовал Shaw в другой AFS, остановились на AFS) то номера кредитных счетов расширили с 9 символов до 15. На это проект ушел год. Вот цена вашего нереляционного решения - его невозможно поддерживать.

Бред

Нет, все-таки правильно я Вам посоветовал писать еще и оптимизатор для каждого приложения. И обязательно разрабатывать, для начала, специальный диалект PL/SQL):

Как раз оптимизатор для каждого приложения пишется в случае императивного подхода. Причем execution plan жестко зашивается в процедурную логику которую потом кому-то надо поддерживать. Любому мало-мальски грамотному программисту понятно что с таким подходом можно стоить только совсем несложные системы.

Как конкурентные транзакции будем поддерживать?
26 июл 08, 00:19    [5988948]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
Выбегалло
Member

Откуда: Scottsdale, AZ, USA
Сообщений: 3823
Мужики, вы все еще с коллегой ЧАЛом паритесь ? Ему не вы нужны, а квалифицированная помощь.
28 июл 08, 07:25    [5991325]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
MX -- ALEX
Guest
Зл0й
MX -- ALEX


Процедуры поиска в Императивных пишем один раз !
и навсегда


Ага, а теперь представьте что таких задач у вас не одна.

Вот я только что запустил скрипт посчитавший количество различных селектов в одном релизе относительно небольшого приложения. Их было 596. Количество апдэйтов и инсертов я не считал ибо лень. Селект пишется и отлаживается гораздо быстрее чем процедура с циклами. Поэтому программеров на PL/SQL учат так: если можно решить задачу одним SQL запросом, ее нужно решать одним запросом.

Про то что "пишется один раз" вы рассажите кому-то кто никогда на Коболе и Клиппере с Фоксом не писал. Заодно расскажите как ваша процедура будет обрабатывать конкурентный доступ к данным когда данные которые вы читаете одновременно кто-то может пытаться изменить.


Мне повезло
у меня одна задача
ПОИСК

Про Кобол Клиппер Фокс не слыхивали.

Чему учат программеров на PL/SQL - интересно конечно ,
но у нас иной подход -
если задачу легко решить без SQL - ее надо решать без SQL
Пока других не встречалось.
28 июл 08, 09:11    [5991464]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
Bogdanov Andrey
Member

Откуда: Да уже и сам не знаю...
Сообщений: 2203
MX -- ALEX

если задачу легко решить без SQL - ее надо решать без SQL

А SQL у вас который?
28 июл 08, 10:25    [5991765]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
MX -- ALEX
Guest
Bogdanov Andrey
MX -- ALEX

если задачу легко решить без SQL - ее надо решать без SQL

А SQL у вас который?


нулёвый
28 июл 08, 14:41    [5993419]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
servit
Member

Откуда: г. Кишинёв, Республика Молдова
Сообщений: 3148
Блог
MX -- ALEX
Bogdanov Andrey
MX -- ALEX

если задачу легко решить без SQL - ее надо решать без SQL

А SQL у вас который?


нулёвый

От себя добавлю:
SQL-92 Compliance
Feature Map
28 июл 08, 15:22    [5993712]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
ModelR
Member

Откуда: Нижний Новгород
Сообщений: 1798
Бред
большинство действий в типичных OLTP-системах сводятся к выполнению операций над экземпляром объекта или над множеством экземпляров объекта B, связанных с экземпляро объекта A. Здесь от SQL никакой пользы.
Да, процедурный код можно сделать более эффективным, но ценой бОльших усилий программистов. Что нынче почем - Вы и сами знаете.
Да, связи, которые заранее заложены в архитектуру данной базы, будут обработаны эффективней связей вычисляемых, но без вычисляемых реально жизни также нет.
По теме я бы сказал, что иерархические системы могут сохранять какую-то нишу, где они эффективней. Не хочу фантазировать, наверно кто-то сможет привести реальные примеры из практики.
29 июл 08, 10:42    [5996993]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
_мод
Guest
ModelR
Да, связи, которые заранее заложены в архитектуру данной базы, будут обработаны эффективней связей вычисляемых, но без вычисляемых реально жизни также нет.

А одно другому не мешает и не противопоставляется.
29 июл 08, 12:16    [5997782]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
Bogdanov Andrey
Member

Откуда: Да уже и сам не знаю...
Сообщений: 2203
servit
MX -- ALEX
Bogdanov Andrey
MX -- ALEX

если задачу легко решить без SQL - ее надо решать без SQL

А SQL у вас который?


нулёвый

От себя добавлю:
SQL-92 Compliance
Feature Map
У вас "неправильный" SQL. :)
На этом SQL действительно решать задачи хуже, чем без него.
29 июл 08, 12:38    [5997998]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
Бред
Guest
Зл0й
Бред

Ну что же Вы опять отвлеклись от веса Сидорова в килограммах?):

Для протстых задач все уже встроенно в СУБД оракл:
Comment on column my_schema.my_table 'incarcerated persons';

Comment on column my_schema.my_table.my_column 'weight in kilograms';
Вся эта информация доступна через клиент-серверный и веб-интерфейс. Если требуется что-то посложнее, то поверх РСУБД ставится система для управления метаданными. Чем сложнее задача - тем более навороченная система ставится. Благо есть большой выбор.

Бред

Рыдайте на здоровье, тем не менее оптимизация действительно давно обсуждалась, и никаких других выводов и быть не могло):

ссылку в студию.

Бред

А Вы не теряйтесь в догадках, а ответьте хотя бы на один конкретный вопрос, причем для этого ответа не нужны никакие "ссылочки", а нужно лишь набраться мужества):

ссылку в студию.

Бред

Плохо, что Вам ничего не понятно про ОСУБД и ООСУБД (на основе ООП). При чем здесь mumps. Эта среда не поддерживает никакой модели данных, и предназначена для создания СУБД - стыдно этого не знать):

Перефразируя вас: Ассемблер - это язык не предназначенный для написания программ, а язык предназначенный для того чтобы в него транслировать программы написанные на языке высокого уровня. Сами-то поняли что написали?

Бред

У меня никогда не было и нет никакой конторы):
Все формально и строго. Мне надоело "давать ссылочку", тем более, что примеры все перед Вами. Не отвлекайтесь, пожалуйста. Если нужно, уточните сколько я Вам должен заплатить, чтобы Вы не дурачились):

Вам не надоело, а вы ее не даете, потому что ее нет и быть не может. См. стр 603-613 "OLAP Solutions" Eric Thomsen, 2е издание. Предупреждаю сразу, что для того чтобы понять эти 10 страниц нужно понимать что такое каноническая логика, исчисление предикатов 1го и 2го порядков и теория множеств.

Бред

Будет Вам про все, и про оптимизаторы (у несчастных "сломавшихся" разработчиков IDMS не было среды разработки СУБД, так же, как и у несчастных разработчиков "Р"СУБД), и про навигаторы, и про "конкурентные транзакции".

где будет и когда?

Бред

Заканчивайте с этим детским лепетом - Вы же серьезный человек - ввязались в разговор о семантике данных, так давайте уж - разговаривайте):

Начнем с определений? Мы уже поднимали вопрос о семантике, я помнится даже приводил определение. После чего был сделан вывод что семантика-таки в РСУБД есть. Схема отношения это логическая формула, которая истина для всех кортежей (tuples). Что позволяет нам гарантировать непротиворечивость данных.

Бред

Не отвлекайтесь, пожалуйста, от нашего с Вами разговора о системах восстановления навигации и смысла данных, утраченных в РБД.

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

Бред

Пожалуйста, расскажите на рассмотренных примерах о нескольких связях между двумя объектами и просто о Весе, кг): Чего Вы стесняетесь-то - Вы же не виноваты в этих кошмарных "современных" архитектурах. Правильно?

Реляционная модель не оперирует объектами и связями между ними. Ставьте и формализуйте задачу на естественном (русском, английском, французском или арабском - выбор за вами) языке, мы вам предложим реляционное ее решение. Причем я берусь гарантировать что решение любой нетривиальной задачи по автоматизации предприятия сделанное на базе Oracle + ERP софт + Microstrategy будет разработано быстрее, в эксплуатации дешевле, поддерживается проще, масштабируется на два порядке лучше чем сделанный на коленке самопал поверх каши.

Мне некогда заниматься изобретением велосипедов, мне надо деньги зарабатывать.


1. Вот видите, при первой же попытке рассмотреть конкретный пример, Вы с задачей не справились. Что "все уже встроено"????? Зря Вы не обратили внимание на мое примечание об MS SQL (про Name и Description), я уж не говорю про то, как это описывается в ОСУБД. Не могу поверить, что вы не понимаете о чем речь. Значит один вывод - "ваши современные архитектуры" глубоко ущербны): Постарайтесь, все-таки, еще раз рассмотреть этот простейший пример, и показать как же можно обойтись без систем восстановления навигации и семантики данных.
Дальше читать после этого фундаментального прокола с примером совсем неинтересно, но я читаю):
2. Если будет время (так как это не имеет отношения к семантике данных) я, заметьте бесплатно, постараюсь найти эти старые обсуждения, раз Вы этого делать не хотите): Кроме того, я никогда не возражал против возобновления обсуждения по любому вопросу БД):
3. Второй раз про "ссылки в студию" - это уже нервишки): Ведь в самом начале Вы уже попробовали ответить хотя бы на один конкретный вопрос. Пока не получилось, но может еще получиться?):
4. Она есть, и этим банальным знаниям уже не менее тридцати лет): Не переживайте за "каноническую логику, исчисление предикатов 1го и 2го порядков и теорию множеств". Мои знания в этих областях, как минимум, не уступают Вашим. На указанных Вами страницах нет ничего, что помогло бы Вам ответить хотя бы на один конкретный вопрос, который мы здесь обсуждаем):
5. Везде и всегда):
6. Отлично! Как же я рад что в "Р"СУБД все так хорошо с семантикой. Вот и давайте - возвращайтесь к примеру, и пробуйте. Именно средствами СУБД.
7. Это точно - заканчивайте с пустым трепом. Будьте любезны про смысл на простом примере (который, заодно, показывает отсутствие идентификации в РСУБД и на уровне метаданных, а не только на уровне данных). Про навигацию есть, например, "РМД пора на пенсию" (хотя я так не считаю):) - вот там и поупражняйтесь. Лабораторку с шариками проделайте и т.д.
8. Блеск! Я Вам поставил простейшую задачу именно на русском языке, и жду от Вас "реляционного решения" для пользователя, конечно же, для русского):
Причем я берусь гарантировать что решение любой нетривиальной задачи по автоматизации предприятия сделанное на базе Oracle + ERP софт + Microstrategy будет разработано медленнее, в эксплуатации дороже, поддерживается сложнее, масштабируется на два порядке хуже чем при использовании ОСУБД.
29 июл 08, 19:54    [6001507]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
Бред
Guest
Зл0й
Бред

Ага, не одна. Миллионы): Именно поэтому и пишем один раз - мы же не сумасшедшие): Очень хорошо, что "посчитали селекты в релизе". Еще бы не мешало посмотреть на них повнимательнее - может дойдет.

Данные в селектах разные, из разных источников. Вы планируете все данные свалить в одну кучу и написать некоторое количество процедур для работы с данными "на все случаи жизни". Видел я такое решение, называется AFS система для учета банковских кредитов, используется в нескольких крупных американских банках. Все данные пишутся вложенными записями сложной структуры в 4 файла. Написано в 70х годах прошлого века, поэтому так и сделано. Когда Wells Fargo сливался с Norwest (один использовал Shaw в другой AFS, остановились на AFS) то номера кредитных счетов расширили с 9 символов до 15. На это проект ушел год. Вот цена вашего нереляционного решения - его невозможно поддерживать.

Бред

Нет, все-таки правильно я Вам посоветовал писать еще и оптимизатор для каждого приложения. И обязательно разрабатывать, для начала, специальный диалект PL/SQL):

Как раз оптимизатор для каждого приложения пишется в случае императивного подхода. Причем execution plan жестко зашивается в процедурную логику которую потом кому-то надо поддерживать. Любому мало-мальски грамотному программисту понятно что с таким подходом можно стоить только совсем несложные системы.

Как конкурентные транзакции будем поддерживать?

Опять уходите в другую тему. Теперь данные из разных источников): О чем-то о наболевшем? Зачем Вы нам рассказывате про AFS??? Это сделано в ОСУБД что ли??? Опять о любимых 70-х? Не смешите людей, цена поддержки "реляционных решений" всегда дороже):
Не уходите от вопроса. Оптимизатор входит в состав СУБД и никогда не пишется для приложения. Однако восстанавлением смысла и навигации данных Вы занимаетесь каждый раз при написании даже самого простого приложения. Вот я Вас и спрашиваю: почему бы не быть последовательным в желании программировать, и почему бы не программировать и оптимизаторы под каждое приложение?): Вместо того, что бы ответить, опять что-то про "зашивание в процедурную логику"):
29 июл 08, 20:02    [6001525]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
Бред
Guest
Выбегалло
Мужики, вы все еще с коллегой ЧАЛом паритесь ? Ему не вы нужны, а квалифицированная помощь.

Молоток! Изучает-таки, теорию БД): А раньше думал, что уже изучил):
29 июл 08, 20:05    [6001533]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
Бред
Guest
ModelR
Бред
большинство действий в типичных OLTP-системах сводятся к выполнению операций над экземпляром объекта или над множеством экземпляров объекта B, связанных с экземпляро объекта A. Здесь от SQL никакой пользы.
Да, процедурный код можно сделать более эффективным, но ценой бОльших усилий программистов. Что нынче почем - Вы и сами знаете.
Да, связи, которые заранее заложены в архитектуру данной базы, будут обработаны эффективней связей вычисляемых, но без вычисляемых реально жизни также нет.
По теме я бы сказал, что иерархические системы могут сохранять какую-то нишу, где они эффективней. Не хочу фантазировать, наверно кто-то сможет привести реальные примеры из практики.

Конечно, знаю. И в приведенных мной примерах "процедурный код" потребует заведомо мЕньших усилий по сравнению с "процедурно-декларативным".
Под "вычисляемыми" Вы, насколько я понимаю, подразумеваете "связи по общим полям" (а не "по ключам") в "реляционном" случае. Этот вопрос так же много раз обсуждался. Без примеров не обойтись. Единственным реальным кандитатом на такую связь является "дата". С одной стороны, оброты Земли вокруг оси можно (и очень полезно) рассматривать как экземпляры объекта. И тогда все связано): С другой стороны, в объектном навигаторе можно получать отчеты, связывая объекты по "общим полям"):
29 июл 08, 20:17    [6001565]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
Зл0й
Member

Откуда: Северная Калифорния
Сообщений: 686
MX -- ALEX

Мне повезло
у меня одна задача
ПОИСК

А причем здесь сравнение СУБД тогда? Если нет конкурентного доступа к нанным (напр. читатели-писатели) все делается "на ура" без СУБД вообще. Эта задача была решена лет этак много тому назад, еще на ЕС ЭВМ с помощью ISAM, VSAM. Сейчас есть более современные прибамбасы как например Lucene. Если у вас объем данных не пол-петабайта, то я вообще не понимаю зачем тут что-то писать, все уже написано много лет тому назад.

Я бы мог вам рассказать как в google эта проблема решается, но воздержусь т.к. подписывал в свое время NDA (бумажка такая, о неразглашении). В любом случае к базам данных эта задача (только ПОИСК) имеет в лучшем случае косвенное отношение.
30 июл 08, 05:18    [6002179]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
Зл0й
Member

Откуда: Северная Калифорния
Сообщений: 686
Бред

Опять уходите в другую тему. Теперь данные из разных источников): О чем-то о наболевшем? Зачем Вы нам рассказывате про AFS??? Это сделано в ОСУБД что ли???

Если абстрагироваться от деталей реализации, то с точки зрения модели данных MUMPS принципиально мало чем отличается от AFS.

Бред

Опять о любимых 70-х?

Употребляемый вами термин "навигация" придумал лауреат премии Тьюринга 1973 года Чарльз Уильям Бахман. В 70х были реализованы "навигационные" СУБД в частности IDMS одним из основных разработчиков и идеологов являлся Чарльз Бахман.

Бред

Не смешите людей, цена поддержки "реляционных решений" всегда дороже):

Цифры в студию, кто сравнивал, что сравнивал, с чем сравнивал и самое главное - как сравнивал. 85% рынка СУБД это СУБД реляционные, а остальные 15% - это legacy системы разработанные в 70х годах прошлого века.

Бред

Оптимизатор входит в состав СУБД и никогда не пишется для приложения.

не возражаю.

Бред

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

Восстановлением смысла мы не занимемся, потому что в этом нет никакой необходимости. Он никуда не "терялся" соответсвенно его не нужно "восстанавливать". Помнится я вам приводил определение термина "семантика" которым вы воспользовались пару лет тому назад. После чего мы пришли к выводу что она в Реляционных СУБД есть. Теперь вы прячетесь за расплывчатым и неопределенным словом "смысл".

Я от вас давно не могу дождаться формального определения "навигации". Отсутствие формального определения с вашей стороны на мой взгляд означает что вы затрудняетесь его дать, так как сами до конца не понимаете смысл употребляемого вами термина. В отличие от вас Чарльз Бахман смысл этого термина понимал. Но вы судя по всему его работ не читали.


Бред

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

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

Ближе всех к решению задачи "реализовать оптимизатор запросов и язык высокого уровня для нереляционной СУБД" подошли разработчики IDMS. Задача эта существенно сложнее чем разработка оптимизатора для реляционной СУБД. Ежу понятно почему, в принципе. Вы утверждаете обратное - потрудитесь аргументировать свою точку зрения.

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

Вы беретесь гарантировать непротиворечивость данных в "ОСУБД"? Докажите.

Последний "гвоздь" в гроб нереляционных СУБД заколотили разработки работы в области поддержки конкурентных транзакций. Для реляционных СУБД существуют алгоритмы обработки конкурентных транзакций (например читатели-писатели) корректность которых математически доказуема. Желающих убедиться отсылаю к классической книге Джима Грея.

Нереляционных СУБД в лучшем случае поддерживают весьма ущербную по сравнению с реляционными обработку транзакций. Поэтому ее обычно выносят в отдельный продукт такой как например CICS. Поскольку этот продукт не является СУБД, то о гранулярности блокировки типа записи или страницы можете забыть. При всех прочих равных масштабируемость реляционной системы всегда выше чем это безобразие. Оно используется до сих пор только потому, что переписывать системы разработанные 30 лет назад неоправданно дорого. Дешевле их поддерживать.

Вы беретесь продемонстрировать алгоритм обработки конкурентных транзакций в ОСУБД и доказать его корректность?
30 июл 08, 06:16    [6002188]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
MX -- ALEX
Guest
Зл0й
Нереляционных СУБД в лучшем случае поддерживают весьма ущербную по сравнению с реляционными обработку транзакций. Поэтому ее обычно выносят в отдельный продукт такой как например CICS. Поскольку этот продукт не является СУБД, то о гранулярности блокировки типа записи или страницы можете забыть. При всех прочих равных масштабируемость реляционной системы всегда выше чем это безобразие. Оно используется до сих пор только потому, что переписывать системы разработанные 30 лет назад неоправданно дорого. Дешевле их поддерживать.


А что ж так - 20 лет мучаемся ?

нет чтобы взять и быстренько переписать
благо, с Ваших слов :

<<Реляционная модель не оперирует объектами и связями между ними. Ставьте и формализуйте задачу на естественном (русском, английском, французском или арабском - выбор за вами) языке, мы вам предложим реляционное ее решение. Причем я берусь гарантировать что решение любой нетривиальной задачи по автоматизации предприятия сделанное на базе Oracle + ERP софт + Microstrategy будет разработано быстрее, в эксплуатации дешевле, поддерживается проще, масштабируется на два порядке лучше чем сделанный на коленке самопал поверх каши.>>
30 июл 08, 09:31    [6002437]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
_мод
Guest
Зл0й
Одно из основных преимуществ реляционной СУБД в том что для нее можно (хотя это и непросто) написать оптимизатор запросов.

оптимизатор запросов можно написать для любой СУБД - если в нем есть необходимость
Зл0й

Для СУБД основанных на сетевой модели реализовать оптимизатор запросов и язык высокого уровня работающие с приемлемой производительностью так и не удалось.

В ССУБД оптимизатор запросов вырождается и становится тривиальным. ЯВУ вообще не причем.
Зл0й

Поэтому в нереляционных СУБД нет разделения модели данных на физическую и логическую

Ну да ? (в IMS данные могут храниться на МЛ, и где это определено в МД ?)
Зл0й

и "план исполнения запроса" который в РСУБД генерирует оптимизатор в нереляционных СУБД пишет программист, "ручками", часто с помощью циклов.

В некоторых РСУБД то же самое - какое это имеет отношение к МД.
30 июл 08, 09:32    [6002444]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
vadiminfo
Member

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

А что ж так - 20 лет мучаемся ?


Вам положена большая медаль за приверженность к старинным технологиям. Смотел какую-то передачу про страны, в которые цивилизация не дошла, там пошли еще дальше: мучаются столетиями с устаревшими технологиями, благодаря чему есть что показывать телезрителям в дневное время по выходным.
30 июл 08, 11:09    [6003065]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
DBjob
Member

Откуда:
Сообщений: 29
Зл0й
Вы беретесь гарантировать непротиворечивость данных в "ОСУБД"? Докажите.

А что Вы подразумеваете под непротиворечивостью?


Зл0й
Последний "гвоздь" в гроб нереляционных СУБД заколотили разработки работы в области поддержки конкурентных транзакций. Для реляционных СУБД существуют алгоритмы обработки конкурентных транзакций (например читатели-писатели) корректность которых математически доказуема. Желающих убедиться отсылаю к классической книге Джима Грея.

Нереляционных СУБД в лучшем случае поддерживают весьма ущербную по сравнению с реляционными обработку транзакций. Поэтому ее обычно выносят в отдельный продукт такой как например CICS. Поскольку этот продукт не является СУБД, то о гранулярности блокировки типа записи или страницы можете забыть. При всех прочих равных масштабируемость реляционной системы всегда выше чем это безобразие. Оно используется до сих пор только потому, что переписывать системы разработанные 30 лет назад неоправданно дорого. Дешевле их поддерживать.

Вобще то и для ОСУБД существуют алгоритмы обработки конкурентных транзакций. Причем более качественные чем скажем у Оракла.
30 июл 08, 11:34    [6003289]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
DBjob
Зл0й
Вы беретесь гарантировать непротиворечивость данных в "ОСУБД"? Докажите.

А что Вы подразумеваете под непротиворечивостью?

Допустим если Вы с одного счета какую-то сумму списали, то на другом счете она тут же должна появиться

DBjob

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

Слишком сильное и голословное утверждение. Может как-то конкретизируете: какие ОСУБД, чем качественнее
30 июл 08, 12:32    [6003858]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
onstat-
Member

Откуда:
Сообщений: 6941
DBjob

А что Вы подразумеваете под непротиворечивостью?


Я( за других не скажу)
подразумеваю соответствие представления данных нормальным формам РМД.

А Вы что подразумеваете?

Можете Вы ответить на однократно задаваемый мною вопрос от ответа на который г-н Бред
уклоняется?

Какие ограничения на представления данных имеются в ОСУБД?

Меня устроит только формализованное описание, такое же, которым дается описание НФ в РМД.
Только после того как я увижу формализованное определение я буду рассматривать конкретные примеры.


DBjob

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


Я с удовольствием посмотрю на формализованное описание уровней изолированности
транзакций для ОСУБД (как в стандарте SQL) в контексте понятия навигация .

В стандарте SQL понятия навигация нет , поэтому можете даже не утруждать себя плагиатом.
30 июл 08, 13:40    [6004444]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
DBjob
Member

Откуда:
Сообщений: 29
SergSuper
DBjob
Зл0й
Вы беретесь гарантировать непротиворечивость данных в "ОСУБД"? Докажите.

А что Вы подразумеваете под непротиворечивостью?

Допустим если Вы с одного счета какую-то сумму списали, то на другом счете она тут же должна появиться

Но это вроде обеспечивается атомарностью и изолированностью транзакций. Причем здесь реляционная модель?


SergSuper
DBjob

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

Слишком сильное и голословное утверждение. Может как-то конкретизируете: какие ОСУБД, чем качественнее

Я говорил о локальной разработке. У Оракла есть определенные артефакты связанные с изоляцией транзакций.
30 июл 08, 13:57    [6004574]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 16 17 18 19 20 [21] 22 23 24 25 .. 27   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить