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

Откуда: Обнинск
Сообщений: 4802
SergSuper
Официальное заявление как модератора:

Мне чесно говоря надоел понос от г-на Бреда
Поскольку по-хорошему он не понимает, то я буду теперь тереть все его топики без предупреждения не читая. Как минимум месяца два. Очевидно пострадают и некоторые отвечающие ему

Достало

Т.е. говорит он много, а ни одного стоящего недостака иерархических баз не выявил?
Раньше он пытался найти существенные недостаки РБД в теченнии нескольких РБД, но тоже результат оказался обратно пропоционален количеству, написанного им текста.
Думаю, что два месяца ему на изучение "теории БД", ему маловато буит.
4 авг 08, 11:00    [6022214]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
ModelR
Member

Откуда: Нижний Новгород
Сообщений: 1798
Не знаю как Бред, но я думаю, что

Навигация = следование ссылкам либо обход в порядке адресов в адресном пространстве СУБД (где каждая запись имеет ровно один адрес и каждый адрес соответсвует не более одной записи).
Ссылка = адрес записи.
Т.е навигационная система основана на модели [абстрактной] памяти, а не данных.

Иерархическая система определенным образом ограничивает допустимые ссылки, в частности в данной записи - не более одной ссылки "вверх".

Самое забавное, что широко распостраненная сейчас практика суррогатных ID для каждой таблицы фактически:
1) конструирует адресное пространство, причем GUID гаранитрует уникальность именно в базе в целом, а не только в таблице.
2) вводит навигационный подход в жизнь: от внука (типа строки дкумента) до деда (поставщика) нельзя добраться никак иначе, чем через родителя (документ).
4 авг 08, 12:01    [6022767]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
okdoky
Member

Откуда:
Сообщений: 349
ModelR
Иерархическая система определенным образом ограничивает допустимые ссылки, в частности в данной записи - не более одной ссылки "вверх".
Точнее сказать, реляционная система ограничивает себя ссылками «вверх» при моделировании иерархической системы. В иерархической системе проще использовать ссылки «вниз».
ModelR
Самое забавное, что широко распостраненная сейчас практика суррогатных ID для каждой таблицы фактически:
1) конструирует адресное пространство, причем GUID гаранитрует уникальность именно в базе в целом, а не только в таблице.
2) вводит навигационный подход в жизнь: от внука (типа строки дкумента) до деда (поставщика) нельзя добраться никак иначе, чем через родителя (документ).
Не очень понятен второй пункт, но согласен с мыслью, что для навигации нужно только знать принцип построения суррогатного ключа. То есть нужно знать чем должен отличаться "следующий" ключ или ключ "предок"/"потомок"?
4 авг 08, 12:48    [6023074]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
onstat-
Member

Откуда:
Сообщений: 6941
okdoky
ModelR
Иерархическая система определенным образом ограничивает допустимые ссылки, в частности в данной записи - не более одной ссылки "вверх".
Точнее сказать, реляционная система ограничивает себя ссылками «вверх» при моделировании иерархической системы. В иерархической системе проще использовать ссылки «вниз».


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

okdoky

ModelR
Самое забавное, что широко распостраненная сейчас практика суррогатных ID для каждой таблицы фактически:
1) конструирует адресное пространство, причем GUID гаранитрует уникальность именно в базе в целом, а не только в таблице.
2) вводит навигационный подход в жизнь: от внука (типа строки дкумента) до деда (поставщика) нельзя добраться никак иначе, чем через родителя (документ).
Не очень понятен второй пункт, но согласен с мыслью, что для навигации нужно только знать принцип построения суррогатного ключа. То есть нужно знать чем должен отличаться "следующий" ключ или ключ "предок"/"потомок"?


Давайте не будет смешивать логику и физику, физику я описывал .
наводящий вопрос
И непосредственно само мое понимание и рядом лежащие мои посты.

Сообщение было отредактировано: 4 авг 08, 14:51
4 авг 08, 14:25    [6023693]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
_мод
Guest
ModelR
Самое забавное, что широко распостраненная сейчас практика суррогатных ID для каждой таблицы фактически:
1) конструирует адресное пространство, причем GUID гаранитрует уникальность именно в базе в целом, а не только в таблице.
2) вводит навигационный подход в жизнь: от внука (типа строки дкумента) до деда (поставщика) нельзя добраться никак иначе, чем через родителя (документ).

Вы совершенно правы - это эмуляция СБД с помощью РСУБД.
4 авг 08, 15:40    [6024352]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
onstat-
Member

Откуда:
Сообщений: 6941
_мод
ModelR
Самое забавное, что широко распостраненная сейчас практика суррогатных ID для каждой таблицы фактически:
1) конструирует адресное пространство, причем GUID гаранитрует уникальность именно в базе в целом, а не только в таблице.
2) вводит навигационный подход в жизнь: от внука (типа строки дкумента) до деда (поставщика) нельзя добраться никак иначе, чем через родителя (документ).

Вы совершенно правы - это эмуляция СБД с помощью РСУБД.


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

С этой точки зрения связи в СБД можно назвать грубым хаком через Ж.
Хоть и грубо , но по другому я связи пока назвать не могу,
Аргументов в их пользу я пока не нашел, а те которые были высказаны здесь для меня оказались неубедительны.
4 авг 08, 15:55    [6024456]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
onstat-
Member

Откуда:
Сообщений: 6941
okdoky
ModelR
Иерархическая система определенным образом ограничивает допустимые ссылки, в частности в данной записи - не более одной ссылки "вверх".
Точнее сказать, реляционная система ограничивает себя ссылками «вверх» при моделировании иерархической системы. В иерархической системе проще использовать ссылки «вниз».


Еще одна идея(ИМХО) для описания навигации и семантики для людей разбирающихся в математике лучше чем я.

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

з.ы. Я уже как Петька, понимаю, что будет литра, а цифрами сказать не могу.
;)
4 авг 08, 16:22    [6024632]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
_мод
Guest
onstat-
Я не считаю это эмуляцией, а считаю правильным приемом при создании приложений.

Так эмуляция СБД и есть наиболее правильный принцип проектирования БД для РСУБД :)
т.е. связи СБД эмулируются с помощью сурр. ключей и конст. PK-FK - все элементарно просто
4 авг 08, 17:48    [6025318]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
onstat-
Member

Откуда:
Сообщений: 6941
_мод
onstat-
Я не считаю это эмуляцией, а считаю правильным приемом при создании приложений.

Так эмуляция СБД и есть наиболее правильный принцип проектирования БД для РСУБД :)
т.е. связи СБД эмулируются с помощью сурр. ключей и конст. PK-FK - все элементарно просто


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

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

Мне кажется что когда то давно я слышал одни из законов Мерфи на эту тему,
в инете пока найти не могу.

Я об всем этом уже говорил, только другими словами.
4 авг 08, 18:28    [6025542]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
vadiminfo
Member

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

По сути связи вверх есть интегрирование,

По Лебегу или по Риману?
onstat-

интегрировать можно любую функцю, но есть недиференцируемые функции,

На скока помню, есть ф-ии интегрируемые по Лебегу, но не интегрируемые по Риману

onstat-

на этом можно строить работу оптимизатора который будет выбирать контекст( семантику)


Стройте, стройте. Мож еще пространства Хана-Банаха, общенные ф-ии и проч из Функционального анализа сподобитесь пристроить для типа оптимизатров. А луче решите уранения Новье-Стокса - сможете турбулентность считать. Тада на оптимизаторы можно буит забить: мелковата задача.

Но в этоп топике могли бы сказать луче про какие-нить недостаки ИБД. Ну на крайняк СБД.
Список то недостаков что-то не растет, хотя уже 26 страниц всяких гипотез и "своего видения" про БД понаписано.
4 авг 08, 23:39    [6026118]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
_мод
Guest
onstat-
если бы в СБД была возможность строить констреинты
на связи, тогда можно было бы говорить об эмуляции.

Однако ! Связь и есть очень жесткий (что есть недостаток имхо) констрейнт. СБД недопускает битых ссылок.
5 авг 08, 09:04    [6026542]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
stells2
Member

Откуда: Оклахома Пригород Колымы
Сообщений: 899
Ужос.
Дошли до высоких материй, залезли в математику..
А в чем суть? Какова цель вопроса? Недостаток чего? Относительно чего недостаток?
Можно ли перефразировать – «Недостаток реляционных БД» в контексте рассматриваемого?
Может что-то не понял, но мне кажется, что порой как раз «плоская» модель строгой иерархии более оптимальна. Или, суть вопроса в математике?
-----------------------------------------------------------
а может, стоит прочесть инструкцию?
6 авг 08, 12:18    [6032975]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
stells2
Ужос.
Дошли до высоких материй, залезли в математику..
А в чем суть? Какова цель вопроса? Недостаток чего? Относительно чего недостаток?
Может что-то не понял, но мне кажется, что порой как раз «плоская» модель строгой иерархии более оптимальна. Или, суть вопроса в математике?
-----------------------------------------------------------
а может, стоит прочесть инструкцию?

Суть вопроса в названии темы.
Цели могут быть разные. Например, для диплома или проосто понять историю БД.

stells2

Можно ли перефразировать – «Недостаток реляционных БД» в контексте рассматриваемого?

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

stells2

Может что-то не понял, но мне кажется, что порой как раз «плоская» модель строгой иерархии более оптимальна.


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

stells2

Или, суть вопроса в математике?

Ну и в ней, возможно.
РМД есть математическое обоснование (рел алгебра), а у ИМД с этим типа хуже, если не обращать внимание на свежевыявленные дифференцирование и интегрирование для оптимизаторов.
6 авг 08, 12:43    [6033231]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
сосед. был акцессник
Guest
два дня без интернета - наконец дорвался.
:)


ModelR
Не знаю как Бред, но я думаю, что

Навигация = следование ссылкам либо обход в порядке адресов в адресном пространстве СУБД (где каждая запись имеет ровно один адрес и каждый адрес соответсвует не более одной записи).
Ссылка = адрес записи.
Т.е навигационная система основана на модели [абстрактной] памяти, а не данных.

Спасибо за пригодный к обсуждению вариант понимания навигации и предоставленную возможность пофлеймить.

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

ModelR

Самое забавное, что широко распостраненная сейчас практика суррогатных ID для каждой таблицы фактически:
1) конструирует адресное пространство, причем GUID гаранитрует уникальность именно в базе в целом, а не только в таблице.
2) вводит навигационный подход в жизнь: от внука (типа строки дкумента) до деда (поставщика) нельзя добраться никак иначе, чем через родителя (документ).


1) Конструирует в том смысле, что суррогатный ключ допускает полную замену идентичности в смысле потенциального естественного ключа отношения. В любом случае, если такая интерпретация и оправдана, то реализовываться она будет во внешнем по отношению к хранимым данным алгоритме. И при этом будет сводиться к update-у по ключевому полю без изменения значения (суррогатного) ключа.
Кстати, там, где реализован механизм автоматического формирования нового значения GUID как значения по умолчанию для поля (например – в Акцессе), он «практически гарантирует» уникальность не просто в базе в целом, а на всем множестве возможных хранилищ (баз) данных. Т.е. некую «всемирную» уникальность. Такой способ поддержки уникальности суррогатного ключа явно используется в репликационных схемах. Сами по себе репликационные схемы соотносятся скорее не столько с идеей адресного пространства, сколько с идеей «восстановления» распределенной базы данных.

2) Я не понимаю этого. Связи по суррогатным ключам неотличимы от связей по естественным в смысле «принципа их действия». (Упрощение записи Join - не в счет). В этом смысле нет чего-то специального, что вводится для «детей и их родителей» именно суррогатными ключами по отношению к естественным.
И нет никакой навигации (типа точек, представляющих собой адреса вызовов функций доступа к данным) ни в записи запроса, ни в полученном результате.
Вся навигация такого типа возникает в голове и на стороне писателя приложения, которому необходимо выстроить в использующем коде отношение между «ведущим» и «ведомым» наборами данных получаемых от сервера так, чтобы текущий «ведомый» набор всегда соответствовал активной строке ведущего набора.
Я понимаю так, что именно такого сорта задача могла ранее в этом топике упоминаться как задача «восстановления навигации». Восстановления в том смысле – что реляционная система не навязывает никаких алгоритмических предпочтений в реализации такой согласованности наборов на клиенте и предполагается, что «прикладной программист» либо запрограммирует все необходимое ему в этом отношении либо сам, либо воспользуется средствами, предоставляемыми поставщиками «среды разработки».
«Восстановление» - при этом должно восприниматься как слово несущее отрицательное значение. Подразумевается, что могут быть (или даже может быть есть) системы другого типа, где тема «восстановления навигации» в использующем коде элиминирована полностью или почти полностью.
На мой взгляд, выбор между системами (предположительно) элиминирующими так понимаемое «восстановление навигации», и «не имеющими навигации» системами реляционного типа, в конечном состоянии сведется к выбору между системами с жестко связанными с ними алгоритмическими языками программирования и открытыми по отношению к прикладным языкам. Это в лучшем случае.
В худшем случае это будет вопрос о способах развития пары (данные + алгоритмы) как в отношении дописывания изначально отсутствовавших алгоритмов (повторное использование данных), так и в смысле возможной модификации структур хранимых данным (являющихся результатом внесения исправлений в логическую модель)

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

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

Это вовсе не значит, что с реляционными базами на практике не действуют как с «навигационными» типа «иерархических» - позадачно дублируя как структуры, так и состав хранимых данных, непрерывно порождая повторный ввод одни и тех же наборов данных для разных задач и последующую «проблему выверки и совместного использования в консолидирующей отчетности». Но сами реляционные базы в этом не виноваты.
7 авг 08, 04:22    [6036874]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
Зл0й
Member

Откуда: Северная Калифорния
Сообщений: 686
_мод
onstat-
если бы в СБД была возможность строить констреинты
на связи, тогда можно было бы говорить об эмуляции.

Однако ! Связь и есть очень жесткий (что есть недостаток имхо) констрейнт. СБД недопускает битых ссылок.


Зато допускает циклические ссылки и ссылки приводящие к тому что в зависимости от того КАК мы задаем один и тот же вопрос мы можем получить несколько противоречащих друг другу ответов.
7 авг 08, 04:23    [6036875]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
_мод
Guest
Зл0й
Зато допускает циклические ссылки

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

Это еще почему ?
7 авг 08, 12:23    [6038393]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
Зл0й
Member

Откуда: Северная Калифорния
Сообщений: 686
_мод
Зл0й
Зато допускает циклические ссылки

А какая МД не допускает ? зависит от субд

В Реляционной модели нет понятия ссылки.

_мод

Зл0й
и ссылки приводящие к тому что в зависимости от того КАК мы задаем один и тот же вопрос мы можем получить несколько противоречащих друг другу ответов.

Это еще почему ?

Потому, что в общем случае результат зависит от того каков навигационный "путь" к данным. Совокупность ссылок - тоже данные, грубо говоря. Причем в общем случае не нормализованные, если только не использовать СБД как некий нижний уровень для подобия реляционной МД.
8 авг 08, 01:36    [6042023]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
_мод
Guest
Зл0й
В Реляционной модели нет понятия ссылки.

Что не мешает строить деревья и сети с циклами.
Зл0й
Потому, что в общем случае результат зависит от того каков навигационный "путь" к данным.

С чего бы это ?
Зл0й
Совокупность ссылок - тоже данные, грубо говоря. Причем в общем случае не нормализованные, если только не использовать СБД как некий нижний уровень для подобия реляционной МД.

Ссылки - это псевдоколонки, типа rownum. Нормализация зависит от проектировщика, а не от МД.
РБД на ССУБД построить очень просто - не используя связи. СБД строится на РСУБД тоже не очень сложно с помощью сурр. ключей и связей PK-FK. По сути это одно и то же. А вот канонические РБД - это предмет для курсовиков, в продакшене не применяются.
8 авг 08, 09:14    [6042377]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
onstat-
Member

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

Ссылки - это псевдоколонки, типа rownum. Нормализация зависит от проектировщика, а не от МД.
РБД на ССУБД построить очень просто - не используя связи.


Как только кто-то эти связи( как инструмент работы с данными) начинает использовать, весь контроль целостности ранее возложенный на БД идет лесом, Да?

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

Я по мне, ИМХО, то использование связей в проектах, которые описываются при помощи
РМД нужно запретить как класс.
Вы это тоже поймете, когда ознакомитесь с ИТ менеджментом
и разделами теория массового обслуживания и работа с инцидентами.


_мод

СБД строится на РСУБД тоже не очень сложно с помощью сурр. ключей и связей PK-FK. По сути это одно и то же.



Ну вы блин даете, я с 14 страницы об этом говорю.
8 авг 08, 14:31    [6044780]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
_мод
Guest
onstat-
Как только кто-то эти связи( как инструмент работы с данными) начинает использовать, весь контроль целостности ранее возложенный на БД идет лесом, Да?

Нет, значения ссылок полезно читать, но изменять нельзя.
onstat-
использование связей в проектах, которые описываются при помощи
РМД нужно запретить как класс.

Это как ? Только есстеств. ключи ? Как в учебнике ?
8 авг 08, 15:25    [6045240]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
onstat-
Member

Откуда:
Сообщений: 6941
_мод
onstat-
Как только кто-то эти связи( как инструмент работы с данными) начинает использовать, весь контроль целостности ранее возложенный на БД идет лесом, Да?

Нет, значения ссылок полезно читать, но изменять нельзя.


Стоп, не понял, а кто должен заботится о том что бы ссылки были изначально установлены правильно для вновь добавляемых записей ?
Кем и где описаны эти правила? с помощью каких инструментов это делается?

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


_мод

onstat-
использование связей в проектах, которые описываются при помощи
РМД нужно запретить как класс.

Это как ? Только есстеств. ключи ? Как в учебнике ?


В каком учебнике?
Ну давайте теперь поломаем копья на тему естественные vs сурагатные ключи.

Нет разницы какие ключи, по моему ИМХО важно соблюдение НФ на уровне концептуальных вопросов логики приложения.
И чем ниже номер НФ, те больше вероятность разночтения данных в БД.
8 авг 08, 16:07    [6045620]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
onstat-
Member

Откуда:
Сообщений: 6941
_мод
onstat-
Как только кто-то эти связи( как инструмент работы с данными) начинает использовать, весь контроль целостности ранее возложенный на БД идет лесом, Да?

Нет, значения ссылок полезно читать, но изменять нельзя.


что бы было яснее есть 2 примера.

1. Вы предлагаете выписывать больного из больницы при переводе его из реанимации в травматологию, а потом снова ложить в больницу в травматологию?

2. При переводе ученика из 3-б в 3-а класс его нужно отчислять из школы а затем снова брать?

Соотвественно вопрос как решить эти задачи используя только ссылки и не используя отношения.
исходя из правила что ссылки изменять нельзя.

Если можно использовать отношения, я только ими и буду пользоваться потому как мне это удобнее.

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

Начальство не интересуют инструменты, его интересуют бизнес процессы.
8 авг 08, 16:27    [6045765]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
DBjob
Member

Откуда:
Сообщений: 29
Зл0й
DBjob

Кстати являются ли тесты ТPC общепринятыми метриками при сравнении различных СУБД? Есть ли в области DWH какие то свои тесты?

Для реляционных СУБД - да является. Для объектных метрик нет, потому что нет масштабируемости и соответственно мерить нечего.

Если бы была предложена объектная СУБД, способная в том числе выполнять аналогичные SQL запросы, то насколько она может быть медленне, что бы при этом оставаться интересной для разработчиков (хотя бы в плане evaluation)? Предполагается что с масштабируемостью всё в порядке.
11 авг 08, 00:48    [6050096]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
_мод
Guest
onstat-
Стоп, не понял, а кто должен заботится о том что бы ссылки были изначально установлены правильно для вновь добавляемых записей ?
Кем и где описаны эти правила? с помощью каких инструментов это делается?

Как кто ? ССУБД ессно. Связи описываются на DDL.
onstat-

Ну давайте теперь поломаем копья на тему естественные vs сурагатные ключи.

А не надо ничего ломать, все просто: естественные ключи используются всегда, а суррогатные - только для эмуляция сетевой БД.
11 авг 08, 09:16    [6050474]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
_мод
Guest
onstat-
что бы было яснее есть 2 примера.

В РСУБД вы меняете FK вручную, а в ССУБД ссылки меняются автоматически - вот и вся разница.
11 авг 08, 09:19    [6050480]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 18 19 20 21 22 23 24 25 [26] 27   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить