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

Так я не понял, "иерархических", "сетевых" или объектных"? О каких системах Вы говорите? И что означает "современных"? Это какие-то конкретные системы или просто для красного словца?

Бред
Создал схему БД (конечно, в Вашем примере она чересчур упрощена):
Проект <-Ведется в/Ведет- Отдел
Сотрудник <-Работает над/Над которым работает- Проект
Сотрудник <-Работает в/Состоит из- Отдел

Такая схема правильная имхо, но слишком общая. Я могу представить довольно много совершенно разных подходов к моделированию данных, где такая запись абсолютно корректна. Поэтому можно пару вопросов:

А где здесь иерархия, т.е. где здесь дети и родители?
Стрелки это просто связи (ссылки) или это иерархические связи?
Если здесь где-то иерархия, то чем это отличается от просто связей?
Если тут иерархия, то как она представляется?
6 июл 08, 14:22    [5892480]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
vadiminfo
Member

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

Ага, значит XML с описанием схемы (DTD, XML Schema) является таки ИМД?

Ну разве что у Вас является. Я придерживаюсь более традиционных взглядов. Не является ни разу.
Тип записи в ИМД - это совсем другое.

okdoky

Самое простое для МД это граф. Вы только с ним работаете? Как же вы без таблиц в базах данных? Попробуйте работать с диаграммами тогда. Это тоже просто и не только для МД СУЩНОСТЬ-СВЯЗЬ. Тренируйте извилины.

Ну в том что Вы понимает под МД, а возможно и под графом у Вас может и "самое простое для МД".
Это расскажете када Вас позовут проектировать БД.
С чего взяли что без таблиц "работаю в базах данных"? С того что их нет в перечисленных Вами МД?
Так их там никада не было, а работают. С диаграмми работаю. И не тока я. Есть CASE средста.
Я извилины то тренирую. А Вы похоже пренебрегаете этим.

okdoky
Для тугодумов повторяю в 10 раз – они (XML) относятся к полуструктурированным (или слабоструктурированным). Т.е. о типе записе речи нет

Просто слабостурированной. Название ИМД - закреплено за сильнотипизированными. В отходе от общепринятой классификации пока не видно смысла. Если тока внести путанницу, в надежде протащить куда-нить Зигзаг. И то вряд ли поможет.

okdoky


Кстати Зигзаг-МД моно назвать слабоструктурированной РМД.

Называйте его чем хотите. Смешнее буит.

okdoky

Вам может почитать что-нибудь про ИМД? Например, Сравнительная характеристика моделей данных. Там тоже есть ошибки, но их меньше, чем в вашей голове. Кстати там есть много о недостатках ИМД, как раз по теме. Я бы выделил следующие:
- отношения М:М могут быть реализованы только искусственно
- могут быть избыточные данные
- удаление исходных объектов ведет к удалению порожденных объектов
- доступ к любому порожденному узлу возможен только через корневой узел
- сильная зависимость логической и физической БД
- сильно ограниченный набор структур запроса


За ссылку спасибо, но у меня полно литры. Потому открывайте Америку про ИМД для кого-нить другого.
Все эти пункты есть в XML? Уже забыли про Вашу мыстль отнести XML к ИМД?

okdoky

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

А еще в диалоге рекомендуется понимать о чем Вам пишут. Все последненее и относится к достоинсвам слабоструктурированности. Потому ее принципиально отличают от структурированных.
Короче, весь Ваш пафос хорошо бы подошел в студенческой аудитории после прослушивания первых лекций по БД. Зачем Вы не идете получить образование? Там бы отвели душу. Здесь могут не оценить. Да и Зигзагу не поможет.
6 июл 08, 14:57    [5892602]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
okdoky
Member

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

Ага, значит XML с описанием схемы (DTD, XML Schema) является таки ИМД?

Ну разве что у Вас является. Я придерживаюсь более традиционных взглядов. Не является ни разу.
Тип записи в ИМД - это совсем другое.
Вы бы уж определили тогда, что такое тип записи. Вот как выглядит тип записи Address(name, street, city, zip) в XML Schema:
<complexType name=”Address”>
  <sequence>
    <element name=”name” type=”string”/>
    <element name=”street” type=” string”/>
    <element name=”city” type=” string”/>
    <element name=”zip” type=”string”/>
  </sequence>
</complexType>

vadiminfo
okdoky
Для тугодумов повторяю в 10 раз – они (XML) относятся к полуструктурированным (или слабоструктурированным). Т.е. о типе записе речи нет
Не приписывайте мне свои выражения. Во-первых я не люблю повторять одно и то же без доказательств. И когда оппонент уже совсем упертый, просто перестаю отвечать. Во-вторых, это переход на личности, которым больше занимаются флудисты, не имеющие достаточной доказательной базы. Странно, что модератор SergSuper не замечает подобные выпады у ВадимаИнфо и Глюка. Возможно, любовь к Ораклу вас так объединяет?

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

Этого достаточно?
6 июл 08, 16:36    [5892809]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
okdoky
Member

Откуда:
Сообщений: 349
Так, наверное, будет лучше?

ОСНОВНЫЕ НЕДОСТАТКИ ИМД
1. отношения М:М реализуются за счет избыточных данных
2. удаление исходных объектов ведет к удалению порожденных объектов
3. доступ к любому порожденному узлу возможен только через корневой узел
4. более ограниченная структура запроса
6 июл 08, 16:47    [5892829]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
Бред
Guest
реляционный дебил
Бред
А в современных "иерархически/сетевых" системах (объектных) нет и этого недостатка.

Так я не понял, "иерархических", "сетевых" или объектных"? О каких системах Вы говорите? И что означает "современных"? Это какие-то конкретные системы или просто для красного словца?

Бред
Создал схему БД (конечно, в Вашем примере она чересчур упрощена):
Проект <-Ведется в/Ведет- Отдел
Сотрудник <-Работает над/Над которым работает- Проект
Сотрудник <-Работает в/Состоит из- Отдел

Такая схема правильная имхо, но слишком общая. Я могу представить довольно много совершенно разных подходов к моделированию данных, где такая запись абсолютно корректна. Поэтому можно пару вопросов:

А где здесь иерархия, т.е. где здесь дети и родители?
Стрелки это просто связи (ссылки) или это иерархические связи?
Если здесь где-то иерархия, то чем это отличается от просто связей?
Если тут иерархия, то как она представляется?

Вы не прочитали все взаимосвязанные сообщения (на очном семинаре у Вас не было бы такой возможности - вырывать предложения из контекста), но мне не превыкать повторять очевидные вещи по несколько раз):
1. Иерархические и сетевые системы являются объектно-ориентированными, в отличие от реляционных - записеориентированных систем. Объектных (именно в этом классическом понимании, то есть не обязательно основанных на принципах ООП) систем создано много. Я уже много раз рекомендовал Вашим коллегам (может быть и Вам, но ведь Вы предпочитаете скрываться):) обращаться к разработчикам, когда их интересует что-то конкретное.
2. Схема из примера "розового слона", и я ясно написал, что она очень упрощена (не мной).
3. Представьте пожалуйста не много, а пару "подходов к моделированию данных" (заметьте, что я показал применение конкретной модели, что такое "подход" пока не очень понятно), в которых объявление схемы БД так же приведет к созданию приложения.
4. В ходе обсуждение темы было предложено (как Вы могли бы заметить не мной) сначала считать иерархическими все связи 1:М, например
Отдел -Состоит их/Работает в-> Сотрудник
в направлении от Отдела к Сотруднику, то есть
Отдел -Состоит из-> Сотрудник
а потом и вообще все связи, то есть и
Сотрудник <-Работает в- Отдел
Я на это ясно сказал: "ну и на здоровье". Если кому-то что-то может дать прилагательное "иерархический". Естественно, никакой иерархии (то есть "служебной лестницы" - см. что такое иерархия) здесь нет, причем ни в одном, ни в другом направлении):
6 июл 08, 17:30    [5892918]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
Бред
Guest
Gluk (Kazan)
Бред
Уважаемый Gluk(Kazan)!
Я здесь пишу сообщения под ником Бред, и никак Вас не задевал): [Понимаю, что местные подонки запросто могут воспользоваться этим ником, чтобы меня подставить, но тут уж ничего не поделаешь)


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

Ну вот видите, я опять прав): Опять берем себе удобные словосочетания, и вперед!
Ну что же, я же сказал, что привык. Обзывайтесь и дальше на здоровье): Ну не по существу же, в самом деле, обсуждать вопросы): Я Вас очень хорошо понимаю, на самом деле):
6 июл 08, 17:35    [5892929]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
реляционный дебил
Guest
Бред
Сотрудник <-Работает в- Отдел
Я на это ясно сказал: "ну и на здоровье". Если кому-то что-то может дать прилагательное "иерархический". Естественно, никакой иерархии (то есть "служебной лестницы" - см. что такое иерархия) здесь нет, причем ни в одном, ни в другом направлении):


Чего то я запутался. Так иерархия есть или ее нет? По Вашему мнению, т.е. в Вашей модели. С одной стороны Вы говорите "на здоровье" а потом говорите что ее нет. Так есть или нет? Что-то мне подсказывает, что у Вас ее нет, т.е. отдел, состоящий из сотрудников это не иерархия. Но что это тогда: множество? связи?

Более общий вопрос: "Что такое вообще иерархия и когда можно говорить что она есть а когда ее нет?" Например, если отдел состоит из сотрудников, то это иерархия? Если нет, то что это тогда? А если отдел состоит из подотделов, то это иерархия? Вообще, иерархия существует объективно в ПО, или это моделировщик ее вносит (или не вносит)?
6 июл 08, 18:06    [5893026]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
okdoky
Вы бы уж определили тогда, что такое тип записи.

А че мне определяся? Это известно лет эдак 40 а то и более.
okdoky

Вот как выглядит тип записи Address(name, street, city, zip) в XML Schema:
<complexType name=”Address”>
  <sequence>
    <element name=”name” type=”string”/>
    <element name=”street” type=” string”/>
    <element name=”city” type=” string”/>
    <element name=”zip” type=”string”/>
  </sequence>
</complexType>

Ну и хорошо, что так выглятит схема. Она не есть тип записи (даже у Вас с помощью схемы представляется всего лишь тип записи). Мало ли что с ее помощью можно представить. Это лишь говорит о ее выразительности. Но еще важнее как выглядят данные в XML. И еще важнее что их интепритация не отделена от данных в отличии от структурированных МД.
Документы в ворде еще слабее типизированы и там интерпритация в двнных в тесте. С их помощью можно "представить" шо угодно. Но это не значит что образ - результат представления и прообраз то что представляли - одно и то же.
Я не пойму Вы хототие отрицать, что XML относится к слаботитпизированным или что?

okdoky
Во-первых я не люблю повторять одно и то же без доказательств. И когда оппонент уже совсем упертый, просто перестаю отвечать. Во-вторых, это переход на личности, которым больше занимаются флудисты, не имеющие достаточной доказательной базы. Странно, что модератор SergSuper не замечает подобные выпады у ВадимаИнфо и Глюка. Возможно, любовь к Ораклу вас так объединяет?

Не знаю что Вы там любите. Но про тренировку извилин Вы первый написали. Это не переход на личности? А Смайлики где Вы якобы что-то доказали? У меня Самайликов в текстах нет. Хотя может мне было что-то вполне смешно. И если переходил на личности, то в ответ, раз у Вас используется как аргументация. Типа я тоже так могу.


okdoky
Да, все эти пункты относятся к XML, потому что он ориентирован на иерархическую модель данных. В качестве бесспорных недостатков ИМД, я бы оставил только четыре:
1. могут быть избыточные данные
2. удаление исходных объектов ведет к удалению порожденных объектов
3. доступ к любому порожденному узлу возможен только через корневой узел
4. более ограниченная структура запроса

Этого достаточно?

А что выкинули про сильную логическую зависимость логической и физической МД? К XML не подходит?
А что скрывается за более ограниченной структурой запроса? Мож тоже к XML не подходит?

Зато пропали традтиционные недостатки. Про навигационный доступ и императивный язык.
Из-за которых собсно РМД и вытеснила ИМД. А ведь это не ппросто. ИМД господствали на момент появления РМД.

Короче, это расширение класса ИМД, за счет привнесение туда левых МД и должно потерять свойств, которые были изначально. Так можно свалить все классы в один большой. Вот хорошо - недостатков тада обнаружить ни у кого и вовсе не удастся. Чего не достает ИМД есть в XML, а чего нет в РМД есть в ООМД. Да и по сравнению с чем недостатки? - ить больше классов МД нет. Есть тока один.
6 июл 08, 18:46    [5893093]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
Бред
Guest
реляционный дебил
Бред
Сотрудник <-Работает в- Отдел
Я на это ясно сказал: "ну и на здоровье". Если кому-то что-то может дать прилагательное "иерархический". Естественно, никакой иерархии (то есть "служебной лестницы" - см. что такое иерархия) здесь нет, причем ни в одном, ни в другом направлении):


Чего то я запутался. Так иерархия есть или ее нет? По Вашему мнению, т.е. в Вашей модели. С одной стороны Вы говорите "на здоровье" а потом говорите что ее нет. Так есть или нет? Что-то мне подсказывает, что у Вас ее нет, т.е. отдел, состоящий из сотрудников это не иерархия. Но что это тогда: множество? связи?

Более общий вопрос: "Что такое вообще иерархия и когда можно говорить что она есть а когда ее нет?" Например, если отдел состоит из сотрудников, то это иерархия? Если нет, то что это тогда? А если отдел состоит из подотделов, то это иерархия? Вообще, иерархия существует объективно в ПО, или это моделировщик ее вносит (или не вносит)?

Итак:
По п. 1 и 2 Вам все понятно. Это хорошо):
П.3, как я и ожидал, замяли. Это плохо, но я к этому привык):
И, наконец, Вы запутались в самом простом п.4. Перечитаем еще раз:

4. В ходе обсуждения темы было предложено (как Вы могли бы заметить не мной) сначала считать иерархическими все связи 1:М, например
Отдел -Состоит из/Работает в-> Сотрудник
в направлении от Отдела к Сотруднику, то есть
Отдел -Состоит из-> Сотрудник
а потом и вообще все связи, то есть и
Сотрудник <-Работает в- Отдел
Я на это ясно сказал: "ну и на здоровье". Если кому-то что-то может дать прилагательное "иерархический". Естественно, никакой иерархии (то есть "служебной лестницы" - см. что такое иерархия) здесь нет, причем ни в одном, ни в другом направлении):

В чем здесь можно запутаться???
Читайте так же мои совершенно ясные высказывания об ИМД и "пользе иерархий".

"Если отдел состоит из сотрудников", то это, конечно, не иерархия. Это же очевидно - см. что такое иерархия (вот отдел состоящий из подотделов можно назвать иерархией). Беда в том, что в ИМД что угодно называется иерархией (ведь это иерархическая модель):). В РМД что угодно называется отношением (ведь это реляционная модель):). В ОМД есть объекты и связи, и объекты, на сегодняшний день, как я уже неоднократно говорил, так же не типизируются (сущности и события - это очень перспективная типизация, и я уверен, что реализация не заставит себя ждать):)
В чем здесь можно запутаться - ума не приложу):
6 июл 08, 19:01    [5893120]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
распутыватель
Guest
okdoky
vadiminfo
okdoky

Ага, значит XML с описанием схемы (DTD, XML Schema) является таки ИМД?

Ну разве что у Вас является. Я придерживаюсь более традиционных взглядов. Не является ни разу.
Тип записи в ИМД - это совсем другое.
Вы бы уж определили тогда, что такое тип записи.
Похоже vadiminfo путает ИМД и иерархические базы данных. Для него это одно и тоже.
6 июл 08, 20:05    [5893231]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
okdoky
Странно, что модератор SergSuper не замечает подобные выпады у ВадимаИнфо и Глюка. Возможно, любовь к Ораклу вас так объединяет?


Скорее любовь к здравому смыслу.

Друг мой, где я на Вас в этой теме выпал ? Это Вас интересуют погодные условия в Казани :(
Я Вам уже сказал, если есть желание обратиться ко мне лично, используйте почту,
а втягивать меня в не интересный мне разговор, лишний раз поминая всуе - как раз таки тема для модерирования.
7 июл 08, 09:18    [5894055]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
Бред
Ну не по существу же, в самом деле, обсуждать вопросы): Я Вас очень хорошо понимаю, на самом деле):


Мне НЕ ИНТЕРЕСНО в 1001 раз пережевывать один и тот же Бред
Вы уж сами как нибудь. (Подозреваю что) Вам за это деньги платють
7 июл 08, 09:48    [5894163]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
_мод
Guest
Бред
Впрочем, я, конечно, понимаю, что это по сравнению с "табличным" походом крайняя ограниченность подразумевается):

Именно так
7 июл 08, 10:05    [5894233]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
_мод
Guest
Бред
Кому нужна "универсальная модель" (!), "работающая" (!?) с "большими ограничениями"???

Никому
7 июл 08, 10:05    [5894236]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
Бред
Guest
_мод
Бред
Впрочем, я, конечно, понимаю, что это по сравнению с "табличным" походом крайняя ограниченность подразумевается):

Именно так


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

"Но тут нестыковочка: по любому конкретному вопросу нежелание обсуждать по существу):"

От всех конкретных вопросов Вы благополучно ушли):
7 июл 08, 20:07    [5899145]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
Бред
Guest
_мод
Бред
Кому нужна "универсальная модель" (!), "работающая" (!?) с "большими ограничениями"???

Никому

Замечательно! А зачем же писать: "Ничего интересного - все это давно сделано"???
Что сделано-то??? "Универсальная модель" (?), "работающая" (??) с "очень большими ограничениями" (???)
Вот я и говорю, что ничего пока не сделано, а Вы, как и большинство на этом сайте, берете из моего сообщения нужное Вам, чтобы ничего не обсуждать, предложение, и отвечаете о чем-то о другом):
7 июл 08, 20:11    [5899153]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
_мод
Guest
Бред
От всех конкретных вопросов Вы благополучно ушли):

Сначала научитесь их задавать :)
8 июл 08, 09:00    [5900032]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
_мод
Guest
Бред
Что сделано-то??? "Универсальная модель" (?), "работающая" (??) с "очень большими ограничениями" (???)

И сделана и работает. И сразу стали видны ограничения объектного подхода - что можно, что нельзя. Вопрос закрыт. Настоящая "Универсальная модель" - это сетевая МД.
8 июл 08, 09:04    [5900043]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
реляционный дебил
Guest
_мод
Настоящая "Универсальная модель" - это сетевая МД.


А вот интересно, что же ей тогда помешало найти широкое применение? Может не хватает какого-то небольшого последнего винтика до полного успеха? Или все-таки причины лежат глубже и не хватает последнего гвоздя (в ее гроб)?

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

Поэтому сетевая модель может быть и хороша, но из-за этого парадокса ее вряд ли можно широко использовать. Что же делать?
8 июл 08, 12:45    [5901832]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
реляционный лох
Guest
Бред
"Если отдел состоит из сотрудников", то это, конечно, не иерархия. Это же очевидно - см. что такое иерархия (вот отдел состоящий из подотделов можно назвать иерархией).
...
В чем здесь можно запутаться - ума не приложу):


Совершенно не ясно, как выявить иерархию, т.е. где четкий критерий, что является иерархией, а что просто связями? Например, почему отдел, состоящий из подотделов это иерархия, а если отдел состоит из сотрудников, то иерархии уже нет. Мы употребляем одно слово "состоит". Сотрудники и подотделы это просто сущности (объекты). Где здесь разница и в чем подвох?

Чтобы было более понятно, в чем проблема. Пусть у нас есть 1000 сущностей ну и еще больше связей между ними, например, кто-то где-то работает, кто-то куда-то доставляет, кто-то где-то живет ну и т.д. Как мне, простому реляционному лох, взращенному на книгах Дейта, понять, где здесь иерархия? Я ночами не сплю и мучаюсь, взывая к реляционным духам и богам, но ничего мне не может помочь, так может кто-то здесь спасет меня от страданий.
8 июл 08, 12:54    [5901918]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
okdoky
Member

Откуда:
Сообщений: 349
реляционный лох
Бред
"Если отдел состоит из сотрудников", то это, конечно, не иерархия. Это же очевидно - см. что такое иерархия (вот отдел состоящий из подотделов можно назвать иерархией).
...
В чем здесь можно запутаться - ума не приложу):


Совершенно не ясно, как выявить иерархию, т.е. где четкий критерий, что является иерархией, а что просто связями? Например, почему отдел, состоящий из подотделов это иерархия, а если отдел состоит из сотрудников, то иерархии уже нет. Мы употребляем одно слово "состоит". Сотрудники и подотделы это просто сущности (объекты). Где здесь разница и в чем подвох?

Чтобы было более понятно, в чем проблема. Пусть у нас есть 1000 сущностей ну и еще больше связей между ними, например, кто-то где-то работает, кто-то куда-то доставляет, кто-то где-то живет ну и т.д. Как мне, простому реляционному лох, взращенному на книгах Дейта, понять, где здесь иерархия? Я ночами не сплю и мучаюсь, взывая к реляционным духам и богам, но ничего мне не может помочь, так может кто-то здесь спасет меня от страданий.
Иерархию связей можно отобразить в виде "многоуровневого дерева" связей. Это более понятно? Тогда, если связь Отдел - Подотделы рассматривать как дерево отделов (подотделов), это - иерархия отделов (подотделов).

С Отдел - Сотрудники такой фокус не проходит. Впрочем, если посмотреть на эту связь как на отношение между объектами. Может получиться что-то ввиде иерархии (дерева) объектов. Но для этого надо не только смотреть...
8 июл 08, 14:38    [5902695]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
Бред
Guest
_мод
Бред
От всех конкретных вопросов Вы благополучно ушли):

Сначала научитесь их задавать :)


Красиво! Пример:
На мое замечание, что между двумя объектами может быть несколько связей, и на схеме следовало бы отразить их семантику, последовал странный ответ про "синонимы", и возник диалог:

SergSuper
А можно это поподробней? Мне чего-то не представить как синонимы могут решить проблему связей

_мод
Изделия <= Состав изделий
преобразуем
Изделия-куда (=Изделия) <- Состав изделий -> Изделия-что (=Изделия)

Бред
Что значит "преобразуем" ???
Есть две таблицы в этом примере. Вы предложили использовать синонимы таблиц. Хорошо. Вы используете для одной из таблиц два синонима, а для другой не используете синонимов. Правильно? А что вы получили в результате, что это за схема? Где хранятся эти "связи с помощью синонимов" в метаданных?
Рассмотрите уж этот пример именно с несколькими связями между двумя объектами (в данном случае, правда, все связи "сам с собой"):
Изделие <-Состоит из/Входит в-> Изделие
Изделие <-Используется как комплектующее для/Является комплектующим для-> Изделие
и т.д.

И вот, вместо ответа (укажите, по крайней мере, на ошибки в моем вопросе, ведь именно его я не смог задать правильно - так?), то есть конкретного объяснения именно про разные связи между двумя объектами, последовало:

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

Что за "множественные связи"? Почему их отсутсвие "сильно упрощает модель"? Хотя бы один "прием" приведите. Чтобы все было "ессно в схеме БД".
8 июл 08, 21:03    [5905342]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
Бред
Guest
_мод
Бред
Что сделано-то??? "Универсальная модель" (?), "работающая" (??) с "очень большими ограничениями" (???)

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

Это я вижу, как Вам хочется закрыть все вопросы):
Какие еще ограничения какого-то "объектного подхода" стали видны??? Что можно??? Что нельзя??? ОМД полностью использует все, что есть в "сетевых" (то есть, объектно-ориентированных) МД. Значит она еще более настоящая, правильно?
Речь шла исключительно о пользе (или вреде - это и нужно выяснить) разделения объектов (в том числе в "сетевой МД", если Вам так понятнее) на сущности и события. Так как четкое (системное) разделение объектов и связей между объектами в объектно-ориентированных системах, по сравнению с записеориентированными (реляционными) системами, в которых объекты и связи никак не различаются, дало исключительно положительный результат, почему бы не посмотреть дальше, и не типизировать объекты? Где Вы видите ограничения, если в окружающей действительности, в самом деле, есть сущности и события? И, самое главное, причем здесь сетевая МД или объектная МД или иерархическая МД?
8 июл 08, 21:18    [5905383]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
Бред
Guest
реляционный дебил
_мод
Настоящая "Универсальная модель" - это сетевая МД.


А вот интересно, что же ей тогда помешало найти широкое применение? Может не хватает какого-то небольшого последнего винтика до полного успеха? Или все-таки причины лежат глубже и не хватает последнего гвоздя (в ее гроб)?

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

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

В Ваших рассуждениях несколько неточностей, но все начинается с "как только модель данных повышает уровень абстракции ... становится менее интересной".
В существующей модели принципиально нельзя изменить уровень абстракции, и она не может вдруг стать ни менее, ни более интересной, чем была):
Никто РМД специально никуда не удалял. Кодд стремился к специальному представлению связей между объектами (см. отчет 1969 года), но с алгеброй не срослось): В результате успех заключается в необходимости огромной армии программистов, так как БД максимально удалена от приложения. Конечно, с точки зрения этих программистов - это очень даже большой успех):
Что же делать? Практикам - конечно, использовать РБД, тогда работы хватит всем!
8 июл 08, 21:35    [5905423]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
Бред
Guest
реляционный лох
Бред
"Если отдел состоит из сотрудников", то это, конечно, не иерархия. Это же очевидно - см. что такое иерархия (вот отдел состоящий из подотделов можно назвать иерархией).
...
В чем здесь можно запутаться - ума не приложу):


Совершенно не ясно, как выявить иерархию, т.е. где четкий критерий, что является иерархией, а что просто связями? Например, почему отдел, состоящий из подотделов это иерархия, а если отдел состоит из сотрудников, то иерархии уже нет. Мы употребляем одно слово "состоит". Сотрудники и подотделы это просто сущности (объекты). Где здесь разница и в чем подвох?

Чтобы было более понятно, в чем проблема. Пусть у нас есть 1000 сущностей ну и еще больше связей между ними, например, кто-то где-то работает, кто-то куда-то доставляет, кто-то где-то живет ну и т.д. Как мне, простому реляционному лох, взращенному на книгах Дейта, понять, где здесь иерархия? Я ночами не сплю и мучаюсь, взывая к реляционным духам и богам, но ничего мне не может помочь, так может кто-то здесь спасет меня от страданий.

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