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

Да я не про вас :)
8 дек 06, 14:03    [3510429]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
mir
Member

Откуда: Томск
Сообщений: 1027
Александр Савинов
>>А чем не устривают отношения PK-FK?
С практической точки зрения всем устраивают за исключением некоторых неудобств:

- Я бы не вставлял отдельно все колонки из ключа в ссылающуюся таблицу, а обозначал бы весь ключ одним именем колонки. На физическом уровне это ничего не меняет, но работать существенно легче.

А что, определить суррогатный ключ из единственного атрибута уже религия запрещает?
Александр Савинов
- Я бы реализовал механизм доступа по ключу без использования join.
Например, account.person.address.street, где два перехода по ключам. Не понимаю, почему нельзя это сделать в запросах. Здесь account это текущая запись, person и address это имена колонок, которые содержат ключ другой записи (который может иметь структуру). Сейчас же надо писать сложный запрос для нескольких таблиц.
Идея понятна. Но практическая польза под большим вопросом.
Скажем, в SQL я напишу в области FROM выражение T1 NATURAL JOIN T2 NATURAL JOIN T3. После этого я в куче мест запроса могу весьма кратко ссылаться на имена полей всех трех таблиц. В вашем гипотетическом синтаксисе мне не придется писать этот JOIN, зато запись имен полей будет ужасно громоздкой, вроде:
T1ForeignKey.T2ForeignKey1ForeignKey2.T3HereComesTheField
.
Ежели я в запросе несколько раз буду вынужден вместо имени поля писать эдакий баян, я прокляну такой синтаксис. А ведь нередки соединения и десятка таблиц. Как же буду выглядеть обращения к атрибутам? Бррр…

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

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

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

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

Уж простите великодушно, сначала-то я хотел разобрать этот нонсенс по полочкам, но приустал уже, поэтому лучше приведу классическую цитату из «Собачьего сердца»:
- Вы стоите на самой низшей ступени развития, - перекричал Филипп Филиппович, - вы еще только формирующееся, слабое в умственном отношении существо, все ваши поступки чисто звериные, и вы в присутствии двух людей с университетским образованием позволяете себе с развязностью совершенно невыносимой подавать какие-то советы космического масштаба и космической же глупости о том, как все поделить... А в то же время вы наглотались зубного порошку...
- Третьего дня, - подтвердил Борменталь.
- Ну вот-с, - гремел Филипп Филиппович, - зарубите себе на носу, кстати, почему вы стерли с него цинковую мазь? - Что вам нужно молчать и слушать, что вам говорят.
8 дек 06, 14:10    [3510495]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
Александр Савинов
Member

Откуда:
Сообщений: 173
shuklin
!
Другими словами, если к обьекту получать доступ по другой ссылке(индексу)
то это свойство будет недоступно.

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

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

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

Но попробовать сделать много ID конечно можно. Идея сама по себе вполне имеет смысл. Нужна очень строгая дисциплина и правила игры, чтобы никто из участников в обиде не остался.
8 дек 06, 14:20    [3510567]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
мод
Guest
mir
А что, определить суррогатный ключ из единственного атрибута уже религия запрещает?

Все так и делают. Но если это надо делать для каждой таблицы, то пусть СУБД это делает сама, у нее всяко выйдет лучше.
8 дек 06, 14:22    [3510593]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
!
Guest
shuklin
!
Тогда я абсолюнто не понимаю почему у Вас равенство != идентичность.

Потому что имея на руках два неравных ID и разадресовав их в одном контексте (адресном пространсве) можно попасть на один и тот же экземпляр. В этом случае ссылки не равны, а указываемые ими экземпляры идентичны - тоесть это один и тот же экземпляр.

Так же возможно имея на руках два неравных ID разадресовать их на два разных но равных по значению экземпляра.

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

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

Под равенством - обычное равенство по значению.


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

Как собираетесь отличать разные обьекты с однинаковыми атрибутами.
При том что ссылки у них не равны.
Обьекты разные, По атрибутам равны, по ссылкам не равны.
Так Равны или не равны.
Почитай предидущие 3 страницы, этот аспект подробно рассматривался.

Вам не кажется что Нужно вводить PK. Который как мы уже выяснили
полностью ссылку заменяет.

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

Вопрос на засыпку:
Какие виды(типы) констреинтов сушествуют в Cerebrum ?
8 дек 06, 14:54    [3510886]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
!
Guest
мод
mir
А что, определить суррогатный ключ из единственного атрибута уже религия запрещает?

Все так и делают. Но если это надо делать для каждой таблицы, то пусть СУБД это делает сама, у нее всяко выйдет лучше.


identity (M$ $QL)
serial ( informix)
sequence + trigger (oracle)
8 дек 06, 15:12    [3511049]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
!
Guest
mir

Уж простите великодушно, сначала-то я хотел разобрать этот нонсенс по полочкам, но приустал уже, поэтому лучше приведу классическую цитату из «Собачьего сердца»:
- Вы стоите на самой низшей ступени развития, - перекричал Филипп Филиппович, - вы еще только формирующееся, слабое в умственном отношении существо, все ваши поступки чисто звериные, и вы в присутствии двух людей с университетским образованием позволяете себе с развязностью совершенно невыносимой подавать какие-то советы космического масштаба и космической же глупости о том, как все поделить... А в то же время вы наглотались зубного порошку...
- Третьего дня, - подтвердил Борменталь.
- Ну вот-с, - гремел Филипп Филиппович, - зарубите себе на носу, кстати, почему вы стерли с него цинковую мазь? - Что вам нужно молчать и слушать, что вам говорят.


+100
8 дек 06, 15:16    [3511093]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
мод
Guest
!

identity (M$ $QL)
serial ( informix)
sequence + trigger (oracle)

Это-то понятно, но по полной программе должна поддерживаться ссылочная целостность и это не должно быть поле в записи (псевдостолбец). И еще хотелось бы отличать типы.
8 дек 06, 15:19    [3511126]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
!
Guest
мод
!

identity (M$ $QL)
serial ( informix)
sequence + trigger (oracle)

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


Речь шла о сурагатном ключе.

Не нужно вводить путаницу с определением нового термина псевдостолбец
по теме топика , это внесет еще большую путаницу.
8 дек 06, 15:24    [3511173]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
mir
Member

Откуда: Томск
Сообщений: 1027
мод
mir
А что, определить суррогатный ключ из единственного атрибута уже религия запрещает?

Все так и делают. Но если это надо делать для каждой таблицы, то пусть СУБД это делает сама, у нее всяко выйдет лучше.
Дело в том, что это вовсе не надо делать для каждой таблицы. Часто естественных ключей достаточно, причем часто они уже из одного атрибута. Чего тут добавлять-то? Да и в случае составного ПК, если на него нет ссылок, зачем огород городить?
Поэтому именно надо явно указывать, где и чего.
8 дек 06, 15:54    [3511396]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
MX -- ALEX
Guest
!
mir

Уж простите великодушно, сначала-то я хотел разобрать этот нонсенс по полочкам, но приустал уже, поэтому лучше приведу классическую цитату из «Собачьего сердца»:
- Вы стоите на самой низшей ступени развития, - перекричал Филипп Филиппович, - вы еще только формирующееся, слабое в умственном отношении существо, все ваши поступки чисто звериные, и вы в присутствии двух людей с университетским образованием позволяете себе с развязностью совершенно невыносимой подавать какие-то советы космического масштаба и космической же глупости о том, как все поделить... А в то же время вы наглотались зубного порошку...
- Третьего дня, - подтвердил Борменталь.
- Ну вот-с, - гремел Филипп Филиппович, - зарубите себе на носу, кстати, почему вы стерли с него цинковую мазь? - Что вам нужно молчать и слушать, что вам говорят.


+100


жалка сабачку ...

а доктор - вредитель и враг народа
8 дек 06, 16:02    [3511470]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
shuklin
Member

Откуда: Харьков
Сообщений: 799
Александр Савинов

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

Я по началу тоже так считал. Но практика расставила свои точки. Пользоваться БД с синонимией/омонимией ID на практике легче. Хотябы потому, что возникает возможность сделать объектный VIEW. В случае со стандартной трактовкой уникальности ID как сделать VIEW я не знаю.

Александр Савинов

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

Да. Это все имеет место быть в разработанной сетевой СУБД и находит порой свою прагматическую нишу. Я на практике не ощутил больших неудобств. Разве что паттерн flyweight при доступе к тем объектам, которые требуют знания своего ID несколько загромождает синтаксис. Синтаксис можно упростить перепоручив определение ID "чуду" StackTrace но это уже нагрузка на ядро. Без Transparent Proxy надежную реализацию я не вижу.


Александр Савинов

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


С точки зрения моего ИМХО реализация действительно удобнее. И если ядро поддерживает этот режим это еще не значит что его нужно использовать всегда. Как раз в 90% паттернов я его не использую.

- он очень удобен в объектных view
- в аттрибутах.

на другие случаи я пока не наткнулся.
8 дек 06, 16:13    [3511546]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
ModelR
Member

Откуда: Нижний Новгород
Сообщений: 1798
Александр Савинов
ModelR
Александр Савинов
Все зависит от функциональности ссылки. Если реализовать метод Next, то будет последовательный доступ. Можно реализовать сборщик мусора, проверку полномочий, кэширование или др. нужные функции. [...]А далее все зависит от разработчика ссылки.
Кхм.., а есть что-то в этом мире что НЕ ссылка?


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


2. [...]доступ объекта по его свойствам это поиск
Действительно в терминах нужно строже. ИМХО доступ - операция над памятью с результатом содержание памяти. Доступ может быть либо по адресу (ссылке) либо последовательный без использования ссылок, либо еще какой.
Поиск очевидно более сложная процедура, использующая доступ. Вход - некие поисковые критерии или ссылки на эти критерии, выход - набор объектов или ссылок на объекты, этим критериям удовлетворяющие.
Посему доступ - не поиск.
8 дек 06, 16:17    [3511574]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
Александр Савинов
Member

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

identity (M$ $QL)
serial ( informix)
sequence + trigger (oracle)

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


Речь шла о сурагатном ключе.

Не, речь не об этом шла. Речь шла о недостатках PK-FK. Один недостаток в следующем.

Как это реализовано в РМД:

table Account {
  ...
  FK String name;
  FK Date dob;
  ...
}

table Person {
  PK String name;
  PK Date dob;
  int age;
  ...
}

Т.е. запись счета ссылается на запись о владельце путем явного повторения полей ключа. Далее, чтобы получить доступ, надо использовать join.

А вот что хотелось бы иметь:

table Account {
  ...
  Person owner; // Для двух полей <name, dob> из Person(identity) одно имя
  ...
}

table Person {
  identity { // Эти поля определяют формат ссылок из других таблиц
    String name;
    Date dob;
  }
  entity { // Только эти поля хранятся в таблице
    int age;
    ...
  }
}

Во-первых, ключ отделен от остальных полей и, вообще говоря, не должен храниться в таблице (хранятся только поля из группы entity). Во-второых, доступ осуществляется без join, просто указанием цепочки полей (как в ООП). Очевидно, что так удобнее, например, account.owner.age, и все. Либо так: account.owner.name.
8 дек 06, 16:21    [3511600]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
MX -- ALEX
Guest
Александр Савинов

.....................
Во-первых, ключ отделен от остальных полей и, вообще говоря, не должен храниться в таблице (хранятся только поля из группы entity). Во-второых, доступ осуществляется без join, просто указанием цепочки полей (как в ООП). Очевидно, что так удобнее, например, account.owner.age, и все. Либо так: account.owner.name.


примерно так и хранятся данные в CACHE и всех базах на основе стандарта MUMPS
и точно так осуществляется доступ
уже много лет

и поэтому - в частности - на них все дружно матерятся на этом форуме
8 дек 06, 16:31    [3511643]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
Александр Савинов


А вот что хотелось бы иметь:

table Account {
  ...
  Person owner; // Для двух полей <name, dob> из Person(identity) одно имя
  ...
}

table Person {
  identity { // Эти поля определяют формат ссылок из других таблиц
    String name;
    Date dob;
  }
  entity { // Только эти поля хранятся в таблице
    int age;
    ...
  }
}

Во-первых, ключ отделен от остальных полей и, вообще говоря, не должен храниться в таблице (хранятся только поля из группы entity). Во-второых, доступ осуществляется без join, просто указанием цепочки полей (как в ООП). Очевидно, что так удобнее, например, account.owner.age, и все. Либо так: account.owner.name.

а как мы тогда по персоне найдём его счета?
8 дек 06, 16:45    [3511735]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
nooo
Guest
ModelR
Поиск очевидно более сложная процедура, использующая доступ.

Ну, допустим, поиск у автора происходит в контексте "обычных ссылок", а доступ - в виртуальном адресном пространстве неизвестной природы. Поэтому совершенно не очевидно сложная, и очевидно не использующая :)
8 дек 06, 16:46    [3511749]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
Господа, если кому-то очень хочется на что-то пожаловаться - есть кнопка Сообщить модератору
Не надо засорять своим плачем обсуждение технических вопросов
8 дек 06, 16:49    [3511771]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
U-gene
Member

Откуда: Москва. Россия
Сообщений: 1576
В последний год при прочтении тутошних топиков меня не покидает оЩуЩение дежавю :)

Александр, во-первых, в РМД ничего не реализовано. Вы же не говорите "в арифметке реализована операция сложения"? Реализовано может быть в системе.

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

Поиск недостатков в паре PK-FK ИМХО напоминает поиск недостаков в операции сравнения пары значений.... ну где то около того :)

В-третьих Вы бы почитали тутошние баталии, которые велись с ЧАЛом с Shulin'ым и т.п. воинствующими противниками РМД. Там очень много чего обсуждалось и если внимательно вчитаться в эти обсуждения то многие вопросы и претензии к РМД отпадут сами собой. Люди порой (я бы сказал - часто) воспринимают РМД через призму используемых систем :).

PS Каким то образом (сам не понимаю каким) вы у меня с Дармштадтом ассоциируетесь....:) ...или я ошибаюсь?
8 дек 06, 16:59    [3511837]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
ModelR
Member

Откуда: Нижний Новгород
Сообщений: 1798
Нет идеала. Зато одно поле запросто участвует в нескольких ФК.
table Account {
  ...
  FK1, FK2 String name;
  FK1 Date dob;
  FK2 Interger nmbr;
}

table Person {
  PK String name;
  PK Date dob;
  int age;
  ...
}
table T{
  PK String name;
  PK Interger nmbr;
  int fld ;}
И сократиь код введя обозначение Account.FK1.age вполне можно.
Т.е. оперируя со всеми данными как равными мы получаем максимальную гибкость.
8 дек 06, 17:04    [3511878]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
Александр Савинов
Member

Откуда:
Сообщений: 173
SergSuper
Александр Савинов


А вот что хотелось бы иметь:

table Account {
  ...
  Person owner; // Для двух полей <name, dob> из Person(identity) одно имя
  ...
}

table Person {
  identity { // Эти поля определяют формат ссылок из других таблиц
    String name;
    Date dob;
  }
  entity { // Только эти поля хранятся в таблице
    int age;
    ...
  }
}

Во-первых, ключ отделен от остальных полей и, вообще говоря, не должен храниться в таблице (хранятся только поля из группы entity). Во-второых, доступ осуществляется без join, просто указанием цепочки полей (как в ООП). Очевидно, что так удобнее, например, account.owner.age, и все. Либо так: account.owner.name.

а как мы тогда по персоне найдём его счета?

Это уже совершенно другой вопрос и есть разные подходы. Мне нравится следующий (неформально). Есть операция инвертирования. В результате, если есть ссылка, скажем, из счета на владельца, то можно путем инверсии получить множество счетов данного владельца. Если использовать фигурные скобки для инвертирования полей, которые в них заключены, то делается это так:
person.{Account.owner}
Естественно, можно составлять более длинные пути, например:
account.owner.address.{Person.address}.age
Здесь мы идем от счета, находим адрес владельца, далее (в фигурных скобках) находим всех людей по этому адресу и возвращаем их возраст. Т.е. получаем коллекцию возврастов (например, чтобы получить средний возраст проживающих вместе с владельцем счета).

Более формально, если идем в направлении ссылки, то это проекция. Если обратно (инверсия), то это де-проекция. Вся структура будет упорядоченным множеством. Все это будет аналогично обычному многомерному пространству с иерархией.
8 дек 06, 17:06    [3511899]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
Александр Савинов
Member

Откуда:
Сообщений: 173
ModelR
Нет идеала. Зато одно поле запросто участвует в нескольких ФК.
table Account {
  ...
  FK1, FK2 String name;
  FK1 Date dob;
  FK2 Interger nmbr;
}

table Person {
  PK String name;
  PK Date dob;
  int age;
  ...
}
table T{
  PK String name;
  PK Interger nmbr;
  int fld ;}

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

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

ModelR
И сократиь код введя обозначение Account.FK1.age вполне можно.

И я так думаю. Более того, я не понимаю, почему так до сих пор не сделано. На самом деле причина есть и она лежит глубже. Во-первых, это будет отход от фундаментальной традиции реляционного подхода, а изменение традиций и даже покушение на них не только трудно, но и опасно (могут обматерить). Это ведь явное движение в сторону ОО - а это грех и ересь. В РМД изначально в основе всех связей лежала join, а доступ по полям наружает эту традицию. Еще одна причина в том, что как это не странно звучит, но PK-FK в РМД это ведь НЕ средство доступа, а ограничение целостности, а это не одно и то же.
8 дек 06, 17:23    [3512051]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
!
Guest
Александр Савинов

Не, речь не об этом шла. Речь шла о недостатках PK-FK. Один недостаток в следующем.


Я попрошу вас не передергивать и не изменять контекст
речь шла о:

mir
Александр Савинов


!
>>А чем не устривают отношения PK-FK?


С практической точки зрения всем устраивают за исключением некоторых неудобств:

- Я бы не вставлял отдельно все колонки из ключа в ссылающуюся таблицу,
а обозначал бы весь ключ одним именем колонки. На физическом уровне это ничего не меняет, но работать существенно легче.

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


Я контекст определил однозначно :
Вас все устраивает в PK-FK , то что не устраивает,
великолепно реализуется сурагантым ключем без дополнительных накладных расходов.
8 дек 06, 17:34    [3512124]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
Александр Савинов
Member

Откуда:
Сообщений: 173
U-gene
Во-вторых, точечная нотация ни о чем не говорит вообще ни о чем. Это все го лишд запись языка программирования. Например, такая запись на неком языке программированя в некой абстрактной системе может быть транслирована в цепочку операция записываемой в РМД как JOIN. Будет ли такая система "удобнее"? :)

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

С общей точки зрения, PK-FK это механизм ограничения целостности, а join это алгебра. А мне хочется иметь механизм доступа, что не есть одно и то же. Поэтому использование точечной нотации говорит об одном, а PK-FK-join о другом, т.е. различия вовсе не поверхностные.

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

U-gene
Поиск недостатков в паре PK-FK ИМХО напоминает поиск недостаков в операции сравнения пары значений.... ну где то около того :)?

Я думаю, речь идет об удобстве-неудобстве, адекватности-неадекватности тех или иных средств. А универсального и непогрешимого не существует. Ну например, РМД плохо подходит для аналитических приложений - никто ведь не спорит.

U-gene
PS Каким то образом (сам не понимаю каким) вы у меня с Дармштадтом ассоциируетесь....:) ...или я ошибаюсь?

Нет, я живу в Бонне.
8 дек 06, 17:41    [3512183]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
Александр Савинов
Member

Откуда:
Сообщений: 173
!
Вас все устраивает в PK-FK , то что не устраивает,
великолепно реализуется сурагантым ключем без дополнительных накладных расходов.

Нет. Нам надо иметь произвольный PK, из многих колонок, определяемый разработчиком. Но в месте использования (FK) обозначать его одним именем.
8 дек 06, 17:55    [3512293]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 6 7 8 9 10 [11] 12 13 14 15 .. 31   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить