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

Ну должна, как это относится к указателям/связям ?


Прямым образом. Если вы поддерживаете 2,3 НФ то связи,
устанавливаемые между обьектами должны контролироваться
для соблюдения целостности данных в соответствии с НФ.

Сервер должен предотвращать возможность нарушения НФ,
если эта связь имеет место быть.

Если хотите, может завести полее мощьный констреинт на
проверку .

Типа :

crate table  person
(.....);
create table deptart
(.....);
create table phone_faxes
(.....);

create reference ..........

restrict  by  3nf(person, deparrt, phone_faxes) by  references( < список связей>);

Сильно не бейте , я хочу передать смысл идеи.
11 дек 06, 18:58    [3520873]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
shuklin
Member

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

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

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


АПП это самый верхний уровень логики.

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

Такая СУБД ничем не отличается от файловой системы.
Где, поле - файл
запись - директория 1 уровня
таблица - директория 2 уровня
и тд.
Почитайте маны про команду ln в unix и вы
поймете что ничего изобретать уже не нужно.

Там Иделогия связей уже реализована,
И ничего нового в развитии модели как таковой 14 страниц
обсуждения не дали.
11 дек 06, 20:07    [3521082]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
!
Guest
shuklin
!
Сильно не бейте , я хочу передать смысл идеи.

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

Всеже я опять не понял предлагаемую идею.


А Какая система может определить функционалые связи автоматически?

Вам не кажется что вы и себя и других заводите в рамки
дилемы о том что первичнее яйцо или курица?

Эти зависимости задаются при создании схемы конкретного приложения.
Разботчик приложения точно задает
что и как и с чем должно состоять в каких связях.
11 дек 06, 20:39    [3521130]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
Александр Савинов
1. Суррогатный ключ привинтили к РМД сбоку, причем как ряз для борьбы с теми проблемами, о которых здесь идет речь. Признавая полезность СК, Вы признаете наличие этих проблем. (Логика, однако.)

2. СК не имеет структуры, а мы как раз говорим о толстых ключах с внутренней структурой. Это одна из основ РМД, т.е. есть набор колонок, часть из которых объявляется ключем.

3. СК не дает нам типизацию, поскольку это примитивная ссылка, как Object в Яве.

4. Даже при наличии СК мы вынуждены заниматься соединенем таблиц вручную.

5. СК это шаг в сторону ОО.

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


Согласен со всеми пунктами, но это приводит нас к сакраметальному вопросу:

Вам шашечки или ехать ???

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

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

Откуда:
Сообщений: 9365
преспособлено читать как приспособлено

И со 2 пунктом я согласился, пожалуй слишком поспешно. Бредовый пункт, правильно mir говорит
12 дек 06, 09:17    [3521910]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
мод
Guest
Александр Савинов

account.owner.address.street
не присутствуют поля ссылок, причем мы не знаем, есть таковые или их нет.

Имхо неверно. Д.б так
*account.owner.address.street
или так
persons(account.owner).address.street
т.е. account.owner имеет тип указателя на persons и перед применением его надо разименовать
отсюда следует что и все дальнейшие рассуждения не верны.
12 дек 06, 09:31    [3521971]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
мод
Guest
Gluk (Kazan)
Единственное отличие СК от набившего всем оскомину ОО идентификатора, то что он хранится с данными и доступен приложению. До сих пор никто внятно не объяснил почему это плохо ???

Плохо, потому что не нужно. Пусть его хранит СУБД, а уж приложению он точно не д.б. доступен.
12 дек 06, 09:55    [3522096]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
Павел Воронцов
Member

Откуда: Новосибирск
Сообщений: 2402
Блог
Александр Савинов
1. Суррогатный ключ привинтили к РМД сбоку, причем как ряз для борьбы с теми проблемами, о которых здесь идет речь. Признавая полезность СК, Вы признаете наличие этих проблем. (Логика, однако.)
Ссылку не подкините с описанием процесса привинчивания?
Александр Савинов
2. СК не имеет структуры, а мы как раз говорим о толстых ключах с внутренней структурой. Это одна из основ РМД, т.е. есть набор колонок, часть из которых объявляется ключем.
Как это не имеет? Есть атрибут определённого типа - это уже структура.
Александр Савинов
3. СК не дает нам типизацию, поскольку это примитивная ссылка, как Object в Яве.
Этого пассажа не понял. Что такое "не даёт типизацию"?
Александр Савинов
4. Даже при наличии СК мы вынуждены заниматься соединенем таблиц вручную.
То есть таки напильником и канатом соединяем, соединяем...
Александр Савинов
5. СК это шаг в сторону ОО.
А эта фраза, достойная занесения в анналы. Наряду с идентификацией, навигацией и семантикой.
Александр Савинов
6. Лично мне СК нравятся, и я советую их использовать как можно чаще, а лучше всегда. Они решают почти все проблемы, за исключением сложных ссылок (можно обойти) и сложных запросов (можно обойти). Но ведь мы не обсуждаем личные предпочтения, а говорим о принципиальных различиях разных подходов.
Лично мне СК не мешают и я использую их везде, где мне это удобно.
12 дек 06, 10:09    [3522165]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
мод
Gluk (Kazan)
Единственное отличие СК от набившего всем оскомину ОО идентификатора, то что он хранится с данными и доступен приложению. До сих пор никто внятно не объяснил почему это плохо ???

Плохо, потому что не нужно. Пусть его хранит СУБД, а уж приложению он точно не д.б. доступен.


Мне (как закоренелому практику) недостаточно такой аргументации. Для меня плохо - это то, что вредно
12 дек 06, 10:13    [3522182]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
okdoky
Member

Откуда:
Сообщений: 349
Александр Савинов
Этот вопрос существенно проще. Использование NATURAL JOIN это анти-паттерн (да простят меня люди за еще один, но моя вина только в том, что я говорю об этом). Почему? Да ясно ведь. Это приводит к непредсказуемым последствиям при редактировании. Ведь соединение таблиц происходит по именам (очень плохая практика). Если кто-то где-то когда-то изменить чего-то, то никто-то этого не заметит, а система будет работать неправильно. Не хочу отвлекаться, но это известный трюк в программировании, когда семантика кодируется в именах. На вид очень удобно. А проблем при развитии системы не оберешься. Изменил имя (добавил, удалил) и все, кирдык. Но никто об этом не узнает.

Итак, еще раз: использование имен для кодирования семантики (в частности, связей) плохо, поскольку результаты изменений непредсказуемы.
А что вы не используете у себя имен? Достаточно изменить имя класса и все ваши точечные запросы или обращения придется исправлять. То же самое и с полями.
R {
A a;
B b
}
Простейший переход от a к b с использованием точечной нотации
R(a).b


Кстати в Zigzag с точечной нотацией все выглядит проще. Если мы задаем отношение
R:r(A:a, B:b); 
Это одновременно означает задание отношений
A:a(R:r);
B:b(R:r);
То есть мы можем прыгать от a к b так
(A:a).R.B; 
Если изменим имя класса, все отношения также изменятся. Например
R = C;
Означает, что в БД будут такие отношения:
C:r(A:a, B:b); 
A:a(C:r);
B:b(C:r);
Можно заметить. Фактически в Zigzag отсутствуют имена отношений (таблиц). БД Zigzag это множество классов объектов произвольно связываемых между собой отношениями. К отношению можно обратиться по имени класса. Например
$printRelation(C:*)
выдаст
C:r(A:a, B:b);
12 дек 06, 10:13    [3522187]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
мод
Guest
Gluk (Kazan)
Для меня плохо - это то, что вредно

Все ненужное вредно :)
12 дек 06, 10:19    [3522218]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
мод
Gluk (Kazan)
Для меня плохо - это то, что вредно

Все ненужное вредно :)


Не стоит говорить за всех, Вам не нужны СК (предпочитаете толстые ключи и простыни запросов), прекрасно. Я использую СК постоянно. Вам не нужен Oracle - замечательно ! Но я зарабатываю на нем себе на жизнь, а не занимаюсь теоретизированием. Можете предложить какую-то альтернативу для задач биллинга, в которой были бы не нужны СК ?
Я не собираюсь отказываться от инструмента на глупейшем основании, что не кошерно хранить идентификатор вместе с данными, мне семью кормить надо.
12 дек 06, 11:06    [3522571]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
мод
Guest
Gluk (Kazan)
Я не собираюсь отказываться от инструмента на глупейшем основании, что не кошерно хранить идентификатор вместе с данными, мне семью кормить надо.

Не надо так горячится. Речь ведь шла не о нынешнем состоянии, а о гипотетических изменениях в будущих СУБД. А на сегодня все так и есть: и оракл и СК - все на месте.
12 дек 06, 11:12    [3522613]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
мод
Gluk (Kazan)
Я не собираюсь отказываться от инструмента на глупейшем основании, что не кошерно хранить идентификатор вместе с данными, мне семью кормить надо.

Не надо так горячится. Речь ведь шла не о нынешнем состоянии, а о гипотетических изменениях в будущих СУБД. А на сегодня все так и есть: и оракл и СК - все на месте.


Если честно, подобные изменения (переход а ООСУБД) представляются мне весьма сомнительными. Именно потому, что никаких существенных плюсов (на мой взгляд) они в себе не несут.
12 дек 06, 11:54    [3523026]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
mir
Member

Откуда: Томск
Сообщений: 1027
Александр Савинов
Дело в том, что NATURAL JOIN тоже привинтили к РМД для удобства
Во-первых, термин «привинтили» мне непонятен. Во-вторых, подобные крайне смелые высказывания «мимоходом» уместны только в устах крупного специалиста, широко известного своими теоретическими и практическими трудами. Вы таковым являетесь? Если нет, потрудитесь бездоказательно не бросаться словами, которые для специалистов выглядят где-то между «странно» и «очень странно» (в сторону: кому я это говорю, господи…).
Александр Савинов
сути дела это не меняет. Я бы даже сказал, что такое облегчение делает ситуацию хуже, поскольку потом уже никто не сможет разобраться, как переплетаются таблицы. Т.е. лучше уж явно все соединения прописать, чем NATURAL JOIN использовать.
Я теперь просьба. Можно попросить вас быть честным в споре и не менять свою позицию на каждом шагу? Ведь тут «все ходы записаны» и вас легко, простите, «ткнуть» в ваши же слова. А они таковы:
Александр Савинов
https://www.sql.ru/forum/actualthread.aspx?bid=10&tid=362638&pg=12#3518857
Но самое интересное, что длина это не самая большая проблема. Существенно хуже то, что в запросе на SQL будут присутствовать в явном виде все имена колонок в ключах. Это все будет повторяться из запроса в запрос, т.е. все сотни или больше запросов в системе будут содержать идентичные фрагменты (join с ключами).


https://www.sql.ru/forum/actualpost.aspx?bid=10&tid=362638&mid=3520377&p=13&act=quot#3519156

В точечной "нотации" отсутствуют имена колонок […]В РМД они явно присутствуют […]Таким образом, мы видим два принципиально разных подхода.

https://www.sql.ru/forum/actualpost.aspx?bid=10&tid=362638&mid=3520377&p=13&act=quot#3519812
В следующей строке (account.owner.address.street) не присутствуют поля ссылок […]А в РМД […] мы обязаны указать поля, по которым происходит связка таблиц.
Таким образом, позиция была выражена предельно ясно: все упирается-де в необходимость явно писать в JOIN имена колонок. И это, мол, принципиальный вопрос («мы видим два принципиально разных подхода»).

А теперь вам говорят: дорогой наш человечек, если бы вы оторвались от философских раздумий над судьбами ссылок и прочитали хоть одну хорошую книжку по РМД/SQL, вы бы узнали, что вам дают разные варианты синтаксиса соединений. Хошь с именами колонок, хошь без имен. И вся ваша «принципиальная» проблема лопается, как мыльный пузырь.

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

А говоря о практике, вы все время пропадаете впросак. То у вас значения ключа в индексе почему-то играет роль ссылки, то вы про наличие суррогатных ключей забываете (и вам про это два дня пытаются втолковать), то вы не знаете о существовании INNER JOIN…
Александр Савинов
mir
Суррогатные ключи встречаются и на уровне ER-модели, которая к РМД не имеет отношения. Это проблема сущностей со слабой идентификацией. Следовательно, суррогатные ключи не изобретение РМД, и никто их там не привинчивал.
Как не привинчивали, если Вы сами утверждаете, что это инородное тело?
Приведите, будьте ласковы, ссылочку на мои слова, где я называл суррогатные ключи «инородным телом». Или вы перешли к приписыванию собеседнику того, что он не говорил?
Александр Савинов
Ну ладно, прибили гвоздями к бедной РМД, у которой и без этого страданий много. Или веревкой привязали. Так больше нравится?
С точки зрения лингвистики, много синонимов вы привели. Тезаурус у вас нормальный. Но вот тут мне кто-то сказал, что у нас не лингвистический форум, а технологический. И я как сугубый технарь не понимаю, что означает в контексте баз данных, что СК к РМД «прибили гвоздями» или «веревкой привязали». Извольте говорить строгим техническим языком, а то ваши мысли пока понять невозможно.
Александр Савинов
Не "Кодд с Дейтом" а просто Кодд, поскольку Дейт, как известно, популяризатор, интерпретатор и сказочник. А автор только Кодд.
Это отдельная тема, но все же скажу пару слов. Родоначальник РМД Кодд, но вы думаете, он один всю теорию разработал? Вам фамилии Армстронг, Хит, Фейгин, Чамберлен, Бойс, Бернштейн, Заниоло, Дарвен что-нибудь говорят? Коли вам «хорошо известно», что Дейт всего лишь популяризатор, тогда скажите, чьи идеи в 3 Манифесте он популяризировал, желательно со ссылкой на источник. Ну, а насчет «сказочника»… Более четко и аргументировано излагающего автора я, пожалуй, не читал. И уж конечно, у него в трудах не встретишь упоминание магии. А вот у вас, напомню, «доступ это магическая процедура». Так сравнивая вас и Дейта (господи, прости), сказочником-то вы выходите.
Александр Савинов
Ну во-первых, мне действительно лень запросы на страницу делать, если можно в одну строку.
Во-вторых, тот, кто за это платит вовсе не в восторге, что я буду целый день пару запросов составлять.
Мне, как SQL-щику с многолетним стажем, данные фразы со всей очевидностью показывают, что вы сколько-нибудь серьезные запросы вообще не писали. И, кстати, я уже показывал вам, что ваш гипотетический синтаксис в реальных запросах с большой вероятностью увеличит их размер и сложность. Даже если использовать не NJ, а обычный IJ.
Александр Савинов
В-третьих, и главное, дело не в возможности обойти проблему, а в том, чтобы ее идентифицировать и найти кардинальное решение.
Вы сначала определитесь, в чем проблема. А то у вас с этим, как оказалось, проблема (типа, каламбур :)). А то станете строго определять проблему, и выяснится, что проблемы никакой нет. Или есть, но в ваших познаниях.
Александр Савинов
Я сам могу десяток способов придумать, как избежать головных болей создаваемых РМД.
А что, РМД у вас вызывает прямо-таки головную боль? А кто же это писал: «меня не очень интересует РМД вообще и ее критика в частности».
Вновь вы неискренни.
Александр Савинов
Следуя Вашей логике, проблемы программирования на ассемлере решаются хорошой средой проектирования. А высокоуровневые языки не нужны. А вот я так не думаю.
Да уж, опять приписываете мне какие-то странные мысли. Это у вас хорошо выходит.

Александр Савинов
Итак, еще раз: использование имен для кодирования семантики (в частности, связей) плохо, поскольку результаты изменений непредсказуемы.
Во-первых, в серьезная система проектируется так, чтобы первичные кдючи измениять не приходилось. Во-вторых, в сербезной системе строгое и неукоснительно использование системы именования объектов и строгий регламент внесения изменений в структуру БД просто обязательны.
А у вас кто-то вот просто «взял и изменил имя» и «никто об этом не узнает».
Зачем вы теоретизируете о том, в чем не имеете достаточно опыта?
12 дек 06, 13:03    [3523680]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
Александр Савинов
Member

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

account.owner.address.street
не присутствуют поля ссылок, причем мы не знаем, есть таковые или их нет.

Имхо неверно. Д.б так
*account.owner.address.street
или так
persons(account.owner).address.street
т.е. account.owner имеет тип указателя на persons и перед применением его надо разименовать
отсюда следует что и все дальнейшие рассуждения не верны.

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

Кроме того, я не понял, почему дальнейшие рассуждения не верны. Ведь как со звездой так и без нее, характерным свойством точечной записи является то, что структура ссылок в ней эффективно скрыта, т.е. можно работать с данными независимо от способа их представления и доступа. Звездочка это уже непринципиальные детали (я не исключаю, что иногда этот оператор может быть полезен).
12 дек 06, 13:08    [3523716]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
shuklin
Member

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


А Какая система может определить функционалые связи автоматически?

Вам не кажется что вы и себя и других заводите в рамки
дилемы о том что первичнее яйцо или курица?

Эти зависимости задаются при создании схемы конкретного приложения.
Разботчик приложения точно задает
что и как и с чем должно состоять в каких связях.


Ну так и я об этом. Ограничения бизнес модели - дело приложения. БД может помогать в этом приложению, но это с абстрактной точки зрения не обязательно. Т.е. ограничения целостности в контексте этой дискуссии вещь вторичная.
12 дек 06, 13:18    [3523842]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
Александр Савинов
Member

Откуда:
Сообщений: 173
okdoky
Александр Савинов
Этот вопрос существенно проще. Использование NATURAL JOIN это анти-паттерн (да простят меня люди за еще один, но моя вина только в том, что я говорю об этом). Почему? Да ясно ведь. Это приводит к непредсказуемым последствиям при редактировании. Ведь соединение таблиц происходит по именам (очень плохая практика). Если кто-то где-то когда-то изменить чего-то, то никто-то этого не заметит, а система будет работать неправильно. Не хочу отвлекаться, но это известный трюк в программировании, когда семантика кодируется в именах. На вид очень удобно. А проблем при развитии системы не оберешься. Изменил имя (добавил, удалил) и все, кирдык. Но никто об этом не узнает.

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

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

Конкретный пример (совершенно реальный, т.е. использующий реально существующую технологию, но упрощенный для целей обсуждения). У вас есть множество транзакциональных методов, перед вызовом которых надо открыть транзакцию, а по окончании закрыть. Вы не хотите каждый раз этим заниматься, и вполне обоснованно (методов много, дублирование кода и т.п.) Один способ автоматизации состоит в следующем. В имя метода вписываете слово transactional, например, creditAccount_transactional, debitAccount_transactional и т.д. Далее препроцессор будет находить такие методы и вставлять нужный код. Для других методов надо проверять полномочия, и тогда в именя вставляем secure: getAddress_secure. Важно, что в именах собственно зашита логика поведения. Теперь представьте, что кто-то добавит свой метод с такими компонентами в имени, или сделает ошибку в написании метода. Компилятор это скушает и все будет нормально работать. А это ОЧЕНЬ плохо.

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

1. Явно перечислять все колонки ключа в join это плохо.
2. Обходить эту проблему с помощью NATURAL JOIN еще хуже, поскольку мы решаем одну проблему, но вводим еще более серьезную.
12 дек 06, 13:40    [3524087]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
Александр Савинов
Member

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

Кстати в Zigzag с точечной нотацией все выглядит проще. Если мы задаем отношение
R:r(A:a, B:b); 
Это одновременно означает задание отношений
A:a(R:r);
B:b(R:r);

A и B относятся как много-к-много через R?
Что означает производное отношение A:a(R:r)? Там для каждого a из A хранится ссылка на соотв. r из R?

okdoky
То есть мы можем прыгать от a к b так
(A:a).R.B; 

Оператор "прыгать" даст в данном случае множество объектов из B?

Если так, то мне это нравится. Единственное, что бы я изменил, так это использование имен полей вместо имен отношений. Имена отношений м.б. неоднозначны, поскольку между двумя классами м.б. несколько путей по разным полям.

okdoky
Можно заметить. Фактически в Zigzag отсутствуют имена отношений (таблиц). БД Zigzag это множество классов объектов произвольно связываемых между собой отношениями.

А если мне надо две таблицы одного класса?
12 дек 06, 13:58    [3524240]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
мод
Guest
Gluk (Kazan)

Если честно, подобные изменения (переход а ООСУБД) представляются мне весьма сомнительными.

Ну, ООСУБД тут и не пахнет. А вот так писать разве плохо:
select a.*,b.* from a,b where a.rowid=b.id_a
12 дек 06, 14:34    [3524603]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
vadiminfo
Member

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

То же самое с NATURAL JOIN, поскольку в соответствии имен зашита логика связи.

Это верно. Но если в соединении участвуют проекции таблов, т.е. запросы с фиксированным списком полей (строго только те которые нужны), изменение, которых приведет к сообщениям ошибке (конечно если такие имена не дадут другим столбцам), то вероятность подобной траблы снижается, а NATURAL JOIN повышает читаемость в больших запросах заметно. Что может иметь значение. А проекция имеет смысл для большей строгости. Кроме того, он хорош для разовых запросов (которые не входят в приложение, например, админ статистику смотрит).
Конечно, использование NATURAL JOIN в стиле, в котором не делают проекции ради экономии времени (звездочку поставить быстрее, чем выписывать нужные поля) на написание чревато.
12 дек 06, 14:44    [3524702]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
Gluk (Kazan)
Member

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

select a.*,b.* from a,b where a.rowid=b.id_a


Плохо. Это означает, что столбец b должен содержать значение rowid.
Работать будет до первого экспорта.

Если уж так хочется сэкономить на соединении, можно построить кластер (в Oracle)
12 дек 06, 14:46    [3524713]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
мод
Guest
Александр Савинов
Исполоьзование звездочки ничего не добавляет к функциональности,

Это как ? Указатель и содержимое - это одно и то же ?
account.owner.address.street
Ваша нотация неверна: street это св-во address но address не является св-ом owner.
Всегда в любом языке ссылка должна отличаться от своего содержимого.
12 дек 06, 14:51    [3524776]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
мод
Guest
Gluk (Kazan)

Плохо. Это означает, что столбец b должен содержать значение rowid.
Работать будет до первого экспорта.

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