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

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

+1

Попытка вывести их на разговор о физическом хранении информации
на диске ни чему не привела.

Они прекрасно понимают, что с началом глубокого рассмотрения
этого вопроса связи( на физическом уровне )
превратятся в эквивалент PK-FK.


Кто кроме ребят из Линтер здесь делал свою СУБД? С кем здесь эти вопросы мне будет интересно обсуждать?
6 дек 06, 12:43    [3498346]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
мод
Guest
shuklin
Кто кроме ребят из Линтер здесь делал свою СУБД? С кем здесь эти вопросы мне будет интересно обсуждать?

Да только ленивый в молодости не делал свою СУБД (и не одну). Поэтому и обсуждать это с вами особо никто не стремится - не интересно.
6 дек 06, 13:05    [3498560]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
Александр Савинов
Member

Откуда:
Сообщений: 173
okdoky
IP почему-то разблокировали
… А идентификатор в ОМД настоящий - он не является просто одной из характеристик объекта. Для лучшего понимания я уже приводил примеры объектов без характеристик (но не может быть тела отношения без атрибутов, точнее в таком отношении может быть только один нульарный кортеж).
Почему сторонники ОМД так упорно под идентификатором понимают ссылку или указатель? Физический уровень превращают в логический?


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

Вообще, использование свойств для идентификации, например, так

class MyClass {
  int ID; // Анти-паттерн - но другого способа не существет
  double color;
  ...
}

это обычно анти-паттерн (если человек ясно не понимает, чего творит). В РМД этот антипаттерн легализован в виде ключей, а в ОО подходах просто нет других способов моделировать идентификаторы (как средство доступа к сущностям), кроме примитивных ссылок. Почему это антипаттерн? Потому что свойство не может принципиально предоставить доступ к сущности, а значит мы не решаем проблему, а обходим ее, т.е. используем трюк. Если человек не понимает, что он делает (что чаще всего имеет место быть), то это приводит к серьезным ошибкам в дизайне.
6 дек 06, 13:06    [3498565]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
!
Guest
shuklin
!
okdoky

+1

Попытка вывести их на разговор о физическом хранении информации
на диске ни чему не привела.

Они прекрасно понимают, что с началом глубокого рассмотрения
этого вопроса связи( на физическом уровне )
превратятся в эквивалент PK-FK.


Кто кроме ребят из Линтер здесь делал свою СУБД? С кем здесь эти вопросы мне будет интересно обсуждать?


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

Треп "Взагалі" меня не интересует.
6 дек 06, 13:06    [3498572]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
ModelR
Member

Откуда: Нижний Новгород
Сообщений: 1798
мод
ModelR
а можно сравнивать собственно указатели на идентичность

Добавлю, что имеет смысл сравнивать только указатели одного типа.
Типы опущены для простоты. К тому же автор топика типизацию считает опциональной.
А вот теперь точка выбора: указатели - это данные или нет? C++ говорит да делайте что хотите, java - нет, полем структуры оно может быть, но руками не трогать, и вообще сделайте вид что не знаете такого слова, говорите объектнная переменная. ЧАЛ (если я правильно понимаю) - и полем быть не может. А как связывать? - а есть отдельное понятие связь - вот там пожалуйста.
6 дек 06, 13:07    [3498579]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
okdoky
Member

Откуда:
Сообщений: 349
shuklin
Кто кроме ребят из Линтер здесь делал свою СУБД? С кем здесь эти вопросы мне будет интересно обсуждать?
Не думаю, что даже ребята сделавшие свою СУБД будут путать ссылки с идентификаторами. Вот вам пример. Задана такая связь:
a1 -> b1
a2 -> b1
a3 -> b1
a4 -> b2
Вы предлагали делать ссылку от A к B. Представьте что объектов A гораздо больше чем B. Чтобы найти все A связанные с b1 системе придется перебирать все A. Те самые ребята для эффективного выполнения такой задачи использовали бы ссылки от B к A. Догадайтесь почему?

Если вы хотите говорить о семантике, логическом уровне, то под идентификаторами нужно понимать только обозначения объектов на логическом уровне (их имена или ключи), а не ссылки на них. Даже SQL-запрос, в конечном счете тоже идентификатор (хоть и не уникальный, не точный).
6 дек 06, 13:29    [3498836]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
ModelR
Member

Откуда: Нижний Новгород
Сообщений: 1798
Александр Савинов
Я думаю, что под идентификатором понимается нечто, что предоставляет доступ к сущности. Если так, то все было сказано правильно, поскольку любое свойство сущности вообще и ключ в РМД в частности не могут предоставить доступ к сущности.
Доступ предоставляют к памяти. Сущность же быть имеет существовать не зависимо от устройства памяти. Если некие сведения о сущности поместили в некую память (базу данных), то у этой сущности появилось еще одно свойство (точнее два) - где эта база и где в ней эти сведения. Например у человека в кармане база. Запись номер 1 - российский паспорт (в базе данных МВД РФ меня записали вот так-то). Запись номер 2 - ник/пароль на SQL.RU
Идентифицирует ли база МВД РФ человека? А попробуйте потерять паспорт и придти сказать вот он я, дайте новый, а то самолет через час. Гарантирует ли SQL.RU что "ЧАЛ" и "IP почему-то разблокировали" это разные люди?

Короче доступ - про память, РМД - про данные.
РМД рассматривает собственно данные и говорит: ЦРУ и ФСБ однако не все зря проедают - ну нет способа однозначно идентифицировать человека, особенно если он этому сопротивляется.
Но данные хранить надо - запишем что знаем, дадим ИД и
1)внутри базы можем им пользоваться для доступа.
2)сообщим человеку/опубликуем, кто не забудет пусть тоже пользуется.

Это не к тому, кто лучше/хуже, а чем забивать и чем инфузорий разглядывать.
6 дек 06, 13:53    [3499138]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
мод
Guest
ModelR
А вот теперь точка выбора: указатели - это данные или нет?

ПМСМ - указатели это данные. Они имеют тип, значение, их можно сравнивать, присваивать, удалять. Указатель - это вообще атрибут сущности, в СУБД превращается в поле записи. А вот то, на что указывает указатель, м.б. полем или rowid (в РСУБД) или только rowid (в сетевых СУБД).
В случае, если считать, что указателей нет, а есть связи, то возникает очень много проблем, решать которые нет никакого желания.
зы Во всех сетевых СУБД указатели это данные.
6 дек 06, 14:40    [3499566]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
pavelvp
Member

Откуда:
Сообщений: 673
ModelR
Александр Савинов
Я думаю, что под идентификатором понимается нечто, что предоставляет доступ к сущности. Если так, то все было сказано правильно, поскольку любое свойство сущности вообще и ключ в РМД в частности не могут предоставить доступ к сущности.
Доступ предоставляют к памяти. Сущность же быть имеет существовать не зависимо от устройства памяти. Если некие сведения о сущности поместили в некую память (базу данных), то у этой сущности появилось еще одно свойство (точнее два) - где эта база и где в ней эти сведения.
Поддерживаю. Однако, IMHO, фраза Александра имеет большую ценность. Он изложил суть то, что имеет в виду под идентификаций, и её отсутствием в РМД, ЧАЛ.
6 дек 06, 15:56    [3500250]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
mir
Member

Откуда: Томск
Сообщений: 1027
Александр Савинов
Я думаю, что под идентификатором понимается нечто, что предоставляет доступ к сущности. Если так, то все было сказано правильно, поскольку любое свойство сущности вообще и ключ в РМД в частности не могут предоставить доступ к сущности.
Александр, я думаю, что основная проблема, которая обесценивает обсуждение, состоит в отсутствии четкости и необходимого формализма в терминологии. Как только вы начинаете строить рассуждения в стиле «нечто, что предоставляет доступ к сущности» , вы обрекаете себя и других на потерю времени, поскольку здесь бессмысленными являются понятия
1) «нечто»
2) «доступ»
3) «сущность».

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

С этой точки зрения, РМД выгодно выделяется тем, что вообще не претендует на всеобъемлющее и потому мутное понятия «идентификатор», в ней этого вообще нет. Вся терминология построена на относительно простых понятиях: множество, значение, переменная, операция. Имея дело со значениями математика вообще не нуждается в дополнительном понятии «идентификатор», ибо все значения являются само-идентифицирующими. Почитайте, скажем, статью Дейта http://zeus.sai.msu.ru:7000/database/articles/relvar2be/

В целом в РМД, цитируя Дейта, «значения v1 и v2 являются равными в том и только в том случае, когда они являются одним и тем же значением». Есть еще понятия физического представления значений, они могут отличаться, но это в статье затронуто.

Кортежи в отношении есть значения (составные, но значения). Отношение есть множество, поэтому все кортежи есть по определения разные значения.
Что же тогда потенциальный ключ и зачем он нужен? Вообще говоря, если ПтК явно не задан, по теории им должно считаться множество всех атрибутов отношения. (К сожалению, в SQL это не так, тут нарушение теории, причем совершенно не нужное.) Зачем же его специально задавать? В чистой абстрактной математике — незачем.

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

Прикладное же знание говорит нам, что при сравнении кортежей не все атрибуты вносят одинаково полезный/важный вклад. Что с точки зрения обеспечения целостности очень важно, чтобы система контролировала уникальность кортежей именно по таким-то подмножествам атрибутов, а вот такие-то участвовать в сравнении совершенно не должны. Это как раз то место, где прикладной аспект науки очень важен.

Так являются ли ПтК «идентификаторами»? Если на секунду забыть, что точный смысл этого понятия не вполне ясен, и, скажем, ответить, что да, то только с обязательной добавкой: ПтК отношения есть идентификатор не в большей степени, что и все атрибуты отношения разом. То есть с логической точки зрения, кортеж как значение сам по себе не худший идентификатор, чем любой его ПтК (и вполне самодостаточный).
Еще раз: явное определение ПтК для отношения несет (в теории) главную задачу все таки не в том, чтобы снабдить отношение «идентификатором», а в том, чтобы обеспечить дополнительное и очень важное ограничение целостности.

К сожалению, в SQL таблица без явно заданного ПК более не является отношением, поэтому для SQL-таблиц явное определение ПК помимо указанной выше роли играет-таки еще и роль создания «идентификатора».

Поскольку математика основана на значениях и не знает, что такое «указатели» (ссылки) (и от этого совершенно не страдает тысячи лет), то в состав РМД как логической модели данных, основанной на математике, указатели не включены. За ненадобностью. Другое дело — уровень реализации, которым ведает конкретная СУБД. Тут возможно все, что угодно. Главное точно отделять логический уровень от физического. Указатели (ссылки) есть исключительно понятия уровня реализации. Хорошо это демонстрирует тот факт, что ссылка в ОЗУ, ссылка на диске и ссылка на ленте есть совершенно разные концепции, из-за разной физической природы доступа в этих носителях.

Позвольте все ваши слова про «"истинные" средства доступа», «обман зрителя» и т.д. из вежливости даже и не комментировать, ибо их точный смысл укрыт не только от меня, но и, полагаю, даже для вас.
6 дек 06, 15:57    [3500261]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
pavelvp
Member

Откуда:
Сообщений: 673
2 mir Респект.
6 дек 06, 16:07    [3500364]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
мод
Guest
mir
в состав РМД как логической модели данных, основанной на математике, указатели не включены. За ненадобностью.

Что-то здесь не так. В концептуальной модели указатели есть, при переходе к РМД они куда-то исчезают, в РСУБД снова появляются (rowid, сурр. ключи). А на фиг тогда такая РМД ? (правильный ответ - нужна другая РМД).
6 дек 06, 16:21    [3500490]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
мод
mir
в состав РМД как логической модели данных, основанной на математике, указатели не включены. За ненадобностью.

Что-то здесь не так. В концептуальной модели указатели есть, при переходе к РМД они куда-то исчезают, в РСУБД снова появляются (rowid, сурр. ключи). А на фиг тогда такая РМД ? (правильный ответ - нужна другая РМД).


Нынче модно путать логическую модель с физической реализацией ?
6 дек 06, 16:26    [3500552]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
shuklin
Member

Откуда: Харьков
Сообщений: 799
мод
Что-то здесь не так.
Там много чего не так, например антимонии
6 дек 06, 16:35    [3500636]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
Александр Савинов
Member

Откуда:
Сообщений: 173
mir
Александр Савинов
Я думаю, что под идентификатором понимается нечто, что предоставляет доступ к сущности. Если так, то все было сказано правильно, поскольку любое свойство сущности вообще и ключ в РМД в частности не могут предоставить доступ к сущности.
Александр, я думаю, что основная проблема, которая обесценивает обсуждение, состоит в отсутствии четкости и необходимого формализма в терминологии. Как только вы начинаете строить рассуждения в стиле «нечто, что предоставляет доступ к сущности» , вы обрекаете себя и других на потерю времени, поскольку здесь бессмысленными являются понятия
1) «нечто»
2) «доступ»
3) «сущность».

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

[краткое изложение РМД вырезано]

Позвольте все ваши слова про «"истинные" средства доступа», «обман зрителя» и т.д. из вежливости даже и не комментировать, ибо их точный смысл укрыт не только от меня, но и, полагаю, даже для вас.

Итак, в РМД идентификаторы не нужны, правильно я понял (обеспечение целостности или уникальности это ведь не есть идентификация)? Но тогда идинственный способ сохранить информацию о значении или кортеже состоит в запоминании свойств сущности. Далее мы надеемся, что эти сохраненные свойства дадут нам возможности найти целевой элемент. Например, есть кортеж с описанием личности. Чтобы запомнить его, мы сохраняем какие-то свойства, скажем <глаза=хитрые, руки=длинные, религия=РМД>. Такие же свойства хранятся в кортеже, а потому при необходимости мы можем найти данный объект. Я правильно понимаю, или где-то ошибка?

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

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

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

Что касается РМД, то из вашего краткого изложения следует, что в ней понятия доступа нет, т.е. никто не знает как получить доступ к значениям v1 и v2. А значит и не надо моделироваь идентификаторы, и единственный способ что-то сохранить для дальнейшего доступа это использовать (уникальные) свойства. Правильно? Ну тогда это как раз то, что я хотел сказать, т.е. РМД занимается только моделированием свойств сущностей (но не идентификаторов). Правда, есть одно "но". Дело в том, что говорить о сущностях, будь то значения или кортежи, без того, чтобы сказать как осуществляется к ним доступ, это по моему, полный абсурд. Зачастую бОльшая часть дизайна как раз приходится на моделирования идентификаторов. Но делается это неадекватными способами через идентифицирующие признаки. Но это уже другой вопрос.
6 дек 06, 16:47    [3500754]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
shuklin
Member

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

Респект
6 дек 06, 16:52    [3500789]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
мод
Guest
Gluk (Kazan)

Нынче модно путать логическую модель с физической реализацией ?

А это где и в чем ?
6 дек 06, 17:48    [3501027]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
okdoky
Member

Откуда:
Сообщений: 349
Не успел прочитать последний пост Александра Савинова. Похоже он как и mir внес больше конструктивизма. От себя добавлю следующее.

Итак, на уровне реализации в качестве идентификаторов, в ОМД проще использовать указатели, в РМД уникальные ключи. Кажется, с этим согласны все. Пожалуй следует согласиться и с тем, что физическая реализация откладывает некоторый оттенок на логический уровень той и другой модели.

Вернемся к тому примеру, который я привел ранее.
class R {
A a;
A b;
}
Универсальным типом в ОМД является некий корневой тип Object.
То есть как минимум иерархия типов может выглядеть так
Object
R A
Мы можем создать некоторый объект типа R и присвоить его полю а определенное значение.
R r = new R();
r.a = …;
Заметьте для обозначения объекта мы используем переменную r. Можно считать, что значением переменной является идентификатор объекта. Не важно, что собственно он представляет, указатель, некоторый ключ, … Это опять же вопросы реализации. Нам на логическом уровне требуется дать ему имя (идентификатор). Имя требуется даже для того, чтобы отобразить этот объект на экране (значение переменной r). В РМД используется более явная идентификация и это плюс.

Конечно в ОМД есть много своих интересных вещей. Например, существует тип Class. Например, допустимо следующее:
class R {
Class a;
Class b;
}
Тогда значением поля a для некоторого объекта может стать даже сам тип R:
R r = new R();
r.a = R.class;
То есть переменная a фактически указывает на некоторый тип R. Ну и что? Тип также можно идентифицировать в РМД.
6 дек 06, 17:57    [3501094]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
мод
Guest
Александр Савинов
Правда, есть одно "но". Дело в том, что говорить о сущностях, будь то значения или кортежи, без того, чтобы сказать как осуществляется к ним доступ, это по моему, полный абсурд. Зачастую бОльшая часть дизайна как раз приходится на моделирования идентификаторов. Но делается это неадекватными способами через идентифицирующие признаки.

На практике именно так и есть, т.е. само существование РМД не несет в себе никакого смысла, поскольку все равно приходится заниматься моделированием исходной концепт. модели с помощью подручных средств РСУБД.
6 дек 06, 17:58    [3501101]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
мод
Guest
okdoky
Итак, на уровне реализации в качестве идентификаторов, в ОМД проще использовать указатели, в РМД уникальные ключи.

А может проще говорить о реализации в конкретной СУБД (причем тут модели)?
6 дек 06, 18:01    [3501127]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
foobar
Guest
Александр Савинов
доступ к объекту не может быть организован на основе его свойств

Не вижу аналогий в реале. Для доступа к объекту мне нужен сам объект (что такое доступ?), а чтобы отличить друг от друга внешне одинаковые объекты, я поставлю на них метки (сделаю их внешне разными).
6 дек 06, 18:08    [3501174]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
!
Guest
foobar
Александр Савинов
доступ к объекту не может быть организован на основе его свойств

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


свойство=метка
6 дек 06, 18:46    [3501383]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
Александр Савинов
Member

Откуда:
Сообщений: 173
foobar
Александр Савинов
доступ к объекту не может быть организован на основе его свойств

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

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

Допустим теперь мы хотим создать свои собственные идентификаторы, например, состоящий из двух полей: Имя и Номер. Есть два способа:

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

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

В целом, единственное, что я хотел сказал, это то, что первый способ (идентификационные метки) это плохо, а второй способ это хорошо. Но с другой стороны, в настоящее время поддержка имеется только первого способа (и то довольно плохая, например, в РМД), а второй практически не поддерживается (за редкими исключениями).
6 дек 06, 19:12    [3501477]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
foobar
Guest
Долгота и широта тоже не идентифицируют ни одного объекта, если не считать "потусторонних" (точка, полюс, экватор). Потустороннее не интересно.
6 дек 06, 19:41    [3501550]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
ModelR
Member

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

доступ к объекту не может быть организован на основе его свойств
Во как. Но все же
Александр Савинов
Есть два способа:
...
первый способ (идентификационные метки) это плохо, а второй способ это хорошо
Ну слава богу.
Александр Савинов
Долгота и широта позволяет добраться до данной точке на земле, но ведь в этой точке эти координаты нигде не закопаны.
Отличный пример. Запоминаем долготу и широту автомобиля, идем по ссылке, а там уже пусто. Ибо мы запомнили ссылку на точку в нами же сконструированном адресном пространстве а не на объект.
Никто не призывает создавать СУБД игнорирующие модель памяти. Нужно лишь понимать, что идентифицирует ссылка и что данные.
Данные плохо - их часто просто недостаточно для иденификации и облом - нельзя второго <глаза=хитрые, руки=длинные, религия=РМД> добавить. Ну и отмеченные Вами минусы. И указатели плохо - они гарантированно что-то идентифицируют, вставляйте хоть мульон <глаза=хитрые, руки=длинные, религия=ОМД> пока памяти хватает, но может все же задуматься о недостаточности набора свойств, а не о том как их засандалить несмотря ни на что.
6 дек 06, 19:44    [3501559]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 3 4 5 6 7 [8] 9 10 11 12 .. 31   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить