Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 6 7 8 9 10 [11] 12 13 14 15 .. 27   вперед  Ctrl
 Re: недостатки иерархических баз  [new]
Бред
Guest
_мод
Бред
А что вы получили в результате, что это за схема? Где хранятся эти "связи с помощью синонимов" в метаданных?

В результате множественные связи между таблицами просто отсутствуют, что сильно упрощает модель. Но в разных СУБД приемы разные. Ессно все описывается в схеме БД на DDL.

"Просто отсутствуют", "приемы разные", "ессно все в схеме". Все, что отсутствует, естественно в схеме??? Опять не хотите обсуждать вопрос): Ну ничего, я к этому привык. Здесь еще не нашлось человека, который мог бы обсуждать вопросы по-существу до какой-то приемлемой для практической значимости глубины):
4 июл 08, 17:04    [5888803]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
Бред
Guest
_мод
Бред

Осуждение объектного подхода - это оффтопик. (лично меня он не интересует ввиду его крайней ограниченности).

Читай: обсуждение иерархических и сетевых (объектно-ориентированных) систем - это оффтопик??? Супер!
Крайняя ограниченность, надо же! Преимущества перед "реляционным" подходом по всем статьям - это, оказывается, крайняя ограниченность): Впрочем, я, конечно, понимаю, что это по сравнению с "табличным" походом крайняя ограниченность подразумевается): Но тут нестыковочка: по любому конкретному вопросу нежелание обсуждать по существу):
4 июл 08, 17:11    [5888860]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
Бред
Guest
_мод
Бред
Даже самому интересно стало. Вот, например:

Ничего интересного - все это давно сделано, работает, но ограничения очень большие.

Читай: пока ничего не сделано. Кому нужна "универсальная модель" (!), "работающая" (!?) с "большими ограничениями"???
4 июл 08, 17:13    [5888879]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
Бред
Guest
розовый слон...
Бред
Иерархии (ну может быть, кроме естественных, от которых никуда не денешься, так сказать) всегда вредны в БД.

Сильное утверждение. Особенно, если его переформулировать вот так: "Иерархии вредны, но они естественны и от них никуда не денешься". Как это понимать? (Сразу почему-то вспоминается: "Немного водки по утрам полезно в любых количествах".)

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

Это у многих здесь любимое занятие - переформулировать, чтобы поиздеваться): Вторым абзацем ограничиться у Вас мужества не хватило):
Иерархия - это очень плохой способ организации данных и, тем более, описания их семантики.
Но. Россия (ее территория) "состоит из" семи федеральных округов (их территорий), а каждый из них "состоит из" соответствующих "субъектов Российской Федерации" (их территорий). Конечно, эта ситуация не должна поддерживаться "самим разработчиком". И мы уже выяснили, что любую связь 1:М можно, при желании, рассматривать как "иерархическую":
Подразделение -Состоит из/Работает в -> Сотрудник
Накладная - Состоит из/Входит в -> Операция отгрузки
Товар - Используется в/Использует -> Операция огрузки
И т.д.
Вам сильно легче от того, что связь в одном направлении:
Операция отгрузки <- Использует - Товар
не иерархическая
а эта же связь в другом направлении
Товар - Используется в -> Операция огрузки
иерархическая
???
Уверяю Вас, что от "иерархичности связей" в частности, и от иерархий в целом Вы не получите такой пользы, которая могла бы ассоциироваться с высказыванием: "иерархия это единственный и наиболее естественный способ организации данных и описания их семантики".
Может быть Вы подразумеваете, что когда пользователь создает себе интерфейс, используя схему БД, он располагает "Накладную" повыше, а "Операции отгрузки" пониже, что выглядит естественным? А это же, вроде как, иерархия? Но даже здесь должен Вас разочаровать. Я много раз наблюдал пользовательские схемы приложения, в которых "Операция" была выше, а "Накладная" ниже. Или это тоже у нас будет "иерархия"???
4 июл 08, 17:39    [5889101]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
Бред
Guest
недостатки иерархических
ЧАЛ - я взялся не за МД. а за иерархческие базы в их конкретном воплощении, или сетевые, но тоже в их конкретном воплощении. Рассуждать на тему моделей и моделирования мне в этом форуме не интересно, в первую очередь из-за вас.
mumps и cashe и их замечательную интегрированность чего-то во что-то я не хочу рассматривать вообще, так каак считаю, что модуль виртуальной памяти надо писать на asm, а, например, TCP/IP стек можно и на С, тогда как для визуального программирования иногда даже TCL/TK сгодится.
По-этому наличие отдельного языка доступа к данным меня не силько напрягает - более того, я сторонник наличия в системе отдельного уровня доступа к данным, и мне сильно не нравится, когда доступ к данным размазан по системе, как масло по бутерброду - я не говорю о том? что там пишут в книгах про Enterprise Architecture, я говорю о том, что видел, и к чему такие "бутерброды" приводят. Это совсем безотносительно к типу модели и СУБД, как вы понимаете.
Рассуждатб же на тему стабильности вселенной мне ещё меньше хочется - просто есть конечный набор неизменных финансовых операций, на которых банки могут строить огромное изменяемое количество сервисов

Ну зачем же собственную ограниченность сваливать на пагубное влияние ЧАЛа?):
Я гарантирую Вам, что не буду принимать никакого участия в обсуждении иерархических и сетевых моделей и их "конкретного воплощения", если Вас вдруг это заинтересует):
Но пока Вас это не интересует, и мы обсуждаем только "конкретные воплощения". Которые Вы тут же "не хотите рассматривать вообще"!? Бесподобно!
Далее какая-то эклектика из личных предпочтений, "основанных" на ограниченности знаний и каких-то "бутербродах", которые Вы где-то видели. И в завершении правильная мысль, если ее очистить от шелухи "обиды на ЧАЛа":
Если предметная область стабильна, есть уверенность, что схема данных не поменяется в течении жизненного цикла системы, то применение "иерархических баз" не только оправдано, но и очень правильное решение.
Конечно! Разве с этим кто-то спорит? Весь цивилизованный мир так и делает): Такие приложения просто идеально строить на "чистом" mumps. И на IMS, конечно, тоже): Но на mumps проще и эффективнее. Соответствующие сравнения были весьма популярны в свое время):
4 июл 08, 18:07    [5889303]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
Бред
Guest
ЧАЛовед со стажем
розовый слон...
Бред
Иерархии (ну может быть, кроме естественных, от которых никуда не денешься, так сказать) всегда вредны в БД.

Сильное утверждение. Особенно, если его переформулировать вот так: "Иерархии вредны, но они естественны и от них никуда не денешься". Как это понимать? (Сразу почему-то вспоминается: "Немного водки по утрам полезно в любых количествах".)


Было такое, и покруче бывали у ЧАЛ-а высказывания.

Ох уж мне эти "секретные специалисты"): Цитируют все подряд, в чем никогда сами не разберутся. Хоть бы спасибо говорили, иногда):
4 июл 08, 18:09    [5889316]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
Бред
Guest
недостатки иерархических
Вот, читаю, что впервые парадигма "отделения кода бизнес логики от данных" была достигнута в индустрии в IMS при посредстве DL/I, и тут же вспоминаю ЧАЛа, с его "торбой" - интегрированным языком.
Такое впечатление, что это его единственый аргумент.
И до-лампочки, что он уже сорок лет как никого не интересует - знай, своё талдычит.

Надо же какой впечатлительный - тут же вспоминает):
И упорно не замечает ясных и простых аргументов. А не только, и не столько интегрированный язык.
То, что из SQL "конкретные воплотители" медленно делали интегрированный язык - это Вы не замечаете): Люди делают то, что их, оказывается, не интересует!? Чего только не напишешь из-за обиды на ЧАЛа):
4 июл 08, 18:16    [5889352]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
розовый слон...
Guest
Бред
Это у многих здесь любимое занятие - переформулировать, чтобы поиздеваться): Вторым абзацем ограничиться у Вас мужества не хватило):

Я же это по доброму В отсутствие штатных клоунов из Rеляционной бRатвы (Глюк, Мир, Ю-джин, Эндрю и т.п.) приходится прикалываться с кем попало

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

Я хотел сказать очень простую вещь: "Связь (ссылка) == иерархия" (это иерархия по ссылке)

Второе: есть иерархия по значению, которая существует без связи (без ссылок). Например, Россия состоит из фед. округов по определению без всяких ссылок. Ну или вложенность в XML.

Прошу также внести в протокол следующий недостаток ИБД. В реальных приложениях существует много альтернативных иерархий, а потому выбор только одной для иерархической модели является неоднозначным. Например, сотрудник приписан одновременно и отделу и проекту, а значит налицо два родителя и две иерархии: проект состоит из множества сотрудников и отдел состоит из множества сотрудников.
4 июл 08, 18:20    [5889376]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
Бред
Guest
розовый слон...
Бред
Это у многих здесь любимое занятие - переформулировать, чтобы поиздеваться): Вторым абзацем ограничиться у Вас мужества не хватило):

Я же это по доброму В отсутствие штатных клоунов из Rеляционной бRатвы (Глюк, Мир, Ю-джин, Эндрю и т.п.) приходится прикалываться с кем попало

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

Я хотел сказать очень простую вещь: "Связь (ссылка) == иерархия" (это иерархия по ссылке)

Второе: есть иерархия по значению, которая существует без связи (без ссылок). Например, Россия состоит из фед. округов по определению без всяких ссылок. Ну или вложенность в XML.

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

Итак:
1. Я - внештатный клоун): Неплохая "должность" в общем-то):
2. Операция отгрузки <- Входит в - Накладная
тоже иерархия. Ну на здоровье):
3. Центральный федеральный округ может быть не связан с Россией, а Ярославская область - с Центральным федеральным округом, потому что "это итак все знают"): Ну на здоровье): Я уже обращал внимание на нестыковки на стр.539 8-го издания при рассуждениях о связях. Не следует использовать разные механизмы для представления одного и того же. И Дейт тоже это рекомендует (точнее хотел бы рекомендовать).
4 июл 08, 18:32    [5889437]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
недостатки иерархических
Guest
розовый слон...
Прошу также внести в протокол следующий недостаток ИБД. В реальных приложениях существует много альтернативных иерархий, а потому выбор только одной для иерархической модели является неоднозначным. Например, сотрудник приписан одновременно и отделу и проекту, а значит налицо два родителя и две иерархии: проект состоит из множества сотрудников и отдел состоит из множества сотрудников


Несогласен - не обессудьте уж.
Я давал ранее ссылку в этой теме на главу Logical References, и упоминал secondary indexes.
Используя это можно строить такие модели данных...
Там же есть много типов ссылок - Phisical Parent, Logical Parent, Logical Child, Logical Twin, Logical First Child, и читайте, короче, доку. Всё это для того, чтобы приложение получило ту иерархию, которая ему нужна
Рекурсия мне оччень понравилась.
4 июл 08, 21:01    [5889916]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
недостатки иерархических
Guest
_mod - не вижу препятствий в создании 3270 утилиты, которая будет принимать предложения DL/I и возвращать результат.
Но вы знаете, может и хорошо, если её нет.
Старые DBA, что характерно, все запросы SQL кодировали в файл, что позволяло подумать, прежде чем посылать запрос на выполнение, и уже файл с запросов выполняли.
Ну вы поняли, о чём я.
Всегда есть (ну хорошо, в автоматизации пивных ларькёв на 1С может и нет) разделение труда - одни пишут, дроугие делают deploy и эксплуатируют, и страшно представить, что могут наделать даже не кривые, а немного не в себе после вчерашнего руки в production системе с наличием такой утилиты, которая позволяет передать любой запрос базе...
Лично я, давным давно, когда имел дело с production, то всегда писал SQL в файл, и никогда не использовал select *
И мне не понятно стремление иметь графическуюд утилиту, которая принимает SQL, и возвращает результат - так и хочется спросить - а отвечать за последствия кто будет?
Я протьив таких "облегчений" и удобств, которые потенциально очень опасны.
Уж лучше на Сях, или КОБОЛе, пока напишешь-скомпилируешь-склинкуешь - подумаешь. Что получилось - передашь эксплуатационникам.
А они, может быть, инсталлируют.
А может и нет

Вопрос только, сколько таких мазохистов-параноиков осталось?
Всё ведь быстрее, быстрее надо...
4 июл 08, 21:10    [5889936]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
мимопробегал

А иерархичность вовсе не подразумевает императивный навигационный язык.

Иерахичность то может и не подразумечает. Но речь в топике тока об известных иерахических (например, XML к таковым не относят) и сетевых МД, коиея навигацию как бы предполагают. Там доступ такой. В реализации ИСУБД предполагается императивность - команды языка БД встроены в процедурный.
А так, конечно, иерахичность моно найти и в РБД. Хотя с напрягами, но там есть либо иерахические запросы SQL, либо рекурсивные - т.е. наровят избежать императивности и навигационности.
4 июл 08, 23:31    [5890275]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
розовый слон...
В отсутствие штатных клоунов из Rеляционной бRатвы (Глюк, Мир, Ю-джин, Эндрю и т.п.) приходится прикалываться с кем попало


А может над тобой поприкалываться ?
За языком следи, Урод
5 июл 08, 09:41    [5890642]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
весенньее обострение блин, опять клоуны ЧАЛа
друг над дружкой прикалываются
5 июл 08, 09:44    [5890648]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
okdoky
Member

Откуда:
Сообщений: 349
vadiminfo
мимопробегал

А иерархичность вовсе не подразумевает императивный навигационный язык.

Иерахичность то может и не подразумечает. Но речь в топике тока об известных иерахических (например, XML к таковым не относят) и сетевых МД, коиея навигацию как бы предполагают. Там доступ такой. В реализации ИСУБД предполагается императивность - команды языка БД встроены в процедурный.
А так, конечно, иерахичность моно найти и в РБД. Хотя с напрягами, но там есть либо иерахические запросы SQL, либо рекурсивные - т.е. наровят избежать императивности и навигационности.
Дак моно или не моно? А таблицы теперь моно найти в РМД, СМД, ИМД, ОМД? Вы их долго не видели тама.

К какой же модели теперь относится XML? Неужели к XМД? Столько сил потратили на критику навигации в ИМД, а тут вдруг бац, XML проповедующий алгебру множеств в XPath объявился. Зигзаг какой-то извивается, тоже претендует на алгебру. Неужели вы их к РМД хотите отнести? А как же Оракул тогда? Как же он потерпит такую компанию?
5 июл 08, 10:30    [5890687]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
okdoky
Member

Откуда:
Сообщений: 349
Gluk (Kazan)
весенньее обострение блин, опять клоуны ЧАЛа
друг над дружкой прикалываются
А в Казани уже лето? Счастливые.
5 июл 08, 10:39    [5890691]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
okdoky
Gluk (Kazan)
весенньее обострение блин, опять клоуны ЧАЛа
друг над дружкой прикалываются
А в Казани уже лето? Счастливые.


Ваш с Калекой Чалом демарш я склонен расценивать как стремление уйти от темы предмета обсуждения (такое за вами замечалось и ранее). Вынужден Вас разочаровать. Я НЕ НАМЕРЕН помогать Вам утопить тему в потоке флейма
Будьте так любезны вернуться к теме обсуждения :) или поискать себе более другое место

Все пожелания, эпитеты, угрозы и прочее, адресованные мне ЛИЧНО, соблаговолите отсылать мне в почту (я ее ни от кого не срываю и с УДОВОЛЬСТВИЕМ Вам отвечу). И не пытайтесь затащить меня в ваш бессвязный флейм, прибегая и далее к столь вами любимым грязным приемчикам.

Калека, это и Вас касается
5 июл 08, 12:08    [5890797]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
розовый слон.....
Guest
недостатки иерархических
розовый слон...
Прошу также внести в протокол следующий недостаток ИБД. В реальных приложениях существует много альтернативных иерархий, а потому выбор только одной для иерархической модели является неоднозначным. Например, сотрудник приписан одновременно и отделу и проекту, а значит налицо два родителя и две иерархии: проект состоит из множества сотрудников и отдел состоит из множества сотрудников


Несогласен - не обессудьте уж.

Нет проблем. Тем более, что это вовсе не мое мнение, а общепризнанный недостаток ИМД, который принято называть если не первым, то где-то в начале списка.

недостатки иерархических
Я давал ранее ссылку в этой теме на главу Logical References, и упоминал secondary indexes.
Используя это можно строить такие модели данных...

В каждой дискуссии мы приходим к одному и тому же, что можно вовсе не значит что модель для этого предназначена. Например, в РМ можно моделировать связи, но тем не менее их там нет. Раз IMS широко применяется, то это автоматически означает, что в ней можно если не все, то почти все, но мы же говорим о недостатках, а не о возможностях их обойти (с помощью навешенных сбоку механизмов через 30 лет после написания первой версии). Так что я вполне соглашусь, что в IMS можно реализовать любую другую модель данных и не только модель данных.

недостатки иерархических
Там же есть много типов ссылок - Phisical Parent, Logical Parent, Logical Child, Logical Twin, Logical First Child, и читайте, короче, доку. Всё это для того, чтобы приложение получило ту иерархию, которая ему нужна

Читал. Спасибо. Но это никак не решает ту принципиальную проблему, о которой я упоминал (но позволяет обойти ее и решать почти все реальные задачи). Вот еще раз. Если сотрудник приписан одному проекту и одному отделу, то какой дизайн БД выбрать: 1. Проект это родитель, а сотрудники его дети, или 2. Отдел это родитель а сотрудники это его дети.

Ясно, что оба дизайна будут работать (при использовании логических ссылок), но мы говорим о принципиальном логическом баге всей модели как таковой. Если каждый разработчик будет от балды выбирать дизайн (а реальные приложения намного сложнее), то ничего хорошего не выйдет. Для сравнения, в РМ такого недостатка нет, что дает большие преимущества.
5 июл 08, 13:48    [5890896]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
N-ый штатный клоун
Guest
розовому слону
сам дурак.

....20-й раз о том же. скучноооууу....
5 июл 08, 22:09    [5891576]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
vadiminfo
Member

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

Дак моно или не моно?

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

okdoky


А таблицы теперь моно найти в РМД, СМД, ИМД, ОМД? Вы их долго не видели тама.

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

okdoky


К какой же модели теперь относится XML?

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

okdoky

Неужели к XМД? Столько сил потратили на критику навигации в ИМД, а тут вдруг бац, XML проповедующий алгебру множеств в XPath объявился. Зигзаг какой-то извивается, тоже претендует на алгебру. Неужели вы их к РМД хотите отнести? А как же Оракул тогда? Как же он потерпит такую компанию?

Про XML и ИМД см. выше. Ни в какую ЭТУ компанию Оракл в реале не попадал. Тока в Вашем воображении.
Что до Зигзага, то он может претендовать не тока на алгебру но и на топологию. Это его дело. А что до XML, то он в Орале есть.
5 июл 08, 22:24    [5891597]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
okdoky
Member

Откуда:
Сообщений: 349
vadiminfo
не все хде есть иерархии является ИМД.
В ИМД для структурирования спользуется понятия тип записи.
Ага, значит XML с описанием схемы (DTD, XML Schema) является таки ИМД?
vadiminfo
Вы можете таблы искать где угодно. А мне проще те средства структурирования, которые там есть.
Самое простое для МД это граф. Вы только с ним работаете? Как же вы без таблиц в базах данных? Попробуйте работать с диаграммами тогда. Это тоже просто и не только для МД СУЩНОСТЬ-СВЯЗЬ. Тренируйте извилины.
vadiminfo
Для тугодумов повторяю в 10 раз – они (XML) относятся к полуструктурированным (или слабоструктурированным). Т.е. о типе записе речи нет
Что-то вы действительно зациклились. Значит моно назвать XML модель данных слабоструктурированной ИМД? Кстати Зигзаг-МД моно назвать слабоструктурированной РМД.

Вам может почитать что-нибудь про ИМД? Например, Сравнительная характеристика моделей данных. Там тоже есть ошибки, но их меньше, чем в вашей голове. Кстати там есть много о недостатках ИМД, как раз по теме. Я бы выделил следующие:
- отношения М:М могут быть реализованы только искусственно
- могут быть избыточные данные
- удаление исходных объектов ведет к удалению порожденных объектов
- доступ к любому порожденному узлу возможен только через корневой узел
- сильная зависимость логической и физической БД
- сильно ограниченный набор структур запроса
vadiminfo
okdoky
Столько сил потратили на критику навигации в ИМД, а тут вдруг бац, XML проповедующий алгебру множеств в XPath объявился. Зигзаг какой-то извивается, тоже претендует на алгебру. Неужели вы их к РМД хотите отнести? А как же Оракул тогда? Как же он потерпит такую компанию?
Ни в какую ЭТУ компанию Оракл в реале не попадал. Тока в Вашем воображении.
Опять же в диалоге рекомендую ссылаться на литру, Опыт построения XML-СУБД. Причиной возврата к подзабытым иерархическим структурам в варианте XML стало более естественное для человека отражение семантики предметного мира. XML-СУБД позволяют непосредственно отображать документооборот в базе данных.... Интересно что эта статья написана "зловредными" кэшистами на сайте Оракэл.
6 июл 08, 09:35    [5892030]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
Бред
Guest
Gluk (Kazan)
okdoky
Gluk (Kazan)
весенньее обострение блин, опять клоуны ЧАЛа
друг над дружкой прикалываются
А в Казани уже лето? Счастливые.


Ваш с Калекой Чалом демарш я склонен расценивать как стремление уйти от темы предмета обсуждения (такое за вами замечалось и ранее). Вынужден Вас разочаровать. Я НЕ НАМЕРЕН помогать Вам утопить тему в потоке флейма
Будьте так любезны вернуться к теме обсуждения :) или поискать себе более другое место

Все пожелания, эпитеты, угрозы и прочее, адресованные мне ЛИЧНО, соблаговолите отсылать мне в почту (я ее ни от кого не срываю и с УДОВОЛЬСТВИЕМ Вам отвечу). И не пытайтесь затащить меня в ваш бессвязный флейм, прибегая и далее к столь вами любимым грязным приемчикам.

Калека, это и Вас касается

Уважаемый Gluk(Kazan)!
Я здесь пишу сообщения под ником Бред, и никак Вас не задевал): [Понимаю, что местные подонки запросто могут воспользоваться этим ником, чтобы меня подставить, но тут уж ничего не поделаешь):] Я, как Вы прекрасно не раз уже убеждались, никогда не ухожу от темы, а, наоборот, стараюсь рассмотреть ее максимально глубоко. Это мои оппоненты постоянно, как и на этот раз, сворачивают обсуждение сразу же, как только понимают, что зашли в тупик, и по-существу вопроса им сказать нечего. Зарегистрироваться и выступать под собственным именем не получилось. Ваши друзья (?) заблокировали возможность отправлять сообщения уже с 6(!) компьютеров, к которым я имел доступ): Остались вот этот ноутбук родственников и комп на работе, с которыми они никак не могут справиться): Очных семинаров по любым вопросам БД Ваши коллеги (!) боятся как огня, ведь там не получиться игнорировать факты, вырывать удобные словосочетания из контекста и ссылаться (уж извините) на происки клонов):
Пожалуйста, если получится, не оскорбляйте меня - это Вам не поможет разобраться в вопросах БД): Если не получится, то, конечно, оскорбляйте на здоровье - я привык):
Всего хорошего!
Я был бы рад, если бы розовый слон рассекретился):
6 июл 08, 12:49    [5892257]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
Бред
Guest
розовый слон.....
недостатки иерархических
розовый слон...
Прошу также внести в протокол следующий недостаток ИБД. В реальных приложениях существует много альтернативных иерархий, а потому выбор только одной для иерархической модели является неоднозначным. Например, сотрудник приписан одновременно и отделу и проекту, а значит налицо два родителя и две иерархии: проект состоит из множества сотрудников и отдел состоит из множества сотрудников


Несогласен - не обессудьте уж.

Нет проблем. Тем более, что это вовсе не мое мнение, а общепризнанный недостаток ИМД, который принято называть если не первым, то где-то в начале списка.

недостатки иерархических
Я давал ранее ссылку в этой теме на главу Logical References, и упоминал secondary indexes.
Используя это можно строить такие модели данных...

В каждой дискуссии мы приходим к одному и тому же, что можно вовсе не значит что модель для этого предназначена. Например, в РМ можно моделировать связи, но тем не менее их там нет. Раз IMS широко применяется, то это автоматически означает, что в ней можно если не все, то почти все, но мы же говорим о недостатках, а не о возможностях их обойти (с помощью навешенных сбоку механизмов через 30 лет после написания первой версии). Так что я вполне соглашусь, что в IMS можно реализовать любую другую модель данных и не только модель данных.

недостатки иерархических
Там же есть много типов ссылок - Phisical Parent, Logical Parent, Logical Child, Logical Twin, Logical First Child, и читайте, короче, доку. Всё это для того, чтобы приложение получило ту иерархию, которая ему нужна

Читал. Спасибо. Но это никак не решает ту принципиальную проблему, о которой я упоминал (но позволяет обойти ее и решать почти все реальные задачи). Вот еще раз. Если сотрудник приписан одному проекту и одному отделу, то какой дизайн БД выбрать: 1. Проект это родитель, а сотрудники его дети, или 2. Отдел это родитель а сотрудники это его дети.

Ясно, что оба дизайна будут работать (при использовании логических ссылок), но мы говорим о принципиальном логическом баге всей модели как таковой. Если каждый разработчик будет от балды выбирать дизайн (а реальные приложения намного сложнее), то ничего хорошего не выйдет. Для сравнения, в РМ такого недостатка нет, что дает большие преимущества.

Да, но в РМ есть другой недостаток - дизайн (в буквальном смысле - дизайн приложения) придется-таки выбирать, программировать и навязывать многочисленным пользователям):
А в современных "иерархически/сетевых" системах (объектных) нет и этого недостатка. Создал схему БД (конечно, в Вашем примере она чересчур упрощена):
Проект <-Ведется в/Ведет- Отдел
Сотрудник <-Работает над/Над которым работает- Проект
Сотрудник <-Работает в/Состоит из- Отдел
А уж дизайн каждый пользователь сделает себе сам. Для ленивых обычно предлагают "схемы от разработчика", причем тоже без всякого программирования):
6 июл 08, 12:58    [5892272]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
Бред
Guest
okdoky
vadiminfo
не все хде есть иерархии является ИМД.
В ИМД для структурирования спользуется понятия тип записи.
Ага, значит XML с описанием схемы (DTD, XML Schema) является таки ИМД?
vadiminfo
Вы можете таблы искать где угодно. А мне проще те средства структурирования, которые там есть.
Самое простое для МД это граф. Вы только с ним работаете? Как же вы без таблиц в базах данных? Попробуйте работать с диаграммами тогда. Это тоже просто и не только для МД СУЩНОСТЬ-СВЯЗЬ. Тренируйте извилины.
vadiminfo
Для тугодумов повторяю в 10 раз – они (XML) относятся к полуструктурированным (или слабоструктурированным). Т.е. о типе записе речи нет
Что-то вы действительно зациклились. Значит моно назвать XML модель данных слабоструктурированной ИМД? Кстати Зигзаг-МД моно назвать слабоструктурированной РМД.

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

Работы над XML-СУБД ведутся давно многими группами разработчиков. У меня нет никаких сомнений в бесперспективности этих работ): Но, конечно, технологии интернет (обмен данными в том числе) и технологии СУБД будут продолжать сближаться, и что-то из этого получится):
6 июл 08, 13:12    [5892290]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
Бред
Уважаемый Gluk(Kazan)!
Я здесь пишу сообщения под ником Бред, и никак Вас не задевал): [Понимаю, что местные подонки запросто могут воспользоваться этим ником, чтобы меня подставить, но тут уж ничего не поделаешь)


Вам уже сотню раз говорили, что можно с этим поделать (зарегестрироваться (снова если ту учетку разбанивать не хотят)). А до тех пор, позвольте мне считать, что Вы и Розовый Слон - физически одно лицо (слишком уж много косвенных факторов на это указывает).
За сим позвольте откланяться
6 июл 08, 13:54    [5892385]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 6 7 8 9 10 [11] 12 13 14 15 .. 27   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить