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

Откуда:
Сообщений: 173
Gluk (Kazan)
Александр Савинов
1. Мы достигаем опосредования
2. Мы сохраняем типизацию
3. Мы сохраняем прозрачность доступа
4. Все ссылка на объект имеет одно имя (поля)

Теперь понятно, выражаясь вашим языком, "на крена?"


Нет, не понятно ЗАЧЕМ отделять ссылку от объекта
чем не устроил PK ???
Здесь кроется глубокое логическое противоречие, которое упоминалось при обсуждении вопроса о сути доступа и отличии его от поиска. Если свойство хранится внутри объекта, то его нельзя использовать для доступа. Для того, чтобы найти объект с нужным свойством, надо заглянуть внутрь него и сравнить его свойство с заданным. Но как его взять-то, если объект еще недоступен? Замкнутый круг. Чтобы его разорвать предлагается такое разделение. Для доступа по свойствам ссылки не надо лезть внутрь объекта, поскольку они там не хранятся.
21 дек 06, 17:02    [3567036]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
4321
Member [заблокирован]

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

теперь остается понять, чем это (кроме синтаксиса) отличается от реализации с ключами. (кроме того, что реализация с ключами публикует _значения_ этих самых ключей, и раз будучи найдены, они могут использоваться и в далнейшем, вы же попросту скрываете значения ключей==ссылок от пользователя (или пользовательской процедуры) но, надеюсь, оставите ему возможность объявлять ссылочную переменную? чтобы не заниматься все время контекстным поиском (т.е. вместо конструкций "цвет левого уха того осла, который..." нам все же позволено будет получить указатель в повторное пользование, но нельзя будет посмотреть на его значение). Вот и расскажите, чем это, кроме синтаксиса, будет отличаться (кроме того, что видимо отпадет возможность линковать сущности ссылочными полями к нессылочным или к исчисляемым - по значению ссылки). Во первых я совсем не уверен, что тут имеют место коренные отличия. А во вторых - сказавши а - неплохо сказать и б. Т.е. дает ли нам разделение идентификаторов и сущностей что-то реально новое. Например - не связанность индентификатора с одним сущностным типом. У вас - кажется нет (вы ведь, кажется, стоите за строгое определение типа, стоящего за ссылкой). (У шуклина - видимо да, но это совсем отдельная тема - ибо...)
21 дек 06, 17:05    [3567064]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
ModelR
Member

Откуда: Нижний Новгород
Сообщений: 1798
Александр Савинов
А вот гораздо более реалистичная ситуация, когда номер телефона потерян. Абонент по-прежнему существует и, более того, ничего о потере не знает. Но вот для нас он фактически не существует. Наличие ссылки это факт существования объекта.
Опять-таки очень сильное ограничение. Полезная система должна уметь возвращать объект и по не ссылочным признакам. Можно просто подойти к аппарату и им воспользоваться.
Александр Савинов
Когда клиент создает счет в банке, то ему тут же выдают номер. А вам больше ничего на самом деле и не нужно.
Да. Для клиента это не ссылка - это собственно данные его договора с банком. А вот у банка типичные для регистратора заморочки - если 15 менеджеров одновременно открывают счета клиентам, то как им получать номера счетов.
Александр Савинов
Теперь это счет можно передать другим людям или сохранить. Реально же все процедуры по созданию счета занимают существенно больше времени. Более того, объект может и не создаться вовсе, если скажем, после запроса в органы обнаружится, что у клиента рыльце в пушку. Еще один пример. Объект м.б. уничтожен по техническим причинам, но ссылки на него остаются (номер телефона, банковский счет). В результате все думают, что он есть, хотя его нет. Вообще, объект обычно сложное образование и может состоять из множества частей на разных уровнях, но все это скрыто и говорить о существовании объекта можно только исходя из наличия ссылки на него.
Это не ссылки, это данные.
ИМХО ссылка по определению такая весчь, которая либо NULL либо указуемый объект существует. И сетевая модель должна исходить из того, что или СУБД гарантирует такое положение дел, или она не отвечает сетевым принципам.
21 дек 06, 17:06    [3567072]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
ModelR
Member

Откуда: Нижний Новгород
Сообщений: 1798
Александр Савинов

Если свойство хранится внутри объекта, то его нельзя использовать для доступа. Для того, чтобы найти объект с нужным свойством, надо заглянуть внутрь него и сравнить его свойство с заданным. Но как его взять-то, если объект еще недоступен? Замкнутый круг. Чтобы его разорвать предлагается такое разделение. Для доступа по свойствам ссылки не надо лезть внутрь объекта, поскольку они там не хранятся.
Но для доступа по свойствам ссылки надо получить доступ к объекту ссылка, что невозможно ибо если...

Круг однозначно.
21 дек 06, 17:12    [3567137]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
4321
Member [заблокирован]

Откуда:
Сообщений: 3573
Александр Савинов
Для доступа по свойствам ссылки не надо лезть внутрь объекта, поскольку они там не хранятся.
???
ПК, поскольку он индекс, тоже храницо в индексе - т.е. в "средствах доступа к абъедкам", а не "в сущности" (вернее - не только в ней). Для нас же важно - что он, с тз. модели - св-во объедка. И мы "скрываем" место и способ его хранения за общностью способов обращения к свойствам. Вам же понадобится 2 разных способа для обращения к разделенным вами на 2 типа свойств. Само по себе это не плохо и не хорошо. Но усложняет язык.
Вот и спрашивается - для чего?
Всего то надо рассказать, что же из этого получиццо рулезного, а не выдумывать на ходу "коренные различия" между ключами и сцылками. которые дескать кому-то мешают жить.
21 дек 06, 17:13    [3567143]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
ModelR
Member

Откуда: Нижний Новгород
Сообщений: 1798
4321
что же из этого получиццо рулезного.
Дык желание понятно - вот сказал на ER диаграмме что Сотрудник работает в Отделе - все - гарантируй выполнение кода
Сотрудник.Отдел
как бы там не менялась схема доступа/ключ/идентификатор отдела.
Т.е. допускается программный код прямиком в терминах ER связей.
21 дек 06, 17:27    [3567274]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
Александр Савинов
Member

Откуда:
Сообщений: 173
ModelR
Александр Савинов
А вот гораздо более реалистичная ситуация, когда номер телефона потерян. Абонент по-прежнему существует и, более того, ничего о потере не знает. Но вот для нас он фактически не существует. Наличие ссылки это факт существования объекта.
Опять-таки очень сильное ограничение. Полезная система должна уметь возвращать объект и по не ссылочным признакам. Можно просто подойти к аппарату и им воспользоваться.
Не спорю. Для этого есть система поиска. Отличие ее в том, что она свойствам объекта сопоставляет ссылки. При поиске доступ НЕ осуществляется. Например, по адресу можно найти телефон или несколько телефонов, но ведь доступа пока еще никакого не было (в смысле никто не звонил). А потому мы не можем сказать, есть на том конце кто-то или нет. Поиск это нахождение ссылок (которые представляют объекты).

ModelR
Александр Савинов
Когда клиент создает счет в банке, то ему тут же выдают номер. А вам больше ничего на самом деле и не нужно.
Да. Для клиента это не ссылка - это собственно данные его договора с банком. А вот у банка типичные для регистратора заморочки - если 15 менеджеров одновременно открывают счета клиентам, то как им получать номера счетов.
Номер счета это типичная ссылка. Вопрос данные это или нет оспаривался на этом форуме, как и вопрос о том, нужно ли ссылки моделироваь. Вопрос о выдаче уникальных счетов (генерировании ссылок) действительно может быть довольно сложным, но это техническая проблема. Главное, что клиента (на его уровне) совершенно не интересует кто, как и где создает объект-счет (на бумаге, в компе или в голове клерка). Таким образом, пространство счетов виртуально. Для него счет это просто номер, поскольку именно этот номер является его проводником в мир денег. А банк со своей стороны, должен гарантировать, что такая ссылка будет работать.

ModelR
Александр Савинов
Теперь это счет можно передать другим людям или сохранить. Реально же все процедуры по созданию счета занимают существенно больше времени. Более того, объект может и не создаться вовсе, если скажем, после запроса в органы обнаружится, что у клиента рыльце в пушку. Еще один пример. Объект м.б. уничтожен по техническим причинам, но ссылки на него остаются (номер телефона, банковский счет). В результате все думают, что он есть, хотя его нет. Вообще, объект обычно сложное образование и может состоять из множества частей на разных уровнях, но все это скрыто и говорить о существовании объекта можно только исходя из наличия ссылки на него.
Это не ссылки, это данные.
Ссылку можно понимать как роль, которую играют данные. Например, целое число это ссылка или нет? Однозначно нельзя сказать. Если это число используется для идентификации объекта, то ссылка. А если как характеристика, то не ссылка. Хотя характеристики они и есть обычно ссылки. Так что роль определяется на самом деле уровнем системы. Т.е. для клиента номер счета это ссылка, а для банка это данные. Здесь можно порассуждать. Для меня важнее как будет работать весь механизм (и будет ли вообще рабтать).

ModelR
ИМХО ссылка по определению такая весчь, которая либо NULL либо указуемый объект существует. И сетевая модель должна исходить из того, что или СУБД гарантирует такое положение дел, или она не отвечает сетевым принципам.
Я бы не стал спорить. Вопрос только, как выражается существование объекта. Например, если у меня в программе есть адрес в памяти, по которому я хочу получить содержимое. Вопрос: содержимое по этому адресу существует или нет? Можно было бы сказать да, но есть одно но. Реально по этому адресу может ничего не храниться, по крайней мере то, на что мы расчитываем. Память ведь виртуальная и там могут храниться какие-то чужие данные, либо вообще ничего. Поэтому объекта реально нет, а виртуально он есть. Процессор нас просто разводит. В момент доступа будет прерывание он загрузит в адресуемую ячейку нужные данные. Объект появился. А потом опять исчез. Может происходить еще куча трансформаций. И именно это я имею в виду, когда говорю, что единственное, что остается неизменным в этом процессе - это ссылка.
21 дек 06, 17:33    [3567317]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
Александр Савинов
Member

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

Если свойство хранится внутри объекта, то его нельзя использовать для доступа. Для того, чтобы найти объект с нужным свойством, надо заглянуть внутрь него и сравнить его свойство с заданным. Но как его взять-то, если объект еще недоступен? Замкнутый круг. Чтобы его разорвать предлагается такое разделение. Для доступа по свойствам ссылки не надо лезть внутрь объекта, поскольку они там не хранятся.
Но для доступа по свойствам ссылки надо получить доступ к объекту ссылка, что невозможно ибо если...

Круг однозначно.
Вот пример, поясняющий идею:

Объявляем класс где одно поле идентификатор:
class Account {
  int ID; // Типа ПК
  int balance; // Типа свойство
}
Далее запоминаем везде именно ID и используем его для доступа, например:
account = 12345;
balance = account.balance; // Опосредованый доступ - нужно разрешить ссылку
По идентификатору надо найти объект, поэтому где-то есть индекс, который нам поможет:
account_pointer = map.get(12345); // Разрешили ID в указатель на объект
balance = account_pointer.balance; // Прямой доступ. Получаем свойство объекта
А теперь задумаемся: зачем в класса Account существует поле ID? Оно ведь никак не используется! Оно там просто не нужно в нашем примере его действительно нигде нет. Список всех существующих ID хранится в отображении (индексе) map, но в самом объекте он не нужен. Там он аппендикс, пятое колесо. Вот это и есть логический баг. Одно возможное решение: принципиальное отделение ссылок от объекта.
21 дек 06, 17:49    [3567472]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
shuklin
Member

Откуда: Харьков
Сообщений: 799
Александр Савинов
Одно возможное решение: принципиальное отделение ссылок от объекта.
И как следствие - возможность иметь ссылки с различными ID на один и тот же объект account. Тоесть при неравенстве ссылок идентичность сохраняется.

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

Т.е. получаем синонимию/омонимию объектных идентификаторов.
21 дек 06, 17:55    [3567522]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
Александр Савинов
Member

Откуда:
Сообщений: 173
shuklin
Александр Савинов
Одно возможное решение: принципиальное отделение ссылок от объекта.
И как следствие - возможность иметь ссылки с различными ID на один и тот же объект account. Тоесть при неравенстве ссылок идентичность сохраняется.
Технически никаких проблем нет. Достаточно, чтобы разрешатель (которого при использовании ссылок не видно - прозрачность) отображал их в одно и то же. Ну а практическую ценность надо конечно обосновать (как и самого механизма разделения), поскольку это может приводить к казусам при сравнении. Кстати, ссылка вовсе не обязана иметь только идентифицирующие поля. Там может быть все что угодно. Например, в ссылку можно включить поле с датой создания счета ну или остаток на заданную дату. Это затраты по размеру ссылок, но экономия по времени доступа (не надо лезть внутрь объекта).

shuklin
И для полноты картины иметь одинаковые ссылки на разные объекты - в зависимости от разного адресного пространства. На этом можно очень много полезного и интересного получить.

Т.е. получаем синонимию/омонимию объектных идентификаторов.
Здесь это не упоминалось, но ссылки имеют вполне естественную иерархическую структуру как у почтового адреса, которая определяется отношением наследования (в оригинале отношение включения). В этом случае младшие сегменты не должны быть уникальными. Например, можно иметь одинаковые счета в разных банках. Это все работает, т.е. ссылка разрешается в зависимости от контекста (от старшего сегмента).
21 дек 06, 18:05    [3567632]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
shuklin
Member

Откуда: Харьков
Сообщений: 799
Александр Савинов
Здесь это не упоминалось, но ссылки имеют вполне естественную иерархическую структуру как у почтового адреса, которая определяется отношением наследования
Тут наиболее перспективным мне видится полиморфизм функции разрешения ссылки при ее наследовании. Жаль что такого инструмента нет в эксплуатации, я бы его с пользой смог применить в своей ООСУБД.
21 дек 06, 18:15    [3567718]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
7
Guest
Александр Савинов
Номер счета это типичная ссылка.

Страница №30... А чем адрес отличается от ссылки?
21 дек 06, 18:46    [3567897]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
!
Guest
shuklin
Александр Савинов
Здесь это не упоминалось, но ссылки имеют вполне естественную иерархическую структуру как у почтового адреса, которая определяется отношением наследования
Тут наиболее перспективным мне видится полиморфизм функции разрешения ссылки при ее наследовании. Жаль что такого инструмента нет в эксплуатации, я бы его с пользой смог применить в своей ООСУБД.


Да не проблема это.
Зделайте вашу ссылку полем класса
определите виртуальные операторы -> , & и наследуйте их наздоровье.
21 дек 06, 18:51    [3567925]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
Александр Савинов
Member

Откуда:
Сообщений: 173
7
Александр Савинов
Номер счета это типичная ссылка.

Страница №30... А чем адрес отличается от ссылки?
По моему, ничем (существенным, а также в контексте дискуссии). А Ваше какое мнение?
21 дек 06, 18:53    [3567937]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
shuklin
Member

Откуда: Харьков
Сообщений: 799
!
Да не проблема это.
Зделайте вашу ссылку полем класса
определите виртуальные операторы -> , & и наследуйте их наздоровье.


В плюсах это работать будет, но я говорил про нет.
21 дек 06, 19:12    [3567996]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
7
Guest
Александр Савинов
7
Александр Савинов
Номер счета это типичная ссылка.

Страница №30... А чем адрес отличается от ссылки?
По моему, ничем (существенным, а также в контексте дискуссии). А Ваше какое мнение?

Как ето - в контексте дискуссии? И ссылка тоже мутирует в контексте!?

Александр Савинов
Предоставление доступа это функция ссылки.


Номер счета - число - никаких функций не реализует. Функции в ООП называются методами. Какой объект реализует метод доступа по номеру счета?
21 дек 06, 19:37    [3568042]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
Александр Савинов
Member

Откуда:
Сообщений: 173
7
Александр Савинов
Предоставление доступа это функция ссылки.


Номер счета - число - никаких функций не реализует. Функции в ООП называются методами. Какой объект реализует метод доступа по номеру счета?
Номер счета это число внутри класса ссылки (identity). В классе ссылки есть метод, который знает как разрешать свои ссылки (continue). Этот метод вызывается автоматически, когда нужен доступ к объекту по этой ссылке. Например:
concept Account
  identity {
    int ID;
    void continue() { // Этот метод будет вызван автоматически при доступе
      print(">>> Start access.");
      Object o = map.get(ID);  // Разрешить данную ссылку
      o.continue(); // Продолжить доступ
      print("<<< End access.");
    }
  }
  entity {
    double balance;
  }
21 дек 06, 19:57    [3568069]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
7
Guest
Александр Савинов

Номер счета это число внутри класса ссылки (identity).

Кто бы мог подумать! Номер счета - число внутри класса! ссылки! Число внутри класса ссылки называется ссылкой. Теперь я знаю как называется число внутри класса объекта!
21 дек 06, 20:12    [3568102]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
!
Guest
Александр Савинов
7
Александр Савинов
Предоставление доступа это функция ссылки.


Номер счета - число - никаких функций не реализует. Функции в ООП называются методами. Какой объект реализует метод доступа по номеру счета?
Номер счета это число внутри класса ссылки (identity). В классе ссылки есть метод, который знает как разрешать свои ссылки (continue). Этот метод вызывается автоматически, когда нужен доступ к объекту по этой ссылке. Например:
concept Account
  identity {
    int ID;
    void continue() { // Этот метод будет вызван автоматически при доступе
      print(">>> Start access.");
      Object o = map.get(ID);  // Разрешить данную ссылку
      o.continue(); // Продолжить доступ
      print("<<< End access.");
    }
  }
  entity {
    double balance;
  }


Вам не кажется, что int ID; и map.get(ID); те самые метапереходы о вредности которых
говорил shuklin ?

Зачем вводить сурагат в виде int ID; если необходимости в этом для прикладной части может не быть никакой.
Там может быть вполне достаточно естественного ключа ( номер счета) .
21 дек 06, 20:17    [3568116]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
Александр Савинов
Member

Откуда:
Сообщений: 173
!
Вам не кажется, что int ID; и map.get(ID); те самые метапереходы о вредности которых
говорил shuklin ?
Метод continue это переход через границу слоя, но что такое метапереход я не знаю.
!
Зачем вводить сурагат в виде int ID; если необходимости в этом для прикладной части может не быть никакой.
Там может быть вполне достаточно естественного ключа ( номер счета) .
Есть механизм, а как его использовать это уже другое дело. Если класс ссылки не определен (пустой), то ссылка будет унаследована от базового класса. А если надо, то можно сложный ключ определить, например, номер счета или несколько полей. По любому вся эта внутренняя механика будет скрыта. Кстати, ID это не суррогат. Суррогат это то, что принадлежит системе, т.е. за что несет ответственность система. А здесь это наше собственное поле, которым мы должны управлять. Вот если бы мы унаследовали ссылку из базового системного класса, то это был бы суррогат.
21 дек 06, 22:36    [3568315]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
7
Guest
Александр Савинов
Object o = map.get(ID);  // Разрешить данную ссылку

Здесь o - не объект. У map нет ссылки на объект. Нет ссылки - нет объекта, есть ссылка - цикл.

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

o.continue(); // Продолжить доступ

Здесь продолжается доступ к недоступному через вызов его же недоступного метода; или continue - цитирую - метод класса = статический. В статических методах экземпляры не менее недоступны. Зачем вы всех обманываете? 8)
22 дек 06, 07:25    [3568661]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
Александр Савинов
Gluk (Kazan)
Александр Савинов
1. Мы достигаем опосредования
2. Мы сохраняем типизацию
3. Мы сохраняем прозрачность доступа
4. Все ссылка на объект имеет одно имя (поля)

Теперь понятно, выражаясь вашим языком, "на крена?"


Нет, не понятно ЗАЧЕМ отделять ссылку от объекта
чем не устроил PK ???
Здесь кроется глубокое логическое противоречие, которое упоминалось при обсуждении вопроса о сути доступа и отличии его от поиска. Если свойство хранится внутри объекта, то его нельзя использовать для доступа.


Помимо PK(UK) есть еще FK, о чем вам неоднократно уже здесь говорили.
Так что проблема притянута за уши. Ответ на сакраментальный вопрос так и не прозвучал.
22 дек 06, 10:21    [3569287]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
!
Guest
Александр Савинов

!
Вам не кажется, что int ID; и map.get(ID); те самые метапереходы о вредности которых
говорил shuklin ?
Метод continue это переход через границу слоя, но что такое метапереход я не знаю.


Я невидел определения понятия граница слоя в этом топике.

НО логически поразмыслив из контекста топика можно зделать вывод:
переход через границу слоя  есть часный случай метаперехода



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

Если класс ссылки не определен (пустой), то ссылка будет унаследована от базового класса.


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

Кто эту бороду связей распутывать потом будет?


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

Кстати, ID это не суррогат. Суррогат это то, что принадлежит системе, т.е. за что несет ответственность система. А здесь это наше собственное поле, которым мы должны управлять. Вот если бы мы унаследовали ссылку из базового системного класса, то это был бы суррогат.


Из данный которыми мы сейчас опереруем реально в жизни существует только счет.
Все остальное сурагат. Нахрена клиенту еще какойто там ID?
Это же его ссылка на его же счет.
По вашей модели все остальные детали счета доступны только после разрешения ссылки.

Может я чегото не понял, и вы описали не ссылку а сам обьект?
Тогда опишите ссылку.


з.ы. Запутали окончательно.
22 дек 06, 10:48    [3569493]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
ModelR
Member

Откуда: Нижний Новгород
Сообщений: 1798
Александр Савинов

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

Про отделение ссылок от данных. Собственно у меня ощущение что отделить можно любые проиндексированные данные, не только адреса. Посторим индекс по account.balance и на фига его хранить собственно в account?
22 дек 06, 11:25    [3569788]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
ModelR
Member

Откуда: Нижний Новгород
Сообщений: 1798
Отделение перекликается с так называемой 6НФ. Если мы проиндексируем каждое поле, а затем прибьем собственно таблицу оставив индексы то получим 6НФ декомпозицию.
22 дек 06, 12:09    [3570162]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 22 23 24 25 26 27 28 29 [30] 31   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить