Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 3 4 5 6 7 [8] 9 10 11 12 .. 27   вперед  Ctrl
 Re: недостатки иерархических баз  [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
vadiminfo
SergSuper
может Вы дадите определение что такое таблица? мне кажется всё дело в терминологии

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

Т.е. если в РСУБД их[таблицы] моно считать представлением отношения то что же Вы спорили с тем, что СУБД оперируют таблицами?

vadiminfo
SergSuper

кстати над экселевскими таблицами тоже можно запросы делать - настроить через ОДБЦ и вперёд

Вы разделяете мнение что Йксель РСУБД? SQL запросы можно делать, наверное, не тока к Йкселю. Более того, он СУБД?
Возможно, кто сподобится написать драйверы и к Ворду.
Есть, например, РОЛАП. Там как бы не РМД, но формат реляционный.

Я разделяю мнение что РСУБД работает с таблицами в любом виде
30 июн 08, 13:19    [5864397]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
okdoky
Member

Откуда:
Сообщений: 349
vadiminfo
многозвенка для Ораклистов - не такое новое понятие
Особенно после того, как они купили Bea? Купили правда недавно, значит новое. Чего-то и где-то не хватило у них для OC4J
vadiminfo
Потому они в курсах чем отличается секрвер приложений от сервера БД и и к какому из этих серверов имеет отншение МД. Это же не Зигзаг чтобы МД в приложения выносить.
Как вы хотите прикрутить ООМД к БД? Это более верхний уровень, даже выше, чем ОРМД :). Тем не менее, это модель и она вполне подразумевает таблицы.
vadiminfo
Оракл поддерживает ООП
Значит вы знаете, что работать с объектами можно только из приложений? Кстати, приложения бывают не только интерактивные :). В БД объекты можно только хранить. А то, что вы называете ОРМД, это, на самом деле, ООМД + РМД.
vadiminfo
okdoky
Это вы серьезно? Если вы не видите таблов даже здесь, это совсем плохо. Начните с ВВЕДЕНИЕ В СИСТЕМЫ УПРАВЛЕНИЯ БАЗАМИ ДАННЫХ. Спрашивайте, не стесняйтесь.
Т.е. Вы нашли там в описании модели СУщность Связь нашли таблицы? А Я тока как и ожидал Сущности и Связи.
Найти за тридцать минут, увы маловато для вас. Хорошо, читайте конкретнее, главу 8. Ищите в Интернете наконец. Не спешите с ответом.
30 июн 08, 13:21    [5864409]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
okdoky
Member

Откуда:
Сообщений: 349
Специально для vadiminfo. Чтобы было понятнее "только" лучше убрать из "В БД объекты можно только хранить". Конечно имеется в виду и искать. Это вытекает. Но главное назначение их (объектов) в другом. Читайте ООМД.
30 июн 08, 13:42    [5864548]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
SergSuper
Т.е. если в РСУБД их[таблицы] моно считать представлением отношения то что же Вы спорили с тем, что СУБД оперируют таблицами?

Я ставил под сомнение что признаком МД являектся наличие таблиц. Т.е. придерживался традиционных подходов. Т.е. считаю, что таблы не обязательны. Но они удобнее в РСУБД. А так это дело реализации. Языкав БД. Мод выдвинул критерием МД Таблы. Я еще не спорил, но выразил скпетическое отношение к этим его достижениям.
Допускаю, что Иерархические СУБД не "оперируют" таблицами. Так как читал, что там для структурирования данных типы записей. Просто формат файла, например.

vadiminfo
Я разделяю мнение, что РСУБД работает с таблицами в любом виде

Не понятен ответ про Йксель. Он РСУБД или нет по Вашему? Слова "работают", "таблицами в любом виде" тоже нуждаются в уточнении.
30 июн 08, 13:47    [5864582]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
SergSuper
Member

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

vadiminfo
Я разделяю мнение, что РСУБД работает с таблицами в любом виде

Не понятен ответ про Йксель. Он РСУБД или нет по Вашему? Слова "работают", "таблицами в любом виде" тоже нуждаются в уточнении.

А уж как нуждается в уточнении термин РСУБД :))

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

"таблица в любом виде" - я имел ввиду что физицеская реализация таблицы(плоский файл, вью, родная таблица, данные Lotus Notes и т.д.) не важна, важно что бы можно было обращаться как к таблице
30 июн 08, 14:05    [5864701]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
_мод
Guest
vadiminfo
В частности, и меня такой вопрос: если предложить двум челам задание: Одному нарисовать таблу, а другому "функцию целого аргумента на отношение" у них по Вашем получится одно и то же?

Попробуйте
vadiminfo
Нарисуйте на ворде любую таблу, а потом выкиньте заголовок.

Номера столбцов останутся, их не выкинешь (и это фундаментальное св-во таблицы)
Кстати про ER. Простой пример: связанные сущности Накладная и Товар. В таком виде цена диаграммы равна 0. Преобразуем в три таблицы: Заголок накладной, Строки накладной ссылка на Товар. Это уже рабочая схема для любой СУБД. Мораль: пока не построили таблицы, МД нет.
30 июн 08, 14:26    [5864836]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
vadiminfo
Member

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

Ну Вам виднее, кто, что покупал. Но удивить нас многозвенками Вам все же не удастся. Поищите что-нить посвежее.

okdoky

Как вы хотите прикрутить ООМД к БД? Это более верхний уровень, даже выше, чем ОРМД :). Тем не менее, это модель и она вполне подразумевает таблицы.

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

okdoky

Значит вы знаете, что работать с объектами можно только из приложений?
Кстати, приложения бывают не только интерактивные :). В БД объекты можно только хранить. А то, что вы называете ОРМД, это, на самом деле, ООМД + РМД.

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



okdoky

Найти за тридцать минут, увы маловато для вас. Хорошо, читайте конкретнее, главу 8. Ищите в Интернете наконец. Не спешите с ответом

Смотря че искать. То что знаю все (кроме Вас) искать не долго. Я на лекции ходил исправно (это далеко не тридцать минут). Хотите Вы или нет, в Модели СУЩНОСТЬ_СВЯЗЬ с момента создания ее Ченом для структурирования исполтьзовались Типы Сущностей и Связей.
Пойдите, в Высшие учебные заведения и переделайте курсы. Впендюрьте туда таблы.
30 июн 08, 14:31    [5864876]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
_мод
Guest
vadiminfo
Достаточно понятия коллекции.

Определение в студию (что за зверь такой)
30 июн 08, 14:34    [5864896]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
vadiminfo
Member

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

Попробуйте

Т.е. Вы уверены что получится одно и то же или у Вас нет никаких предположений о результатах?

_мод

Номера столбцов останутся, их не выкинешь (и это фундаментальное св-во таблицы)
Кстати про ER. Простой пример: связанные сущности Накладная и Товар. В таком виде цена диаграммы равна 0. Преобразуем в три таблицы: Заголок накладной, Строки накладной ссылка на Товар. Это уже рабочая схема для любой СУБД. Мораль: пока не построили таблицы, МД нет.

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

_мод

Определение в студию (что за зверь такой)

Индексированное множество объектов, например. Т.е. для Вас любителя ф-ий: задано множество объетов одного типа, множество индексов и, например, ф-я, которая ставит значения индексу
определенный объект. Вы можете нарисовать большую таблицу, если хотите. А я не стану - и без нее моно, мне все еще кажется, а рисовать ломаеть.
30 июн 08, 14:55    [5865029]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
_мод
Guest
vadiminfo
Т.е. для Вас любителя ф-ий: задано множество объетов одного типа, множество индексов и, например, ф-я, которая ставит значения индексу определенный объект.
Это и есть таблица, чего велосипед выдумывать. Про ER - жду разбора примера - не уходите от ответа.

Сообщение было отредактировано: 30 июн 08, 15:16
30 июн 08, 15:14    [5865134]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
_мод
Т.е. для Вас любителя ф-ий: задано множество объетов одного типа, множество индексов и, например, ф-я, которая ставит значения индексу определенный объект.
Это и есть таблица, чего велосипед выдумывать. Про ER - жду разбора примера - не уходите от ответа.[/quot]
По Вашему определению это таблица? Ваще без колнок? Или их нуно присовать там хде-то рисовать? Массив это таблица?
Это не я ухожу, это Вы не поняли ответа. ER это МД или нет? Када там тока сущности и связи?
Пока Вы еще не преобразовали в таблицы? Про цены 0 или нет позже. Тем более, что для МД цена концептуальной МД не такой и 0, за нее проектировщику могут плптить много больше, чем за таболы в СУБД.
30 июн 08, 15:29    [5865193]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
_мод
Guest
vadiminfo
По Вашему определению это таблица? Ваще без колнок? Или их нуно присовать там хде-то рисовать? Массив это таблица?

Как это без колонок, вы же сказали - отображается на мн-во объектов, значит один столбец типа объект. Одмомерный массив - таблица. Мнгомерные можно преобразовать к одномерному.
vadiminfo
ER это МД или нет?

Нет, разберите мой пример.
30 июн 08, 15:35    [5865220]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
_мод
Как это без колонок, вы же сказали - отображается на мн-во объектов, значит один столбец типа объект. Одмомерный массив - таблица. Мнгомерные можно преобразовать к одномерному.

С какой стати "значит столбец"? Могу эти объекты изобразить и не в виде колонки. Через запятую, например. Да мало ли?

vadiminfo
ER это МД или нет?

Нет, разберите мой пример.[/quot]
ER - модель?
А че тда разбирать? По моии это МД и цена которой не ноль. Она позволет увидить общий смыл данных. Концептуальная. Одно из главнейших назначений МД упростить проектирование. На основе этой МД моно налабать логическую РМД с отношеними. Выбран на этом этапе тока тип СУБД- РСУБД, а не иерархическая, к примеру. Там нормализовать и все такое. ПОтом Физическую с таблами - это реализация. Там уже для конуретнеой СУБД. Денормализовать с целью приложения БД в целом. Таков был до Ваших новшеств типой подход.
30 июн 08, 15:48    [5865301]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
_мод
Guest
vadiminfo
Да мало ли?

В том и дело что вариантов мало.
vadiminfo
Она позволет увидить общий смыл данных.

Цена этому общему смыслу ровно 0. И последовательность проектирования другая: сначала таблицы и связи, потом выбор СУБД и реализация связей. Так-то логичнее.
30 июн 08, 16:03    [5865405]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
vadiminfo
Member

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

Цена этому общему смыслу ровно 0. И последовательность проектирования другая: сначала таблицы и связи, потом выбор СУБД и реализация связей. Так-то логичнее.

У начинающих проектировщиков, наверное, такая. Для телефонных справочников, тоже.
Вашим конкурентам, я думаю, повезло, если они, конечно, тоже не экономят на специалистах.
30 июн 08, 20:07    [5866531]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
Бред
Guest
_мод
Бред
Где не нужны?

В БД.
Бред
Алгебра необходима в отсутствие связей.

Алгебра необходима всегда.
Где не нужны? Обратите внимание на "без разницы". Если бы не проклятые "истинные связи" (по Дейту), то можно было бы сказать - не нужны.
Бред

И последнее: кто Вас научил, что в результате операции над "классами" нельзя получить новый "класс"?

Пример в студию (еж+уж=?)
Бред

Который, кстати говоря, как и множество взаимосвязанных n "классов" всегда можно представить в виде "таблы".

Я об этом и твержу: информация в БД всегда представлена таблицами и ничем иным

Жаль, что Вы уходите от Вами же инициированного вопроса. Ну не беда): Итак.
1) В какой именно БД. в "реляционной" для "истинных связей" (в терминологии Дейта) создаются отдельные отношения. Да, конечно, отдельные, а не специализированные. Специализировать не удалось, так как не понятно было как реализовать специализацию в алгебре.
2) Алгебра абсолютна не нужна никогда. Это просто медицинский факт - ИС на основе БД во всех областях работали, а во многих областях продолжают работать, без алгебры. Я уже говорил, что долго искал подходящую область, где алгебра была бы полезна, и что-то удалось найти (об этом примере я написал).
3) еж+уж=ежеуж в чем здесь вопрос? А вот в РБД еж+уж= чему???
4) про "универсальность" таблиц я не спорю, но Ваше утверждение (или предположение?), что связи между сущностями (в том числе "истинные связи") представляются во всех типах БД ни в коем случае не с помощью таблиц, выглядит несколько не убедительно. Если бы Вы это пояснили, было бы здорово):
30 июн 08, 21:16    [5866682]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
_мод
Guest
Бред

Вы меня конечно извините, но вы ничего не поняли. Могу только посоветовать перечитать топик сначала. Увы :(
1 июл 08, 09:10    [5867557]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
Бред
Guest
_мод
Бред

Вы меня конечно извините, но вы ничего не поняли. Могу только посоветовать перечитать топик сначала. Увы :(

Конечно извиняю! Конечно перечитал, причем Ваши сообщения по несколько раз. Напомню Ваши утверждения:
1. Все СУБД оперируют только таблицами.
2. Способ связи между таблицами определяет модель данных. Есть связь [интересный способ - Бред] - сетевая, нет связи [тоже интересный - Бред] - реляционная.
3. Отношение - это множество кортежей, а таблица - функция, определенная на множестве кортежей.
Теперь, если не рассматривать вопросы, от которых Вы так изящно ушли, сославшись на то, что Вас не понимают, то из Ваших утверждений 1 и 3 следует, что все СУБД - реляционные. "Бедный" автор темы: только получил список недостатков "иерархических баз", как выяснилось, что это список недостатков реляционных баз):
Прав оказался SergSuper, как всегда: Вам нужно было быть намного серьезнее подготовленным, чтобы обсуждать вопросы БД):
1 июл 08, 19:31    [5872161]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
_мод
Guest
Бред

1. Все СУБД оперируют только таблицами.
2. Способ связи между таблицами определяет модель данных. Есть связь [интересный способ - Бред] - сетевая, нет связи [тоже интересный - Бред] - реляционная.
3. Отношение - это множество кортежей, а таблица - функция, определенная на множестве кортежей.
из Ваших утверждений 1 и 3 следует, что все СУБД - реляционные.

Нет. Из 2 следует что универсальная МД - сетевая, а И и Р ее частные случаи. Конкретная СУБД может реализовать несколько разных МД одновременно. (вы невнимательно читаете).
У МД не м.б. недостатков - МД либо подходит либо нет, недостатки м.б. только у конкретной СУБД.
зы что мне нужно - не вам решать
ззы есть вопросы - спрашивайте - только без глупостей типа ссылок на Кодда и Дейта
2 июл 08, 10:44    [5873836]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
розовый слон...
Guest
недостатки иерархических
Может, кто ткнёт носом в описание недостатков иерархических баз? Поиск по форуму и по инету дал мало вразумительного.
Только не недостатки Cashe и MUMPS, а иерархических баз, как класса.


Говоря об иерархиях и иерархическом модели надо иметь в виду, что есть два принципиально разных способа организации иерархий:
  • 1. непосредственный (по значению) и
  • 2. опосредованный (по ссылке или с помощью связи).

    Например, если глава включается в книгу, то на XML это можно выразить так:

    <!-- Непосредснвтенно или по значению -->
    <book>
      <chapter>...</chapter>
    </book>
    
    <!-- Опосредованно или по ссылке или с помощью связей -->
    <book id="b1">...</book>
    <chapter parent="b1">...</chapter>
    

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

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

    В РМ нет вообще иерархии хранения и нет вообще связей и в этом смысле это не совсем модель данных, а скорее пред-модель, которая позволяет описать любую другую модель. Иерархию хранения (способ 1) объявили вселенским злом и полностью исключили из РМ. Связи тоже решили не включать, поскольку тут не было (да и до сих пор нет) единства мнений. Вместо этого в РМ вложили мощную алгебру для манипулирования множествами значений и решили забить ее все остальное. На вопрос что это за значения и что это за множества решили не отвечать, т.е. исключили из области моделировании (хотя это есть собственно моделирование данных). В результате РМ это некий тулбокс или ведро с гайками и болтами, используя которые подготовленный специалист может создать любое нужное устройство (даже не относящееся к моделированию данных). Модель данных это прежде всего способ организации, а в РМ этого нет (от него сознательно отказались). Связи в РМ можно моделировать с помощью join или еще немного автоматизировать с помощью связки ПК-ФК. Это крайне трудоемко, неудобно, неестественно, но зато близко к машинной реализации и очень общий способ, подходящий для многих других вещей.
  • 2 июл 08, 13:10    [5875148]     Ответить | Цитировать Сообщить модератору
     Re: недостатки иерархических баз  [new]
    недостатки иерархических
    Guest
    розовый слон - позвольте не согласиться.
    Из той ссылки, которую я привёл на документацию IMS (logical references chapter) можно видеть, что IMS реализация позволяет оба способа организации.
    Наложив на это следующую главу (secondary indexes) ситуация становиться всё интереснее и интереснее.
    2 июл 08, 13:18    [5875224]     Ответить | Цитировать Сообщить модератору
     Re: недостатки иерархических баз  [new]
    Бред
    Guest
    _мод
    Бред

    1. Все СУБД оперируют только таблицами.
    2. Способ связи между таблицами определяет модель данных. Есть связь [интересный способ - Бред] - сетевая, нет связи [тоже интересный - Бред] - реляционная.
    3. Отношение - это множество кортежей, а таблица - функция, определенная на множестве кортежей.
    из Ваших утверждений 1 и 3 следует, что все СУБД - реляционные.

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

    Я предельно внимательно читаю. И не считаю Кодда и Дейта глупцами. Итак.
    1. То, что "СУБД может реализовать несколько разных моделей данных - азбучная истина. Когда я это оспаривал?
    2. Из 2 абсолютно не следует какая именно МД универсальная (или более универсальная). Здесь Вам придется, если Вы не будете уходить от существа вопроса, основательно поспорить с "Вкладом Кодда в великий спор". Отсутствие связей универсальнее - так считают Кодд и Дейт. В самом деле - какой смысл в связях между бессмысленными (математическими) объектами (что отношениями, что таблицами)??? Вы упорно уходите от вопроса о связях. Что такое связь? Между чем связь? Как представить "истинную связь" (по Дейту) в любой МД?
    А вот из 1 и 3 явно следует, что все СУБД - реляционные):
    3. Что не мне решать? К чему эта ремарка? Я всего лишь напомнил высказывание SergSuper):
    4. Спрашивал неоднократно - Вы не хотите отвечать. А ссылки совершенно конкретные, с указанием страницы. Если бы Вы еще и рассказали какие именно глупости написаны на этой странице, было бы совсем хорошо):
    2 июл 08, 13:33    [5875360]     Ответить | Цитировать Сообщить модератору
     Re: недостатки иерархических баз  [new]
    _мод
    Guest
    Бред
    Из 2 абсолютно не следует какая именно МД универсальная (или более универсальная).Отсутствие связей универсальнее - так считают Кодд и Дейт. В самом деле - какой смысл в связях между бессмысленными (математическими) объектами (что отношениями, что таблицами)??? Вы упорно уходите от вопроса о связях. Что такое связь? Между чем связь? Как представить "истинную связь" (по Дейту) в любой МД?

    Я же просил без глупостей - мне глубоко все равно что там кто считает. Очевидно, что МД с таблицами без связей всего лишь частный случай МД со связями, т.е. сетевой. Связь ессно между двумя таблицами, всегда вида 1:N, т.е. одной строке таб1 поставлено в соотв. N строк таб2. Механизм зависит от СУБД. Соответсвие устанавливается "по построению", т.е. в процессе создания строк таб2. Связь представляется с помощью DDL ессно - зависит от СУБД.
    2 июл 08, 14:21    [5875865]     Ответить | Цитировать Сообщить модератору
     Re: недостатки иерархических баз  [new]
    Бред
    Guest
    _мод
    Бред
    Из 2 абсолютно не следует какая именно МД универсальная (или более универсальная).Отсутствие связей универсальнее - так считают Кодд и Дейт. В самом деле - какой смысл в связях между бессмысленными (математическими) объектами (что отношениями, что таблицами)??? Вы упорно уходите от вопроса о связях. Что такое связь? Между чем связь? Как представить "истинную связь" (по Дейту) в любой МД?

    Я же просил без глупостей - мне глубоко все равно что там кто считает. Очевидно, что МД с таблицами без связей всего лишь частный случай МД со связями, т.е. сетевой. Связь ессно между двумя таблицами, всегда вида 1:N, т.е. одной строке таб1 поставлено в соотв. N строк таб2. Механизм зависит от СУБД. Соответсвие устанавливается "по построению", т.е. в процессе создания строк таб2. Связь представляется с помощью DDL ессно - зависит от СУБД.

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

    Точнее - сущности моделируются таблицами. Пример приводил: сущность Накладная, таблиц две (кстати связь иерархическая)
    Бред
    используя более понятный, как Вам кажется, термин "таблица".

    Более формальный
    Бред
    таблица представляет объект, а связь между объектами - это не объект, и, следовательно, не таблица.

    Ессно нет
    Бред

    Далее, если, у связи вдруг обнаруживаются собственные свойства, то это никакая не связь, а объект, и мы создадим для него соответствующую таблицу.

    Да
    Бред
    Еще один важный вывод, который я делаю из Ваших рассуждений: сущность не следует рассматривать как свойство другой сущности

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

    Принцип простой - макс декларативности, остальное как получится
    2 июл 08, 18:00    [5878002]     Ответить | Цитировать Сообщить модератору
    Топик располагается на нескольких страницах: Ctrl  назад   1 .. 3 4 5 6 7 [8] 9 10 11 12 .. 27   вперед  Ctrl
    Все форумы / Сравнение СУБД Ответить