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

Более формально, если идем в направлении ссылки, то это проекция. Если обратно (инверсия), то это де-проекция. Вся структура будет упорядоченным множеством. Все это будет аналогично обычному многомерному пространству с иерархией.



Пацталом!!!!

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


Цитата Булгакова
+200

зы Прошу прощения за офтопик, сдержаться просто немогу.
8 дек 06, 18:37    [3512554]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
!
Guest
Александр Савинов
!
Вас все устраивает в PK-FK , то что не устраивает,
великолепно реализуется сурагантым ключем без дополнительных накладных расходов.

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



Любая РСУБД выполнит это требование в том виде в котором задан вопрос.

Прежде чем спрашивать о том что вам нужно, потрудитесь
найти в документации по любой РСУБД, что такое PK(primary key)
и FK(foreign key).
8 дек 06, 18:48    [3512607]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
!
Guest
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 ;}
И сократиь код введя обозначение Account.FK1.age вполне можно.
Т.е. оперируя со всеми данными как равными мы получаем максимальную гибкость.


У таблицы в РСУБД не может быть 2 PK
( это может быть лазейкой для нарушения нормализации)
, но может быть 1 PK и сколько угодно уникальных констреинтов.
Количество FK ограничено физической реализацией СУБД.
8 дек 06, 19:41    [3512765]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
pavelvp
Member

Откуда:
Сообщений: 673
ModelR
Посему доступ - не поиск.
Хм... Поиск - не доступ. Доступ - не поиск.
В таком случае, что такое B-tree, hash etc. access methods?
8 дек 06, 20:02    [3512825]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
Александр Савинов
Member

Откуда:
Сообщений: 173
pavelvp
ModelR
Посему доступ - не поиск.
Хм... Поиск - не доступ. Доступ - не поиск.
В таком случае, что такое B-tree, hash etc. access methods?

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

Действительно в точу, кто то из участников этого форумa явно PhD "с университетским образованием"
8 дек 06, 20:20    [3512867]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
pavelvp
Member

Откуда:
Сообщений: 673
Александр Савинов
pavelvp
В таком случае, что такое B-tree, hash etc. access methods?
Это реализация таблицы разрешения, т.е. функции, которая преобразует из "более опосредованного" в "менее опосредованное" представление. Обычно в конце хотят получить непосредственное представление для т.н. прямого доступа, например, номер записи или адрес содержимого в памяти.
Не нужно рассказывать мне что это такое. Вы просто посмотрите на терминологию - access methods. Все индексные структуры есть методы доступа. Это устоявшийся термин не имеющий, в общем случае, никакого отношения к БД. Думаю Вы не будете отрицать, что индексы суть поиск?
8 дек 06, 20:28    [3512897]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
nooo
Guest
Александр Савинов
как это не странно звучит, но PK-FK в РМД это ведь НЕ средство доступа, а ограничение целостности, а это не одно и то же.

Александр, это сделано вот для чего. Когда вы поместите идентификатор вместо FK, может случится так, что объект, на который он указывает находится в компьютере вождя племени Дрочидопота, занятого более важными вещами, чем предоставление доступа входящим идентификаторам. Поэтому, без шансов предугадать все ваши намерения, при помощи простых математических выражений вам, наоборот, запрещают думать о непотребном. Все остальное делать можно, это называется реализация. Целостность данных в терминах РМД будет нарушена если у вас есть доступ к идентификатору и нет доступа к объекту, видимо с этой целью вы их и разделили. А пока целостность не нарушается, РСУБД не перестают быть "Р", неужели это так сложно понять. Я вижу "адресное пространство" имело успех, предлагаю еще несколько интуитивных ассоциаций. Доступ: механизм, протокол, разграничение, средства контроля, управления, аудита. Употребляйте на здоровье - все телки будут ваши. Да, вместо "ссылка" можно говорить "фхтагн" - смысл не меняется, а как заводит!
8 дек 06, 20:39    [3512920]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
Александр Савинов
Member

Откуда:
Сообщений: 173
pavelvp
Александр Савинов
pavelvp
В таком случае, что такое B-tree, hash etc. access methods?
Это реализация таблицы разрешения, т.е. функции, которая преобразует из "более опосредованного" в "менее опосредованное" представление. Обычно в конце хотят получить непосредственное представление для т.н. прямого доступа, например, номер записи или адрес содержимого в памяти.
Не нужно рассказывать мне что это такое. Вы просто посмотрите на терминологию - access methods. Все индексные структуры есть методы доступа. Это устоявшийся термин не имеющий, в общем случае, никакого отношения к БД. Думаю Вы не будете отрицать, что индексы суть поиск?

В индексе, который используется для поиска, заданное (индексируемое) свойство объекта играет роль ссылки. Т.е. индекс, который используется для доступа разрешает легальные, явно объявленные, ссылки (например, ключ в БД или ссылки Явы в адрес в памяти). А индекс, который используется для поиска берет какие-то свойства объекта и далее отображает спектр их значений опять же в базовые ссылки. Сам индекс при этом ничего не знает о том, для чего он используется - это просто быстрое отображение. А вот для чего это отображение используется, это уже другой вопрос - можно для разрешения (легальных) ссылок, а можно для разрешения произвольных свойств.
8 дек 06, 20:45    [3512937]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
!
Guest
Александр Савинов

В индексе, который используется для поиска, заданное (индексируемое) свойство объекта играет роль ссылки. Т.е. индекс, который используется для доступа разрешает легальные, явно объявленные, ссылки (например, ключ в БД или ссылки Явы в адрес в памяти). А индекс, который используется для поиска берет какие-то свойства объекта....

Не какие-то, а вполне конкретные.

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

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

В индексе, который используется для поиска, заданное (индексируемое) свойство объекта играет роль ссылки. Т.е. индекс, который используется для доступа разрешает легальные, явно объявленные, ссылки (например, ключ в БД или ссылки Явы в адрес в памяти). А индекс, который используется для поиска берет какие-то свойства объекта....

Не какие-то, а вполне конкретные.

Дальше без политры понять невозможно.

Возможно. От градуса многое завсит.

1. Индекс выполняет отображение из пространства значений А в пространство значений Б. Он ничего не знает ни об объектах, ни о ссылках, ни о чем другом.
2. В качестве А могут использоваться совершенно любые свойства, которые имеют отношение к объекту, в т.ч. свойства ссылки и сущности. Индексу по барабану как элементы этого пространства интерпретируются - эти роли приписываются извне.
3. В качестве Б используются ссылки: либо примитивные, либо нет.

Почему это называется поиском объектов?
Потому, что пространство Б это пространство ссылок. Когда ссылка найдена, то можно считать, что найден объект (см. ниже). Т.е. ссылка возвращается тому, кто ищет, а он уже может использовать ее для доступа.

Почему это называетися доступом к объекту?
Потому, что, если пространство А это ссылка, то тогда мы говорим о доступе по ссылке. Получена примитивная ссылка в Б - можно объект доступать.

Если и это непонятно, то я сдаюсь. Разбирайтесь сами. У терминов поиск и доступ м.б. еще миллион интерпретаций.

А вообще, какая разница как это называется. Главное, как эта штуковина работает. А о термниах можно бесконечно спорить, по поводу чего собстсвенно народ и рубится на форумах.
8 дек 06, 23:08    [3513270]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
contr
Member

Откуда:
Сообщений: 1909
Александр Савинов
Поскольку большинство запросов пишутся всего лишь для доступа к одной записи из другой записи...

более чем смелое предположение. На грани фола.
И теме не менее, в большинстве случаев при сравнении различных моделей участники как-то акцентируются именно на обращении за единственной записью по уникальному набору атрибутов...
Если уж претендуете на псевдофундаментальность - претендуйте плиз до конца. Сравните, например, эффективность организации поиска по неключевым атрибутам, организацию нечеткого поиска или сложных аналитических отчетов, Ad-Hoc queries.
Когда говорим о современных БД, подразумеваем сотни и тысячи сущностей, миллиарды строк и десятки тысяч различных запросов. Поиск единственной записи по PK - только один из многочисленных подвидов отряда простейших.
Я бы очень хотел посмотреть на синтаксис, более лаконичный, нежели современный SQL, и при этом обладающий сравнимым набором возможностей.
И совершенно не верю в возможности сетевой модели в области организации запросов, отличных от поиска единственной записи по уникальному ключу.
11 дек 06, 02:18    [3516374]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
мод
Guest
ModelR

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

Но иногда нужна определенная жесткость:
table Account {
  ref Person Person_id;   // ссылка на человека
  ref T        T_id;          // ссылка на T
  Int           nmbr;
  ...
}

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

table T{
  String    name;
  Interger nmbr;
  int        fld;
}
select Account.*,Person.* from Account,Person where Person.rowid=Account.Person_id
// все счета человека
11 дек 06, 10:04    [3516800]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
ModelR
Member

Откуда: Нижний Новгород
Сообщений: 1798
Александр Савинов
ModelR
Нет идеала. Зато одно поле запросто участвует в нескольких ФК.

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

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

И я так думаю. Более того, я не понимаю, почему так до сих пор не сделано.
Александр Савинов
Много хлопот (имена FK нужно вводить в неймспейс таблиц, предусмотреть outer join синтаксис и др.) и ограниченная выгода
На самом деле причина есть и она лежит глубже. [...]Еще одна причина в том, что как это не странно звучит, но PK-FK в РМД это ведь НЕ средство доступа, а ограничение целостности, а это не одно и то же.
А что в этом странного?
11 дек 06, 10:11    [3516859]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
ModelR
Member

Откуда: Нижний Новгород
Сообщений: 1798
Упс... вот так верно:
Александр Савинов
ModelR
Нет идеала. Зато одно поле запросто участвует в нескольких ФК.

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

Ну, это уже вопросы вкуса - хотим, не хотим...
Александр Савинов

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

И я так думаю. Более того, я не понимаю, почему так до сих пор не сделано.
Много хлопот (имена FK нужно вводить в неймспейс таблиц, предусмотреть outer join синтаксис и др.) и ограниченная выгода
Александр Савинов
На самом деле причина есть и она лежит глубже. [...]Еще одна причина в том, что как это не странно звучит, но PK-FK в РМД это ведь НЕ средство доступа, а ограничение целостности, а это не одно и то же.
А что в этом странного?
11 дек 06, 10:20    [3516917]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
ModelR
Member

Откуда: Нижний Новгород
Сообщений: 1798
!
У таблицы в РСУБД не может быть 2 PK
( это может быть лазейкой для нарушения нормализации)
, но может быть 1 PK и сколько угодно уникальных констреинтов.
Количество FK ограничено физической реализацией СУБД.
Точнее, с точки зрения РМД все ключи (в нормализованном отношении) равноправны. Но я использовал SQL подобную нотацию, и в SQL стандарте это действительно так.
11 дек 06, 10:28    [3516966]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
!
Guest
ModelR
!
У таблицы в РСУБД не может быть 2 PK
( это может быть лазейкой для нарушения нормализации)
, но может быть 1 PK и сколько угодно уникальных констреинтов.
Количество FK ограничено физической реализацией СУБД.
Точнее, с точки зрения РМД все ключи (в нормализованном отношении) равноправны. Но я использовал SQL подобную нотацию, и в SQL стандарте это действительно так.


Если вводить такую возможность в сетевых БД ,
негативы в поддержке нормализации могут побить все и так мнимые позитивы.

На первых страницах автора( shuklin) заботил вопрос только 1 НФ,
сейчас похоже появляются проблемы и с прочими.

или ну их на...... эти НФ.

Что скажет автор( shuklin) ?

И как там с констреинтами в Cerebrum?
Я ответа пока не видел.
11 дек 06, 11:32    [3517452]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
Александр Савинов
Member

Откуда:
Сообщений: 173
ModelR
Упс... вот так верно:
Александр Савинов
ModelR
Нет идеала. Зато одно поле запросто участвует в нескольких ФК.

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

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

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

Ну, это уже вопросы вкуса - хотим, не хотим...

Совершенно верно. Только вместо слова "вкуса" я бы использовал "традиции" и "основы" подхода, на основе которых вырабатывается вкус. В этом смысле можно разделить подходы на два класса: с открытыми ссылками и с закрытыми ссылками.

ModelR
Александр Савинов
На самом деле причина есть и она лежит глубже. [...]Еще одна причина в том, что как это не странно звучит, но PK-FK в РМД это ведь НЕ средство доступа, а ограничение целостности, а это не одно и то же.
А что в этом странного?

Неувязка в том, что механизм изначально создавался как ограничение целостности, а используется он для других целей, т.е. для доступа, т.е. цель не соответствует применению. Отсюда некоторые неудобства, которые я где-то перечислил. Например, если ссылка (ключ) состоит из 100 полей. Для доступа "с открытыми сслыками" я их все вижу и должен использовать для доступа (найти соответствующие записи). А для доступа "с закрытыми сслыками" нет никакой разницы сколько в ней полей, поскольку я использую переменную и далее имя поля, а соответствующая запись находится сама с гарантией от ошибок.
11 дек 06, 11:50    [3517618]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
ModelR
Member

Откуда: Нижний Новгород
Сообщений: 1798
contr
Александр Савинов
Поскольку большинство запросов пишутся всего лишь для доступа к одной записи из другой записи...

более чем смелое предположение. На грани фола.

+1
Вот так я бы согласился:
"Если в приложении большинство запросов пишутся..." то смотрите в сторону сетевой модели.
11 дек 06, 12:00    [3517721]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
!
Guest
Александр Савинов

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


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

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

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



Что же всетаки мешает использовать сурагатный ключ?


з.ы. Этот вопрос наверное уже рваный :[|||||||||||||]: этого топика.
11 дек 06, 13:11    [3518368]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
shuklin
Member

Откуда: Харьков
Сообщений: 799
!
или ну их на...... эти НФ.

Ну почему же, втора и третья мне никогда не мешали, если их без первой применять. Они очень удобны для разделения аттрибутов по классам. Тоесть классы для экземпляров объектов в сетевой БД я выделяю чаще всего руководствуясь именно 2 & 3 NF.

!
И как там с констреинтами в Cerebrum?
Я ответа пока не видел.

В этом топике про констрейнты я не упоминал. Cerebrum это исследовательская СУБД которая доросла до состояния когда ее можно использовать не только в исследованиях, если ее ограничения не конфликтуют с постановкой задачи. Cerebrum это одна из реализаций СМД, причем не полная и развивающаяся. На данный момент констрейнты в ядре не поддерживаются. Из ограничений которые я публиковал год назад, на данный момент перестали быть актуальными - строгий Descktop Single User. Сейчас уже можно запускать в среде ASP.NET и Remoting. Появились однопользовательские undo/redo транзакции. ACID и констрейнты не поддерживаются. Вторичные индексы (аттрибутов объектов не являющихся ObjectID) практически не поддерживаются (со строкавыми индексами есть небольшой прогресс). Ну это и понятно, меня интересует разработка и проверка таких возможностей, которых нет в существующих СУБД. То что есть и уже отлажено всегда можно сделать по образу и подобию, если будут соостветсвующие рессурсы для разработки.
11 дек 06, 14:13    [3518818]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
Александр Савинов
Member

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

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


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

Правильно, т.е. то, что я и сказал.

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

Индексы и эффективность мы не рассматриваем.

!
Если сущьность( ключ) обьединяет в себе несколько положительных свойств, почемубу этими свойствами не пользоваться.
Или это религиозный вопрос?

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

Но мы говорим об удобстве тех или иных средств для тех или иных задач. Если есть запись и я хочу добраться до другой записи через ссылки по ключам, то естественным образом это записывается одной короткой строкой:
account.owner.address.street
А в РМД мне надо сделать 3 join между 4 таблицами. Если ключи достаточно толстые, то это займет одну страницу. Чувствуете разницу?

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

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

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



Что же всетаки мешает использовать сурагатный ключ?

Ничего не мешает. Это просто не относится к делу (как и большинство других Ваших комментариев). Объяснять почему нет охоты.
11 дек 06, 14:17    [3518857]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
shuklin

однопользовательские undo/redo транзакции.


плакалъ
11 дек 06, 14:20    [3518871]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
Александр Савинов
Но мы говорим об удобстве тех или иных средств для тех или иных задач. Если есть запись и я хочу добраться до другой записи через ссылки по ключам, то естественным образом это записывается одной короткой строкой:
account.owner.address.street
А в РМД мне надо сделать 3 join между 4 таблицами. Если ключи достаточно толстые, то это займет одну страницу. Чувствуете разницу?


Вы проигнорировали вопрос относительно бояна
11 дек 06, 14:24    [3518904]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
!
Guest
Александр Савинов


account.owner.address.street



Вам про Фому а вы по Ерему.

Давате порвем еще одни баян про нотации.
11 дек 06, 14:39    [3518997]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 7 8 9 10 11 [12] 13 14 15 16 .. 31   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить