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

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

Скажите, пожалуйста, что именно (какую главу или главы) нужно прочитать в предложенном Вами сборнике статей
http://www.amazon.com/gp/reader/1558605231/ref=sib_fs_top/002-5287797-9204016?ie=UTF8&p=S00L&checkSum=BdpGAS%2BPWnfknbWv0NJM1nJxRKZv06LajVRDhNL%2Brb0%3D#reader-link
что бы получить оветы на обсуждаемые в этой теме вопросы?


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

В статье Стоунбрэйкер убеждает народ по третьему разу на те же грабли не наступать.
11 июл 08, 00:10    [5918824]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
Зл0й
Member

Откуда: Северная Калифорния
Сообщений: 686
Бред
Зл0й
Народ, ну если книжку в лом читать, воспользуйтесь что ли гуглом по ключевым словам cullinane IDMS LSL. Смешно читать. Этот велосипед уже был изобретен, аж в 1975 году. Подозреваю что некоторых участников данного обсуждения тогда еще и "в проекте" не было.


Загляните что ли сюда

О каком "этом велосипеде" Вы говорите??? И почему, например, не в 1965???
"Сюда" все, конечно, давным-давно заглядывали): И на какой вопрос можно найти ответ, заглянув "сюда"?):


Велосипед - IDMS. Все эти ваши идейки с навигацией (у которых ноги растут из работ лауреата премии Тьюринга 1973 г. Чарльза Бахмана) были давно реализованы. Даже декларативный язык высокого уровня для сетевых БД был сделан, типа как SQL в реляционных. Создатели IDMS в 70х годах прошлого века были на 3 шага впереди того что всерьез обсуждается в этом топике. Кончилось все тем что реляционные СУБД победили.
11 июл 08, 00:16    [5918836]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
_мод
Guest
okdoky
2-я таблица пустой, это в смысле граф без ребер? А может наоборот, достаточно второй таблицы?

Нет, д.б. ровно 2 таблицы. Пустая - значит содержит только две ссылки, т.е. ребра не нагружены ничем (на практике не встречается)
11 июл 08, 09:21    [5919412]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
_мод
Guest
Бред
Ну считайте, на здоровье, что я ничего не понимаю и мне нужно ответить конкретно, чтобы дошло)

Ответ был дан (куда уж конкретнее)
11 июл 08, 09:26    [5919434]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
_мод
Guest
Зл0й
Создатели IDMS в 70х годах прошлого века были на 3 шага впереди того что всерьез обсуждается в этом топике.

Не только IDMS. Сравните DBOMP, Total, Adabas, IMS.
Зл0й
Кончилось все тем что реляционные СУБД победили.

Вопрос "почему" здесь уже задавали. Но есть и еще один вопрос: победили навсегда ?
11 июл 08, 09:38    [5919493]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
Зл0й
Кончилось все тем что реляционные СУБД победили.

Но некоторые подсели не на те СУБД? и не могут поверить что они так ошиблись. Хотят персмотреть историю. Но квалификация у них имеет недостатки, чтобы найти реальные аргументы.
В лучшем случае они выписывают из книжек известные недостатки РМД, но пытаются значительно преувеличить их значение. В худьшем выдумывают отсебятину - получается по началу даже смешно. Потом, к сожалению, надоедает.
11 июл 08, 11:24    [5920532]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
реляционный дебил
Guest
Зл0й
Народ, чем изобретать велосипед и переливать из пустого в порожнее почитайте умную книжку:

Readings in Database Systems
Joseph M. Hellerstein and Michael Stonebraker

И 99% вопросов по теме данного топика и смежным темам у вас отпадут.

А хде это чтиво скачать можно? Может найдется д0брый человек, кто на русском имеет эту книжку?
11 июл 08, 13:37    [5921799]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
реляционный дебил
Guest
Бред
Не понятно зачем Вам нужно "выявлять иерархии"? Зачем Вы ищите какой-то подвох?

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

Бред
В иерархии, если исходить от происхождения "иерархии", на что я уже несколько раз обращал внимание, находятся объекты одного рода.

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

Но тогда встает еще более глубокий вопрос, а как определять "род" объектов? Это то же самое, что тип или что-то другое? Например, если я все объекты храню в одной таблице, где одно поле обозначает их род (1 = деталь, 2 = блок и т.д.), то все записи будут одного рода или разного рода?

Бред
Мне то, как раз, все понятно): И свое отношение к "иерархиям", и к ИМД я высказал.

Ну как раз отношение к иерархиям мне абсолютно не инетересно. Я хочу получить более или менее формальное (конструктивное) определение. Чтобы можно было как минимум отличить иерархические связи от просто связей. Сам я уже упомянул как-то, что такой разницы не вижу (трудное реляционное детство), т.е. для меня любая связь это иерархия, но возможно я не прав и вот хочу, чтобы меня кто-то свидомый просвятил.
11 июл 08, 13:54    [5921941]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
Бред
Guest
Зл0й
Бред

Скажите, пожалуйста, что именно (какую главу или главы) нужно прочитать в предложенном Вами сборнике статей
http://www.amazon.com/gp/reader/1558605231/ref=sib_fs_top/002-5287797-9204016?ie=UTF8&p=S00L&checkSum=BdpGAS%2BPWnfknbWv0NJM1nJxRKZv06LajVRDhNL%2Brb0%3D#reader-link
что бы получить оветы на обсуждаемые в этой теме вопросы?


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

В статье Стоунбрэйкер убеждает народ по третьему разу на те же грабли не наступать.

Спасибо! Готов перечитать (так как у меня нет сомнения, что со всеми ключевыми мыслями Стоунбрейкера я знаком, и, в аспекте объяснения причин "загибания" иерархических и сетевых СУБД эти мысли по существу не отличаются от аналогичных мыслей Кодда или Дейта) еще раз статью, о которой Вы сообщите.
С объектными СУБД (классическими, а не на основе ООП, о которых говорит Стоунбрейкер) Стоунбрейкер не достаточно, мягко говоря, знаком. Они обладают несомненными преимуществами перед "Р"СУБД по всем направлениям, и за ними, конечно же, будущее. Поэтому о каких "граблях по третьему разу" (объектные СУБД появились несколько раньше "реляционных") Вы говорите не совсем понятно):
Я и предлагаю конкретизировать на примерах, которые здесь рассматривали, и на вопросах (совершенно конкретных), которые здесь возникали. Но именно это мое сообщение Вы и проигнорировали): Ответьте на эти вопросы пусть не своими словами - пусть словами Стоунбрейкера (я практически на 100% уверен, что Вы не найдете в татьях Стоунбрейкера ответов на эти вопросы):)):
11 июл 08, 14:21    [5922184]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
Бред
Guest
Зл0й
Бред
Зл0й
Народ, ну если книжку в лом читать, воспользуйтесь что ли гуглом по ключевым словам cullinane IDMS LSL. Смешно читать. Этот велосипед уже был изобретен, аж в 1975 году. Подозреваю что некоторых участников данного обсуждения тогда еще и "в проекте" не было.


Загляните что ли сюда

О каком "этом велосипеде" Вы говорите??? И почему, например, не в 1965???
"Сюда" все, конечно, давным-давно заглядывали): И на какой вопрос можно найти ответ, заглянув "сюда"?):


Велосипед - IDMS. Все эти ваши идейки с навигацией (у которых ноги растут из работ лауреата премии Тьюринга 1973 г. Чарльза Бахмана) были давно реализованы. Даже декларативный язык высокого уровня для сетевых БД был сделан, типа как SQL в реляционных. Создатели IDMS в 70х годах прошлого века были на 3 шага впереди того что всерьез обсуждается в этом топике. Кончилось все тем что реляционные СУБД победили.

Ошибаетесь): Ноги, конечно, растут, но почва намного шире и глубже работ Бахмана. Пожалуйста, переходите от политических деклараций к конкретным вопросам и примерам, и Вы быстро убедитесь, как глубоко заблуждаетесь и про "на 3 шага впереди" и про "победили". Или Вы опять про коммерческий результат и борьбу с безработицей среди программистов приложений БД хотите говорить?):
11 июл 08, 14:26    [5922228]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
Бред
Guest
_мод
okdoky
2-я таблица пустой, это в смысле граф без ребер? А может наоборот, достаточно второй таблицы?

Нет, д.б. ровно 2 таблицы. Пустая - значит содержит только две ссылки, т.е. ребра не нагружены ничем (на практике не встречается)

А можно эту таблицу изобразить? Ну чтобы убедиться, что она пустая): Хотя и содержит две ссылки):
11 июл 08, 14:28    [5922248]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
MX -- ALEX
Guest
реляционный дебил
[quot Бред]Не понятно зачем Вам нужно "выявлять иерархии"? Зачем Вы ищите какой-то подвох?

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

Бред
.


В природе их нет

Они в голове человека - печальная необходимость из-за ограниченности моска

Например Путин не может командовать всеми россиянами персонально
но сможет руководить несколькими министрами

Компьютеру иерархия (например : файлов-папок) не нужна -
она нужна человеку
чтоб не рехнуться окончательно

принцип построения иерархий - чисто субьективный - как нам удобнее
натаскивать "это" на базу данных - необязательно
11 июл 08, 14:30    [5922268]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
Бред
Guest
_мод
Бред
Ну считайте, на здоровье, что я ничего не понимаю и мне нужно ответить конкретно, чтобы дошло)

Ответ был дан (куда уж конкретнее)

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

Изделия <= Состав изделий

нет нескольких связей между двумя объектами, то есть Вы изначально ушли от ответа):

Поэтому я еще раз спросил:

Рассмотрите уж этот пример именно с несколькими связями между двумя объектами (в данном случае, правда, все связи "сам с собой"):
Изделие <-Состоит из/Входит в-> Изделие
Изделие <-Используется как комплектующее для/Является комплектующим для-> Изделие
и т.д.

И потом неоднократно повторял свой вопрос. Может Вам нужно объединиться со Стоунбрейкером, чтобы ответить?):
11 июл 08, 14:39    [5922352]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
Бред
Guest
vadiminfo
Зл0й
Кончилось все тем что реляционные СУБД победили.

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

Ну вот, понеслось): Любимое занятие: явные пробелы в своих знаниях (причем не только по БД в целом, но и, что самое главное, по РБД) по-тихому восполняют за чужой счет, а потом вместо "спасибо" говорят "надоедает"): Конечно, учиться не просто. А кто говорил, что просто?):
11 июл 08, 14:44    [5922399]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
Бред
Guest
реляционный дебил
Бред
Не понятно зачем Вам нужно "выявлять иерархии"? Зачем Вы ищите какой-то подвох?

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

Бред
В иерархии, если исходить от происхождения "иерархии", на что я уже несколько раз обращал внимание, находятся объекты одного рода.

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

Но тогда встает еще более глубокий вопрос, а как определять "род" объектов? Это то же самое, что тип или что-то другое? Например, если я все объекты храню в одной таблице, где одно поле обозначает их род (1 = деталь, 2 = блок и т.д.), то все записи будут одного рода или разного рода?

Бред
Мне то, как раз, все понятно): И свое отношение к "иерархиям", и к ИМД я высказал.

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

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

В иерархии, если исходить от происхождения "иерархии", на что я уже несколько раз обращал внимание, находятся объекты одного рода.
Изделие -Состоит из-> Изделие (можно сказать "подизделие" или "сборочная единица" или еще как-то).

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

Для того, чтобы не мучиться, предлагаю Вам реализовать "иерархическую связь" именно как тип. Кроме того, предлагаю "классификатор" реализовать именно как тип (есть строка, есть число, есть дата, а теперь еще будет классификатор). Эти типы будут обрабатываться СУБД совершенно конкретным (характерным для этих типов) образом. У Вас же не вызывает, обычно, сомнений, сделать это поле датой или числом, ну вот так же и здесь будет дело обстоять): Этим (не моим, конечно) предложениям правда лет сорок уже): Но подумайте, раз Вы все равно ночами из-за иерархий не спите):
11 июл 08, 15:03    [5922573]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
_мод
Guest
Бред
А можно эту таблицу изобразить? Ну чтобы убедиться, что она пустая): Хотя и содержит две ссылки):

Конечно можно. Уверен, даже вы сможете.
11 июл 08, 15:20    [5922717]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
_мод
Guest
Бред
Но в приведенном Вами примере
Изделия <= Состав изделий
нет нескольких связей между двумя объектами

Там стрелочка двойная, неужели не заметно. А преобразование в одинарные уже было.
11 июл 08, 15:24    [5922765]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
реляционный дебил
Guest
MX -- ALEX
реляционный дебил
В природе я вижу какой-то феномен, но не могут понять, это действительно иерархия или я просто вчера много выпил.


В природе их нет

Они в голове человека - печальная необходимость из-за ограниченности моска

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

MX -- ALEX
Например Путин не может командовать всеми россиянами персонально
но сможет руководить несколькими министрами

И поэтому нам типа удобно это представить в виде иерархии, так? Вроде так. Но ведь нам не придет в голову представить эту иерархию в обратном виде, когда министр управляет Путиным. Значит, все-таки тут не поллный произвол, а в природе все-таки что-то есть, что заставляет нас сильно ограничивать наш выбор иерархии. Вот я и хочу понять, что это за критерии.

MX -- ALEX
Компьютеру иерархия (например : файлов-папок) не нужна -
она нужна человеку
чтоб не рехнуться окончательно

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

MX -- ALEX
принцип построения иерархий - чисто субьективный - как нам удобнее
натаскивать "это" на базу данных - необязательно

С этим я соглашусь, но произвол в построении иерархии примерно такой же как в выборе структуры отношений. Но с отношениями как-то понятно, поскольку мы говорим, что одна сущность в природе соответствует одному отношению (произвол только в выборе сущностей и их параметров). А в случае иерархии мы говорим о связях, поэтому вопрос в том, какие связи являются иерархическими, а какие просто так. Например, можно предполжить, что связь один-ко-многим это иерархия (один родитель - много детей).
11 июл 08, 17:17    [5923885]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
реляционный дебил
Guest
_мод
реляционный дебил
А вот интересно, что же ей тогда помешало найти широкое применение?

Я отвечу. В сетевых СУБД для связей используется прямой дисковый адрес. Это подразумевает фиксированную длину записи и неизменность ее расположения в файле. Вс это крайне не технологично. В РСУБД связи переложили на PK-FK и индексы. Это сняло многие проблемы, но несколько снизило скорость. Это снижение компенсировали оптимизаторами и общим повышением мощности компов. Поэтому пока не придумают технологичный способ поддержания связей, сетевых СУБД не будет. Так в Oracle связь с nested tables поддерживается индексом (!) (а надо было-бы прямой ссылкой).

Это значит, что проблема всего лишь в реализации хороших связей. А главное, что извне это никак не видно. Например, можно взять те же номера строк в любой РСУБД ну или те же PK-FK и адаптировать их для сетевой модели. Почему тогда так до сих пор не сделали, ведь это просто?
11 июл 08, 17:21    [5923918]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
Бред
Guest
_мод
Бред
А можно эту таблицу изобразить? Ну чтобы убедиться, что она пустая): Хотя и содержит две ссылки):

Конечно можно. Уверен, даже вы сможете.

Ну хорошо, я попытаюсь, а Вы поправьте, пожалуйста.
Таблица (для хранения связей, как мы помним, таблица не должна использоваться)
---------------------
Колонка 1 Колонка 2
---------------------
Null..........Null
---------------------
Так? Вроде таблица "пустая". А где нарисовать "две ссылки", о которых Вы упоминали?
11 июл 08, 21:12    [5924666]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
Зл0й
Member

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

Рассмотрите уж этот пример именно с несколькими связями между двумя объектами (в данном случае, правда, все связи "сам с собой"):
Изделие <-Состоит из/Входит в-> Изделие
Изделие <-Используется как комплектующее для/Является комплектующим для-> Изделие
и т.д.


Это классическая задача в моделировании данных в реляционных СУБД. Называецца "bill of materials". В любом более-менее нормальном учебнике она есть. У Joe Celko помоему все расписано. Перепечатывать в конфу учебник мне лично лень.

Если вы хотите дать возможность пользователям легко и непринужденно задавать отношения и определять предметную область для этого есть специальный инструмент, который по отношению к реляционной СУБД является приложением-клиентом. Лидерами этого рынка в настоящее время являются Microstrategy и Business Objects, в Оракловом мире где "все свое" используют Oracle Discoverer.


В отличие от вашего "объектного навигатора", Рсубд + Business Intelligence platform это не монолит а грамотрно построенная архитектура с четко прописанными уровнями абстракции и формализованными интерфейсами между ними. Поэтому для крупномасштабных задач такие системы гораздо дешевле поддерживать, чем глыбу-монолит.
11 июл 08, 21:41    [5924733]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
Бред
Guest
_мод
Бред
Но в приведенном Вами примере
Изделия <= Состав изделий
нет нескольких связей между двумя объектами

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

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

Изделие составное <-(семантика связи не нужна, так как помещена разработчиком в название фиктивного объекта)- Состав изделия
Изделие-компонента <- Состав изделия

Но ведь один и тот же экземпляр изделия (из "вычислительной модели") может присутствовать и в "таблице" "Изделие составное", и в "таблице" "Изделие-компонента" "невычислительной модели". Следовательно, очевидно, что в этих таблицах ничего не хранится. А все хранится в двух таблицах "вычислительной модели". Правильно? Так где же здесь "упрощение", и в чем оно заключается??? И еще раз спрашиваю: как в метаданных хранится "вычислительная модель" и как в ней отражены две связи между двумя объектами? Что представляет собой "невычислительная модель"? Представление для приложения, или что?
11 июл 08, 21:49    [5924750]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
Бред
Guest
Зл0й
Бред

Рассмотрите уж этот пример именно с несколькими связями между двумя объектами (в данном случае, правда, все связи "сам с собой"):
Изделие <-Состоит из/Входит в-> Изделие
Изделие <-Используется как комплектующее для/Является комплектующим для-> Изделие
и т.д.


Это классическая задача в моделировании данных в реляционных СУБД. Называецца "bill of materials". В любом более-менее нормальном учебнике она есть. У Joe Celko помоему все расписано. Перепечатывать в конфу учебник мне лично лень.

Если вы хотите дать возможность пользователям легко и непринужденно задавать отношения и определять предметную область для этого есть специальный инструмент, который по отношению к реляционной СУБД является приложением-клиентом. Лидерами этого рынка в настоящее время являются Microstrategy и Business Objects, в Оракловом мире где "все свое" используют Oracle Discoverer.


В отличие от вашего "объектного навигатора", Рсубд + Business Intelligence platform это не монолит а грамотрно построенная архитектура с четко прописанными уровнями абстракции и формализованными интерфейсами между ними. Поэтому для крупномасштабных задач такие системы гораздо дешевле поддерживать, чем глыбу-монолит.

Опять ошибаетесь из-за невнимательности): Надеюсь):
Никакая это не классическая задача): "Классическая "задача" это только
Изделие <-Состоит из/Входит в-> Изделие
Чтобы Вы (вместе с _мод) поняли продолжу список:
Изделие <-Состоит из/Входит в-> Изделие
Изделие <-Используется как комплектующее для/Является комплектующим для-> Изделие
Изделие <-Используется для упаковки/Упаковывается в-> Изделие
Изделие <-Использует в качестве аналога/Является аналогом- Изделие
И т.д.
Ну а дальше у Вас опять голые декларации про "грамотно построенную архитектуру", которая:
1) является вынужденным решением из-за недостатков РМД;
2) удлиняет сроки разработки и снижает качество приложений;
3) приводит к постоянному программированию даже самых простых приложений.
И, конечно, у этих безобразных, а не "грамотных" архитектур есть лидеры, кто бы сомневался):
Но это теория, а почему бы Вам не показать на рассматриваемых конкретных примерах, как все делается в "грамотных архитектурах"?): Вот _мод хотя бы старается показать. Может Вы ему поможете?):
11 июл 08, 22:02    [5924772]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
реляционный дебил
А что тогда в природе? Ну в смысле что изначально имеется? Отношения? А потом мы эти отношения представляем в виде иерархии из-за ограниченной по размерам черепной коробки?

В природе круговорот воды. Изначально имеется материя. Отношений в природе до сих пор не было - это была чистая абстакция. Вы представляете отношения в виде иерархий? А что не в виде таблов к примеру, как поступает в настоящее время большинство? У Вас что коробка черепная заментно меньше, чем у них?
Или Вы думает больше, а они просто тупят?
11 июл 08, 22:39    [5924833]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
Бред
Guest
реляционный дебил
_мод
реляционный дебил
А вот интересно, что же ей тогда помешало найти широкое применение?

Я отвечу. В сетевых СУБД для связей используется прямой дисковый адрес. Это подразумевает фиксированную длину записи и неизменность ее расположения в файле. Вс это крайне не технологично. В РСУБД связи переложили на PK-FK и индексы. Это сняло многие проблемы, но несколько снизило скорость. Это снижение компенсировали оптимизаторами и общим повышением мощности компов. Поэтому пока не придумают технологичный способ поддержания связей, сетевых СУБД не будет. Так в Oracle связь с nested tables поддерживается индексом (!) (а надо было-бы прямой ссылкой).

Это значит, что проблема всего лишь в реализации хороших связей. А главное, что извне это никак не видно. Например, можно взять те же номера строк в любой РСУБД ну или те же PK-FK и адаптировать их для сетевой модели. Почему тогда так до сих пор не сделали, ведь это просто?

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