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

Откуда:
Сообщений: 349
Александр Савинов
Отсюда можно сделать некоторые определения:
Поиск - процедура нахождения объекта с нужными свойствами.
Доступ - процедура получения свойств объекта по его ссылке.

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

С практической точки зрения, например в само ускорение доступа на физическом уровне, подход не вносит ничего нового. Вы сами признали, что ваша абстрактная процедура для БД скорее всего будет реализована через индексацию. Более того вы занижаете значение поиска. Запросы для СУБД, это прежде всего нахождение объектов с нужными свойствами, то есть поиск. Только потом доступ. Как будут представлены найденные объекты, какими значениями, действительно не так важно, множеством ссылок или множеством уникальных ключей. Только затем вы осуществляете доступ к «объектам» и выбираете интересующие вас свойства.
7 дек 06, 17:57    [3506579]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
okdoky
Member

Откуда:
Сообщений: 349
Вместо Другое дело ссылка (или указатель, pointer), это действительно средство доступа и поиск здесь не нужен. точнее будет: Другое дело ссылка (или указатель, pointer), это действительно непосредственный доступ не предполагающий поиска.
7 дек 06, 18:01    [3506597]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
###
Member

Откуда: Курумоч
Сообщений: 658
Александр Савинов

Ну здесь же не лингвистический форум и даже не матаматический, а технологический. У большинства людей нет проблем с пониманием ссылки на этом уровне. Такие понятия как объект, переменная или ссылка в этом контексте имеют вполне ясный смысл и имеют роль, которую вполне можно назвать фундаментальной.
[остальное поскипано...]

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

Посыл - кто ясно мыслит, тот ясно излагает. Согласны?

Как я понял и Вашего высказывания, Вы предлагаете отказаться от четких определений в пользу интуитивного понимания терминов?

Не сочтите за "наезд", я сам стороннник новых технологий, новых подходов и решений, но лично Вас я никак не могу понять - о чем Вы говорите?!!
7 дек 06, 20:48    [3507257]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
foobar
Guest
Александр Савинов
Отсюда можно сделать некоторые определения:
Поиск - процедура нахождения объекта с нужными свойствами.
Доступ - процедура получения свойств объекта по его ссылке.

О, дернув немнога пивка, я понял что вы тут написали. Ваша ссылка внутре реализует функцию быстрого поиска объекта на физ. носителе (любом, неонка). А поиск по ключу интуитивно медленнее. Зашить такую штуку в модель - это круто йо!
7 дек 06, 23:13    [3507587]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
Александр Савинов
Member

Откуда:
Сообщений: 173
foobar
Александр Савинов
Отсюда можно сделать некоторые определения:
Поиск - процедура нахождения объекта с нужными свойствами.
Доступ - процедура получения свойств объекта по его ссылке.

О, дернув немнога пивка, я понял что вы тут написали. Ваша ссылка внутре реализует функцию быстрого поиска объекта на физ. носителе (любом, неонка). А поиск по ключу интуитивно медленнее. Зашить такую штуку в модель - это круто йо!

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

Далее. Основная функция ссылок это предоставление доступа к объектам, т.е. только ссылка знает как получить содержимое, хранящееся в объекте. Чтобы обеспечить такой доступ, мы предполагаем, что ссылка умеет разрешаться в базовую ссылку. Та, в свою очередь опять разрешается и т.д. Этот процесс бесконечен, но обычно останавливаются на каком-то уровне, который объявляют примитивным, например, адреса в памяти, ссылки на Яве или номера записей в БД.

И третье. Классы ссылок определяются вместе с классами объектов, поскольку это две части одного и того же. В результате все свойства делятся на две группы: внутри ссылок и внутри объектов.

Если сравнивать с ключами, то на самом деле я думаю скорость доступа не изменится. Разница в том, что в РМД ключ хранится реально как свойства объекта, но в то же время дублируется в индексе, где он имеет смысл ссылки. Уберите колонки ключа физически из таблицы и оставтье их в индексе и получите как раз мою модель. Я считаю важным не скорость доступа, а возможность разрабатывать свои собственные форматы ссылки, отвечающие целям модели (виртуальные адресные пространства).

Обычно за единицу измерения трудности понимания принимается пол литра (без которых не разберешся). Если же что-то понять можно "дернув немного пивка", то такой материал можно считать весьма легким.
7 дек 06, 23:45    [3507662]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
ModelR
Member

Откуда: Нижний Новгород
Сообщений: 1798
Александр Савинов
только ссылка знает как получить содержимое, хранящееся в объекте.
Очень сильное ограничение. Получаем урезанную модель памяти прямого доступа - по адресу могет, а Next не понимает.
Александр Савинов
Разница в том, что в РМД ключ хранится реально как свойства объекта, но в то же время дублируется в индексе, где он имеет смысл ссылки. Уберите колонки ключа физически из таблицы и оставтье их в индексе и получите как раз мою модель.
Никак невозможно, ибо в РМД не никаких индексов, если только не назвать индексами какие-то отношения.
Александр Савинов
Я считаю важным не скорость доступа, а возможность разрабатывать свои собственные форматы ссылки, отвечающие целям модели (виртуальные адресные пространства).
Наверно, кому-то пригодится.
Александр Савинов
Обычно за единицу измерения трудности понимания принимается пол литра (без которых не разберешся). Если же что-то понять можно "дернув немного пивка", то такой материал можно считать весьма легким.
:))
8 дек 06, 10:00    [3508477]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
!
Guest
Александр Савинов


Если сравнивать с ключами, то на самом деле я думаю скорость доступа не изменится. Разница в том, что в РМД ключ хранится реально как свойства объекта, но в то же время дублируется в индексе, где он имеет смысл ссылки. Уберите колонки ключа физически из таблицы и оставтье их в индексе и получите как раз мою модель. Я считаю важным не скорость доступа, а возможность разрабатывать свои собственные форматы ссылки, отвечающие целям модели (виртуальные адресные пространства).



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

Если всетаки оно необходимо для обработки(является свойством обьекта),
то лучше пользоваться PK-FK, то есть друнаправленной связью.

to shuklin
Об этом я пытался Вам сказать об эквивалентности с точки зрения реализации
связи(ссылки) в сетевой модели и ключа в РСУБД.

Этот индекс и есть таблицей переходов состояний
обьектов о котором я говорил выше.
8 дек 06, 10:33    [3508692]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
мод
Guest
В оракле есть rowid. Его можно использовать в запросах.
Есть два ограничения:
1. не гарантируется его неизменность
2. его нельзя использовать для ФК.
Снять эти ограничения и будет счастье ?
8 дек 06, 11:35    [3509233]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
!
Guest
мод
В оракле есть rowid. Его можно использовать в запросах.
Есть два ограничения:
1. не гарантируется его неизменность
2. его нельзя использовать для ФК.
Снять эти ограничения и будет счастье ?


В Informix этих огранчений нет.
Единственное ограничение: rowid не сохраняется при экспорте импорте.

Если базу переносить через бэкап - рестор все будет тип топ.

з.ы. Мне кажется мы пошли по второму кругу.
8 дек 06, 11:42    [3509285]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
Александр Савинов
Member

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


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



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

Должно быть доступно, иначе действительно плохо. Механизм должен с одной стороны поддерживать прозрачность доступа по ссылкам (иллюзия прямого доступа со скрытием структуры ссылок и промежуточных операций), а с другой стороны возможость залезть в ссылки или получить их функции.
8 дек 06, 11:48    [3509350]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
!
Guest
Александр Савинов
!
Александр Савинов


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



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

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


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

ИЛИ тогда вам нужно создавать индекс с воможностью
быстрого поиска как так по ключевому значению так и по ссылке( rowid) .
Что равносильно созданию 2 дервьев, с перекресными связями.

Что тоже эквивалентентно поведению PK-FK.


зы Еще раз повторяю обсуждение вышло на второй круг.
8 дек 06, 12:13    [3509474]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
мод
Guest
!
Единственное ограничение: rowid не сохраняется при экспорте импорте.

в оракле тоже самое
А вот как ФК rowid можно использовать ?
!
з.ы. Мне кажется мы пошли по второму кругу.

Да, но мне показалось что начали ломится в открытую дверь.
8 дек 06, 12:20    [3509541]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
Александр Савинов
Member

Откуда:
Сообщений: 173
ModelR
Александр Савинов
только ссылка знает как получить содержимое, хранящееся в объекте.
Очень сильное ограничение. Получаем урезанную модель памяти прямого доступа - по адресу могет, а Next не понимает.

Все зависит от функциональности ссылки. Если реализовать метод Next, то будет последовательный доступ. Можно реализовать сборщик мусора, проверку полномочий, кэширование или др. нужные функции. Собственно, идея как раз и состоит в том, что универсальные ссылки (средства доступа) нас не устраивают, а потому нужны средства моделирования собственных ссылок (виртуальных адресов), но так, чтобы была полная иллюзия работы с обычными ссылками. Др. словами, при использовании ссылок я не должен замечать, что это какие-то особые ссылки. А далее все зависит от разработчика ссылки.
8 дек 06, 12:21    [3509550]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
!
Guest
мод
!
Единственное ограничение: rowid не сохраняется при экспорте импорте.

в оракле тоже самое
А вот как ФК rowid можно использовать ?
!
з.ы. Мне кажется мы пошли по второму кругу.

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


Документация этого делать не рекомендует по причине

автор

Never store a rowid in a permanent table or attempt to use it as a foreign key. If a table is dropped and then reloaded from external data, all the rowids will be different.


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

Ссылка на первой странице топика.

з.ы. Для меня эта дверь была открыта с первой страницы обсуждения.
8 дек 06, 12:48    [3509746]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
!
Guest
Александр Савинов
ModelR
Александр Савинов
только ссылка знает как получить содержимое, хранящееся в объекте.
Очень сильное ограничение. Получаем урезанную модель памяти прямого доступа - по адресу могет, а Next не понимает.

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


suklin (как автор темы) запрещает арифметику указателей(ссылок) !!!!!!
Читайте попик.

2 shuklin или вы свое мнение уже изменили?

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

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

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

Чтобы экземпляр имел информацию о своем ID возможно 3 способа из которых 2 реализовано

- хранить ID как дополнительный аттрибут экземпляра
- паттерн Flyweight

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

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

suklin (как автор темы) запрещает арифметику указателей(ссылок) !!!!!!
Читайте попик.

2 shuklin или вы свое мнение уже изменили?

з.ы. незнаю как вставить ссылку на конкретый пост.


Это мое ИМХО. Оно осталось со мной и в процессе этого обсуждения.

Так реализованы например Java, C#, Cerebrum

Я не вижу большой трагедии в отсутствии арифметики ссылок. В C# есть отдельное понятие указателя, для которого арифметика разрешена. С 2002 года как я этот C# использую вдоль и поперек, только один раз этот указатель оказался полезен, да и то скорее из-за недороботки апи в C# (в яве тоже место сделано толковее и там указатели не нужны).
8 дек 06, 12:59    [3509858]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
!
Guest
shuklin
!
Другими словами, если к обьекту получать доступ по другой ссылке(индексу)
то это свойство будет недоступно.

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

Чтобы экземпляр имел информацию о своем ID возможно 3 способа из которых 2 реализовано

- хранить ID как дополнительный аттрибут экземпляра
- паттерн Flyweight

и еще не реализован
- определение ID по StackTrace


Тогда я абсолюнто не понимаю почему у Вас равенство != идентичность.
8 дек 06, 13:05    [3509919]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
nooo
Guest
Александр Савинов
так, чтобы была полная иллюзия работы с обычными ссылками.

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

Откуда: Нижний Новгород
Сообщений: 1798
Александр Савинов
Все зависит от функциональности ссылки. Если реализовать метод Next, то будет последовательный доступ. Можно реализовать сборщик мусора, проверку полномочий, кэширование или др. нужные функции. [...]А далее все зависит от разработчика ссылки.
Кхм.., а есть что-то в этом мире что НЕ ссылка?
8 дек 06, 13:19    [3510046]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
!
Guest
nooo
Александр Савинов
так, чтобы была полная иллюзия работы с обычными ссылками.

Появляется новая интуитивная сущность - обычная ссылка, и весьмааа интуитивное допущение, что объект всегда имеет обычную ссылку на себя.


+1 К вопросу о равенстве и едентичности.
8 дек 06, 13:21    [3510064]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
shuklin
Member

Откуда: Харьков
Сообщений: 799
!
Тогда я абсолюнто не понимаю почему у Вас равенство != идентичность.

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

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

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

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

Под равенством - обычное равенство по значению.
8 дек 06, 13:27    [3510116]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
Александр Савинов
Member

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


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



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

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


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


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

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

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

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

Вывод. Механизм PK-FK вполне подходит для использования на низком уровне как база для какого-то более сложного подхода. У него отличиные реализации, хорошая скорость, надежность, много других полезных качеств. На его основе можно выстроить что-то более современное. То же касается и современных СУБД, которые вполне могут служить в качестве физического хранилища информации, но интерфейс должен быть другой.
8 дек 06, 13:31    [3510147]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
mir
Member

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

Александр Савинов
Вообще, все исходит из того, что ссылки могут иметь любую (нужную) структуру и поведение наравне с объектами
Ссылки уже могут иметь поведение? Чем дальше в лес...

Александр Савинов
Разница в том, что в РМД ключ хранится реально как свойства объекта, но в то же время дублируется в индексе, где он имеет смысл ссылки.
Оказывается, в индексе ключ имеет роль ссылки… Хорошо, РМД как теорию вы не знаете, это мы поняли. Но вы и в практике что-то слабы, не сочтите за грубость. В индексе ключ роль ссылки не выполняет. В индексе ключ выполняет роль ключа (то есть значения). А роль ссылок в индексе выполняют таки ссылки. Несколько особая статья — кластерные индексы, но вы, для начала, с обычными разберитесь.

В общем, у меня вывод такой. Ежели этот форум, по вашему, технологический, что же вы лезете в сугубо теоретические вопросы? А если уж беретесь рассуждать на уровне теории, то что ж вы строгость подменяете «интуицией»?
8 дек 06, 13:36    [3510184]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
Александр Савинов
Member

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


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

2. С технической точки зрения все гораздо проще и конструктивнее. Мир двойственнен: есть ссылки и есть объекты. Соответственно, можно предложить классы ссылок и классы объектов для их описания. Но они неразделимы, а потому определяются парами. Тем самым мы легализуем ссылки и они получают такие же права как и объекты. Ну а далее надо описать механизм их взаимодействия, что в формате форума сделать невозможно, да это и не было моей целью (я выдвинул всего один простой тезис - что доступ объекта по его свойствам это поиск). Но это все достаточно просто, естественно и вполне конструктивно без всякой темной материи - обычная инженерия.
8 дек 06, 13:46    [3510267]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 5 6 7 8 9 [10] 11 12 13 14 .. 31   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить