ReSQL.ru
     
powered by simpleCommunicator - 2.0.60     © 2026 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Чем плоха связь "многие ко многим"...?
66 сообщений из 66, показаны все 3 страниц
  все  
Чем плоха связь "многие ко многим"...?
    #33263856
Фотография Дедушка
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Дедушка
Участник
Добрый день.
В умных книгах советуют... если обнаруживается связь "многие ко многим" между таблицами вводить дополнительную табл. связки и связывать через неё по "один ко многим". Подскажите что при этом мы выигрываем...?
Спасибо.
...
Рейтинг: 0 / 0
12.09.2005, 12:46
| Ответить | Цитировать | Написать  
Чем плоха связь "многие ко многим"...?
    #33263878
Фотография Валентин К
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Валентин К
Участник
Сугубо мое мнение.
Что значит если нашли? вопрос исходит от задачи, если нужно сделать такую таблицу - то брать ее и делать. Конечно можно разделить ее на 2 или 3 штуки. Но тут стоит узнать как работает сервер с таблицами. Некоторые сервера быстрее отбрабатывают 1 таблицу по индексам, нежели связку нескольких по индексам.
Поэтому такое утверждение как аксиома не корректно. Нужно смотреть конкретный случай.
На практике таблицы многие-ко-многим делаю, если это наиболее оптимальное решение в проектировании и до сих пор в этом не разочаровался.

Что вы от этого выиграете?
Можно выиграть немного в быстродействии, а можно и проиграть.
...
Рейтинг: 0 / 0
12.09.2005, 12:52
| Ответить | Цитировать | Написать  
Чем плоха связь "многие ко многим"...?
    #33263922
Фотография Дедушка
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Дедушка
Участник
Сервер MSSQL2K.
Есть табл. "Клиенты" и "Адреса". У одного клиента может быть много адресов и на одном адресе может быть зарегистрированно много клиентов... Вопрос: как лучше... оставить две эти табл. и связать по "Клиент.id" и тогда в табл. "Адреса" будут множественные записи по клиенту либо создать табл. связки где будут только id-шники клиентов и адресов правда тоже множественные записи и не очень понятно в чём выигрыш...??
...
Рейтинг: 0 / 0
12.09.2005, 13:03
| Ответить | Цитировать | Написать  
Чем плоха связь "многие ко многим"...?
    #33263983
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
Дедушка Подскажите что при этом мы выигрываем...?
В основном то, что связь "многие ко многим" обычно не поддерживается напрямую механикой сервера БД и приходится использовать тот или иной трюк.Таблица развязки - наиболее популярный из таких трюков и пожалуй наиболее корректный с точки зрения "духа реляционной теории".

ДедушкаЕсть табл. "Клиенты" и "Адреса". У одного клиента может быть много адресов и на одном адресе может быть зарегистрированно много клиентов... Вопрос: как лучше... оставить две эти табл. и связать по "Клиент.id" и тогда в табл. "Адреса" будут множественные записи по клиенту
Если Вы свяжете их по "Клиент.id", в таблице "Адреса" не будет "много клиентов на одном адресе" - если меня не глючит и MSSQL еще не научился делать массивов в полях. Будут "много клиентов на совпадающих адресах".

Дедушкалибо создать табл. связки где будут только id-шники клиентов и адресов правда тоже множественные записи и не очень понятно в чём выигрыш...??
Относительно скорости, как справедливо заметил Валентин, вопрос неоднозначный. Выигрыш, я бы сказал, в простоте и универсальности такой структуры - она легко воспринимается, к ней легко писать любые запросы, чаще всего она достаточно эффективна.
...
Рейтинг: 0 / 0
12.09.2005, 13:21
| Ответить | Цитировать | Написать  
Чем плоха связь "многие ко многим"...?
    #33264003
zayac
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
zayac
Участник
Дедушка... в табл. "Адреса" будут множественные записи по клиенту...
Как вы это собираетесь сделать ? В табл. "Адреса" завести текстовое поле "Список Клиентов" и записывать в него id клиентов через запятую ?
Недостатков такого подхода достаточно.
1. Как выяснить адрес клиента, зная его id ?
select IdCli from address where my_func(IdCli)=1
(в данном примере функция my_func возвращает 1 если в поле "Список Клиентов" есть id данного клиента, и 0 - если его там нет)
полный просмотр таблицы адресов с вызовом функции my_func для каждой записи
(я не знаю можно или нет строить идекс по функции в MSSQL2K)
2. Нельзя организовать ссылоную целосность.
2.1. В поле "Список Клиентов" можно добавить id несуществующего клиента (или писать триггер).
2.2. При удалении клиента необходимо пройтись по всей таблице "Адреса" и обновлять все поля "Список Клиентов" где присутствует данный id клиента.
2.3. При удалении записи из "Адреса" необходимо опять же обеспечить сохранение ссылочной целосности (чтобы не получить клиентов без адреса).

При создании таблицы связей и foreign key - всех этих проблем просто не будет.
...
Рейтинг: 0 / 0
12.09.2005, 13:25
| Ответить | Цитировать | Написать  
Чем плоха связь "многие ко многим"...?
    #33264025
Фотография Валентин К
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Валентин К
Участник
Афтор темы - ответьте пож-ста на следующий вопрос.
Какие отрицательнае факторы вы видите в создании таблицы многие-ко-многим, поддержании целостности данных и работе с этой таблицей?
Какие вы ожидаете положительные качества от разделения этой таблицы?

Это вопросы на уровне концепции реализации этого кусочка предметной области.
...
Рейтинг: 0 / 0
12.09.2005, 13:30
| Ответить | Цитировать | Написать  
Чем плоха связь "многие ко многим"...?
    #33264055
Templar
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Templar
Участник
Дедушка Добрый день.
В умных книгах советуют... если обнаруживается связь "многие ко многим" между таблицами вводить дополнительную табл. связки и связывать через неё по "один ко многим". Подскажите что при этом мы выигрываем...?
Спасибо.
Попробуйте сначала найти как минимум еще одно решение, а потом уже определять, что выигрываем/проигрывеам.
...
Рейтинг: 0 / 0
12.09.2005, 13:38
| Ответить | Цитировать | Написать  
Чем плоха связь "многие ко многим"...?
    #33264173
Фотография Дедушка
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Дедушка
Участник
Если использовать пример с табл-ми "Клиенты" и "Адреса" то конечно связь многие к многим реализуется как множественные записи т.е для разных Клиент.id повторяется один Адрес...
Тогда желая получить все адреса клиента мы делаем выборку из "Адреса" по конкретному Клиент.id и получаем список адресов клиента, обратно работает для получения всех клиентов с этим адресом...
Во многих толстых книгах по построению БД советуют такие сущности разделять через табл. связки, но ни где толком не объясняется почему?? Вчём проблема при такой организации БД (с нормализацией что ли...)??
Этот вопрос для меня тёмный поэтому и спрашиваю...
...
Рейтинг: 0 / 0
12.09.2005, 14:10
| Ответить | Цитировать | Написать  
Чем плоха связь "многие ко многим"...?
    #33264242
zayac
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
zayac
Участник
Напишите пример.
Код: plaintext
1.
2.
3.
4.
5.
6.
create table ADDRESS...
create table CLIENT...

insert into ADDRESS...
...
insert into CLIENT...
...
так чтобы был клиент с одним адресом и клиент с тремя адресами
и так чтобы был адрес для по которому находиться один клиент и адрес по которому находиться три клиента.
И select-ы которыми вы получаете
Дедушка...желая получить все адреса клиента мы делаем выборку из "Адреса" по конкретному Клиент.id и получаем список адресов клиента, обратно работает для получения всех клиентов с этим адресом...
...
Рейтинг: 0 / 0
12.09.2005, 14:33
| Ответить | Цитировать | Написать  
Чем плоха связь "многие ко многим"...?
    #33264318
Фотография Дедушка
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Дедушка
Участник
Ну условно...
Клиенты:
Клиент_ид
Имя

Адрес:
Адрес_ид
Клиент_ид
Город
Адрес1

Пример:
Клиенты:
1*****Путин
2*****Иванов

Адрес:
1*****1*****Москва*****Кремль
2*****1*****Моск.обл.*****Борвиха
3*****2*****Москва*****Кремль
4*****2*****Моск.обл.*****Борвиха

Запрос получить все адреса Путина:
select Клиент.Имя, Адрес.Город, Адрес.Адрес1
from Адрес left outer join Клиент on Адрес.Адрес_ид=Клиент.Адрес_ид
where Клиент.Имя='Путин'

В другую сторону получить имена всех клиентов проживающих в кремле:
select Клиент.Имя, Адрес.Город, Адрес.Адрес1
from Клиент left outer join Адрес on Клиент.Адрес_ид=Адрес.Адрес_ид
where Адрес.Адрес1='Кремль'
...
Рейтинг: 0 / 0
12.09.2005, 15:01
| Ответить | Цитировать | Написать  
Чем плоха связь "многие ко многим"...?
    #33264330
ModelR
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ModelR
Участник
zayacНапишите пример.
Код: plaintext
1.
2.
3.
4.
5.
6.
create table ADDRESS...
create table CLIENT...

insert into ADDRESS...
...
insert into CLIENT...
...
так чтобы был клиент с одним адресом и клиент с тремя адресами
и так чтобы был адрес для по которому находиться один клиент и адрес по которому находиться три клиента.
И select-ы которыми вы получаете
[/quot]
Главное - Адрес, по которому пока нет ни одного Клиента и Клиента, чей Адрес не известен. Независимое существование адресов и клиентов и обеспечивается сущностью АдресКлиента.
...
Рейтинг: 0 / 0
12.09.2005, 15:05
| Ответить | Цитировать | Написать  
Чем плоха связь "многие ко многим"...?
    #33264338
Фотография Дедушка
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Дедушка
Участник
В предыдущем очепятка... :) Связка по Клиент_ид.
...
Рейтинг: 0 / 0
12.09.2005, 15:07
| Ответить | Цитировать | Написать  
Чем плоха связь "многие ко многим"...?
    #33264361
ModelR
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ModelR
Участник
Дедушка Ну условно...

Адрес:
Адрес_ид
Клиент_ид
Город
Адрес1

Адрес:
1*****1*****Москва*****Кремль
2*****1*****Моск.обл.*****Борвиха
3*****2*****Москва*****Кремль
4*****2*****Моск.обл.*****Борвиха

Вот в этом и вопрос - является ли Адрес у нас самостоятельной сущностью?
В вашем примере нет - таблицу правильнее назвать АдресКлиента. А собственно Адрес без привязки к Клиенту отсутствует.
...
Рейтинг: 0 / 0
12.09.2005, 15:15
| Ответить | Цитировать | Написать  
Чем плоха связь "многие ко многим"...?
    #33264369
Фотография Дедушка
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Дедушка
Участник
ModelR
Главное - Адрес, по которому пока нет ни одного Клиента и Клиента, чей Адрес не известен. Независимое существование адресов и клиентов и обеспечивается сущностью АдресКлиента.
В данной системе не предполагается Клиента без адреса и Адреса без клиента... Т.е разделение связи многие ко многим через табл. связи актуально если необходимо независимость сущностей Клиент и Адрес??
...
Рейтинг: 0 / 0
12.09.2005, 15:18
| Ответить | Цитировать | Написать  
Чем плоха связь "многие ко многим"...?
    #33264386
Фотография Дедушка
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Дедушка
Участник
Мне казалось, что грабли в чём то другом...
Ну вот пример из pubs-а где табл. "Авторы" и "Названия книг". Везде говорится, что это многие ко многим и поэтому будем разделять через связку. Хотя очевидно, что не будет авторов без книг и книг без авторов...
Вот и вопрос ПОЧЕМУ ПОЭТОМУ ...??
...
Рейтинг: 0 / 0
12.09.2005, 15:22
| Ответить | Цитировать | Написать  
Чем плоха связь "многие ко многим"...?
    #33264408
zayac
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
zayac
Участник
У вас неправильное представление о практической реализации связи "многие ко многим". Тут явно видна избыточность.

Адрес:
1*****1*****Москва*****Кремль
2*****1*****Моск.обл.*****Борвиха
3*****2*****Москва*****Кремль
4*****2*****Моск.обл.*****Борвиха
(Кстати, почему у [Моск.обл.*****Борвиха] два различных Адрес_ид - 2 и 4 ?)

Если будет 1000 клиентов из Борвихи надо будет писать (согласно вашему примеру):
2*****1*****Моск.обл.*****Борвиха
4*****2*****Моск.обл.*****Борвиха
5*****3*****Моск.обл.*****Борвиха
..............
1001*****1000*****Моск.обл.*****Борвиха

а в таблице Адрес кроме полей Город,Адрес1 может быть еще штук 30 полей.
В таблице Адрес должна быть только одна запись [Моск.обл.*****Борвиха]

Причем еще и второй пример нерабочий.
select Клиент.Имя, Адрес.Город, Адрес.Адрес1
from Клиент left outer join Адрес on Клиент.Адрес_ид=Адрес.Адрес_ид
where Адрес.Адрес1='Кремль'
В таблице Клиент у вас нет поля Адрес_ид. Если вы его туда вставите то получиться (опять же следуя вашей логике):
1*****1*****Путин
2*****1*****Иванов
3*****2*****Путин
4*****2*****Иванов
тоже самое что и с адресами.


Должно быть:
Клиенты:
1*****Путин
2*****Иванов

Адрес:
1*****Москва*****Кремль
2*****Моск.обл.*****Борвиха

Связь_Адрес_Клиент:
Адрес_ид
Клиент_ид

Наполнение:
1*****1
1*****2
2*****1
2*****2
...
Рейтинг: 0 / 0
12.09.2005, 15:30
| Ответить | Цитировать | Написать  
Чем плоха связь "многие ко многим"...?
    #33264446
zayac
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
zayac
Участник
ДедушкаВ данной системе не предполагается Клиента без адреса и Адреса без клиента... Т.е разделение связи многие ко многим через табл. связи актуально если необходимо независимость сущностей Клиент и Адрес??
ModelR сделал абсолютно верное замечание. Если удалить всех ваших клиентов из Борвихи - то и Борвиха прекратит свое существование. Если вы именно этого и добиваетесь - объединяйте таблицы "Адрес" и "Клиент". (Опять же - будет некоторая избыточность).
ДедушкаНу вот пример из pubs-а где табл. "Авторы" и "Названия книг". Везде говорится, что это многие ко многим и поэтому будем разделять через связку. Хотя очевидно, что не будет авторов без книг и книг без авторов...
Мне это не очевидно. Если у нас книжный склад - то имеем таблицу "Книга" в которой есть поля "Название книги" и "Автор". Потому что различных книг у которых один и тоже автор на книжном складе несколько штук. Но если мы говорим о библиотеке, в которой выделяются полки на конкретных авторов (классиков) - то уже имеет смысл говорить о разделении "Книга"/"Автор".
...
Рейтинг: 0 / 0
12.09.2005, 15:44
| Ответить | Цитировать | Написать  
Чем плоха связь "многие ко многим"...?
    #33264454
ModelR
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ModelR
Участник
Дедушка Мне казалось, что грабли в чём то другом...
Ну вот пример из pubs-а где табл. "Авторы" и "Названия книг". Везде говорится, что это многие ко многим и поэтому будем разделять через связку. Хотя очевидно, что и книг без авторов...
Вот и вопрос ПОЧЕМУ ПОЭТОМУ ...??
"Никогда не говори никогда". Поверив, что не будет авторов без книг, сделаем информацию об авторе полями в Книге.
Если мы удалим информацию про книгу, автор которой является автором единственно этой книги, то потеряем информацию про автора, а также про его адреса и т.д. А он возьмет и напишет еще, и придется снова его забивать.
И еще, задачи меняются. Однажды обнаружится, что кроме авторства, человек нам интересен по другим основаниям (сотрудник, подрядчик, критик). Поэтому изначально разумно выделить человека как сущность:

Человек ( ЧелИД, ФИО, ...),
Книга (КнИД, Наименование,...)
Авторство (ЧелИД,КнИД)
Рецензирование (ЧелИД,КнИД)

Именно об этих моментах обычно пишут в книгах....
...
Рейтинг: 0 / 0
12.09.2005, 15:46
| Ответить | Цитировать | Написать  
Чем плоха связь "многие ко многим"...?
    #33264467
Фотография Дедушка
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Дедушка
Участник
to: zayac
Ну хорошо... но ведь в табл. "Связь_Адрес_Клиент" тоже множественные записи
пусть 1000 клиентов из Борвихи тогда:
1*****1
.
.
.
1000*****1
И основная проблем в том, что в табл. "Адрес" есть ещё 30 полей... насколько я понял... но ведь поиск будет по индексу??
Т.е избыточность по айдишникам лучше чем по любым другим полям??
...
Рейтинг: 0 / 0
12.09.2005, 15:50
| Ответить | Цитировать | Написать  
Чем плоха связь "многие ко многим"...?
    #33264505
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
ДедушкаТ.е избыточность по айдишникам лучше чем по любым другим полям??
Безусловно. Но помимо всего прочего, это не будет избыточностью; это будет как раз минимально необходимой записью соответствующего факта.
...
Рейтинг: 0 / 0
12.09.2005, 16:06
| Ответить | Цитировать | Написать  
Чем плоха связь "многие ко многим"...?
    #33264524
Фотография Дедушка
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Дедушка
Участник
ModelR Дедушка Мне казалось, что грабли в чём то другом...
Ну вот пример из pubs-а где табл. "Авторы" и "Названия книг". Везде говорится, что это многие ко многим и поэтому будем разделять через связку. Хотя очевидно, что и книг без авторов...
Вот и вопрос ПОЧЕМУ ПОЭТОМУ ...??
"Никогда не говори никогда". Поверив, что не будет авторов без книг, сделаем информацию об авторе полями в Книге.
Если мы удалим информацию про книгу, автор которой является автором единственно этой книги, то потеряем информацию про автора, а также про его адреса и т.д. А он возьмет и напишет еще, и придется снова его забивать.
И еще, задачи меняются. Однажды обнаружится, что кроме авторства, человек нам интересен по другим основаниям (сотрудник, подрядчик, критик). Поэтому изначально разумно выделить человека как сущность:

Человек ( ЧелИД, ФИО, ...),
Книга (КнИД, Наименование,...)
Авторство (ЧелИД,КнИД)
Рецензирование (ЧелИД,КнИД)

Именно об этих моментах обычно пишут в книгах....

Спасибо.
Но при таком построении для занесения новой записи Автор-Книга нужно провести скан табл. Автор на предмет есть ли уже такой, затем скан табл. Книга собственно за тем же... и только потом произвести запись в табл. связку. При сущностях Клиент Адрес единственное "за" за введение табл. связки это то, что если город или улицу переименуют то изменять придётся только одну строку вместо скажем 100-ни...
...
Рейтинг: 0 / 0
12.09.2005, 16:11
| Ответить | Цитировать | Написать  
Чем плоха связь "многие ко многим"...?
    #33264582
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
Дедушка
Но при таком построении для занесения новой записи Автор-Книга нужно провести скан табл. Автор на предмет есть ли уже такой, затем скан табл. Книга собственно за тем же... и только потом произвести запись в табл. связку.
Допустим (хотя в данном случае это вряд ли окажется именно так). Только не скан таблицы, а скан индекса. Простенькая ХП из двух операторов MERGE и вставки в связку.

Дедушка
При сущностях Клиент Адрес единственное "за" за введение табл. связки это то, что если город или улицу переименуют то изменять придётся только одну строку вместо скажем 100-ни...
Не единственное "за", но "решающее". Скажем, представьте себе запрос, который будет в Вашей схеме искать "подставные адреса", на которые зарегистрирована куча разных фирм. Вот это уж действительно будет перелопачивание абсолютно всей таблицы.
...
Рейтинг: 0 / 0
12.09.2005, 16:30
| Ответить | Цитировать | Написать  
Чем плоха связь "многие ко многим"...?
    #33264586
zayac
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
zayac
Участник
Дедушка
Ну хорошо... но ведь в табл. "Связь_Адрес_Клиент" тоже множественные записи
пусть 1000 клиентов из Борвихи тогда:
1*****1
.
.
.
1000*****1
И основная проблем в том, что в табл. "Адрес" есть ещё 30 полей... насколько я понял... но ведь поиск будет по индексу??
Т.е избыточность по айдишникам лучше чем по любым другим полям??
Основная проблема, на мой взгляд, в том что в приложении вы предлагаете человеку кроме клиента каждый раз вводить еще и реквизиты адреса. В итоге в вашей таблице адресов будет куча Борвих:
Моск.обл *****Борвиха
Моск обл *****Борвиха
Московская обл.*****Борвиха
Московская обл*****Борвиха
"Каша" в справочнике - это по-моему основная проблема. Привести все потом к единому виду очень тяжело.

Во-вторых тут нет никакой "избыточность по айдишникам". 1000 клиентов из Борвихи действительно имеют вид:
1*****1
.
.
.
1000*****1
но так и должно быть.

ДедушкаИ основная проблем в том, что в табл. "Адрес" есть ещё 30 полей... насколько я понял... но ведь поиск будет по индексу??
Хорошо, поиск по индексу. Таблица, в которой запись дублируется несколько десятков раз и занимать на диске будет в несколько десятков раз больше места.
100 Кб и 1Мб сейчас конечно несильно отличаются, но 1 Гб и 10 Гб отличаются существенно. И в запросе
select Клиент.Имя, Адрес.Город, Адрес.Адрес1
from Клиент left outer join Адрес on Клиент.Адрес_ид=Адрес.Адрес_ид
where Адрес.Адрес1='Кремль'
для тысячи "Кремлевских" клиентов будет в сотни раз больше чтений с жесткого диска (достаточно дорогая операция) если адрес дублируется тысячу раз, чем при обращении к таблице где только одна такая запись. Индекс тут помагает, но панацеей не является.
Таблица связи в свою очередь гораздо меньше чем таблица адресов. При доступе по индексу для тысячи клиетов "Кремлевских" будет пара чтений с диска для индекса и одино чтение для таблицы "Адрес".
...
Рейтинг: 0 / 0
12.09.2005, 16:30
| Ответить | Цитировать | Написать  
Чем плоха связь "многие ко многим"...?
    #33265151
ModelR
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ModelR
Участник
Дедушка Спасибо.
Но при таком построении для занесения новой записи Автор-Книга нужно провести скан табл. Автор на предмет есть ли уже такой, затем скан табл. Книга собственно за тем же... и только потом произвести запись в табл. связку. При сущностях Клиент Адрес единственное "за" за введение табл. связки это то, что если город или улицу переименуют то изменять придётся только одну строку вместо скажем 100-ни... Именно так, в частности если у Клиента изменился адрес - ищем новый в Адрес, не нашли - добавляем новую запись в Адрес и обновляем АдресКлиента. Эту технологию легко можно проследить практически в любой системе от 1С и до R/3.
Изменение связи адреса с клиентом в корне отличается от изменения характеристик собственно адреса, например, данный дом почтовая служба передала другому почтовому отделению или, как вы говорите переименовали улицу.
...
Рейтинг: 0 / 0
12.09.2005, 22:19
| Ответить | Цитировать | Написать  
Чем плоха связь "многие ко многим"...?
    #33265181
funikovyuri
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
funikovyuri
Участник
Дедушка

Покажите мне эти ваши книжки где сказано что многи ко многим надо избегать!? Единственное что там может быть сказано, так это что такая связь при близком рассмотрения сама по себе является сущностью.
...
Рейтинг: 0 / 0
12.09.2005, 22:59
| Ответить | Цитировать | Написать  
Чем плоха связь "многие ко многим"...?
    #33292208
Sergey M
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Sergey M
Участник
Templar Дедушка Добрый день.
В умных книгах советуют... если обнаруживается связь "многие ко многим" между таблицами вводить дополнительную табл. связки и связывать через неё по "один ко многим". Подскажите что при этом мы выигрываем...?
Спасибо.
Попробуйте сначала найти как минимум еще одно решение, а потом уже определять, что выигрываем/проигрывеам.

а вложенные таблицы Оракловские это что не то что ли ?
...
Рейтинг: 0 / 0
28.09.2005, 07:38
| Ответить | Цитировать | Написать  
Чем плоха связь "многие ко многим"...?
    #33294732
mir
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mir
Участник
Sergey M Templar Дедушка Добрый день.
В умных книгах советуют... если обнаруживается связь "многие ко многим" между таблицами вводить дополнительную табл. связки и связывать через неё по "один ко многим". Подскажите что при этом мы выигрываем...?
Спасибо.
Попробуйте сначала найти как минимум еще одно решение, а потом уже определять, что выигрываем/проигрывеам.

а вложенные таблицы Оракловские это что не то что ли ?Не то. Это связь один ко многим, если проект правильный. То есть одной записи в мастер-таблице соответствует много записей во вложенной таблице. Если же вложенными таблицами пытаться сделать M:N, то хотя бы задумайтесь о проблемах согласованного обновления.
...
Рейтинг: 0 / 0
29.09.2005, 08:39
| Ответить | Цитировать | Написать  
Чем плоха связь "многие ко многим"...?
    #33298281
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
mir Sergey Mа вложенные таблицы Оракловские это что не то что ли ?Не то. Это связь один ко многим, если проект правильный.
Хм. Запомним.

mir То есть одной записи в мастер-таблице соответствует много записей во вложенной таблице.
Мастер - это насколько я понимаю, ведущая таблица, та, в которой есть поле типа nested table.

В таком случае я бы хотел увидеть пример "неправильного" проекта, в котором процитированное здесь утверждение не выполняется. Ну или понять, к чему было сказано про правильное/неправильное.
...
Рейтинг: 0 / 0
30.09.2005, 13:16
| Ответить | Цитировать | Написать  
Чем плоха связь "многие ко многим"...?
    #33300619
mir
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mir
Участник
softwarer mir Sergey Mа вложенные таблицы Оракловские это что не то что ли ?Не то. Это связь один ко многим, если проект правильный.
Хм. Запомним.

mir То есть одной записи в мастер-таблице соответствует много записей во вложенной таблице.
Мастер - это насколько я понимаю, ведущая таблица, та, в которой есть поле типа nested table.

В таком случае я бы хотел увидеть пример "неправильного" проекта, в котором процитированное здесь утверждение не выполняется. Ну или понять, к чему было сказано про правильное/неправильное.Ну, скажем, храним данные о проектах и разработчиках. В проекте много разработчиков, разработчик участвует в нескольких проектах.
Правильно: таблица "Разработчики", таблица "Проекты", таблица связности "Разработчики в проектах".
Неправильно: таблица "Разработчики" с полем типа nested table "Проекты разработчика". Или же таблица "Проекты" с полем типа nested table "Разработчики проекта". Надо ли объяснять, почему?
...
Рейтинг: 0 / 0
03.10.2005, 10:09
| Ответить | Цитировать | Написать  
Чем плоха связь "многие ко многим"...?
    #33301137
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
Во-первых, попрошу таки ответить на заданный вопрос. Напомню его:

softwarer mir То есть одной записи в мастер-таблице соответствует много записей во вложенной таблице.
В таком случае я бы хотел увидеть пример "неправильного" проекта, в котором процитированное здесь утверждение не выполняется. Ну или понять, к чему было сказано про правильное/неправильное.

Надо ли объяснять, почему?
Было бы интересно услышать, чем неправильна таблица "Проекты" с полем "Разработчики проекта" И таблица "Разработчики" с полем "Проекты разработчика".
...
Рейтинг: 0 / 0
03.10.2005, 12:54
| Ответить | Цитировать | Написать  
Чем плоха связь "многие ко многим"...?
    #33301311
Templar
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Templar
Участник
softwarerБыло бы интересно услышать, чем неправильна таблица "Проекты" с полем "Разработчики проекта" И таблица "Разработчики" с полем "Проекты разработчика".
Нарушением 1-й нормальной формы.
...
Рейтинг: 0 / 0
03.10.2005, 13:47
| Ответить | Цитировать | Написать  
Чем плоха связь "многие ко многим"...?
    #33301366
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
TemplarНарушением 1-й нормальной формы.
Затрудняюсь предположить, как именно Вас учили, поэтому попрошу уточнить, что с Вашей точки зрения нарушается.
...
Рейтинг: 0 / 0
03.10.2005, 14:05
| Ответить | Цитировать | Написать  
Чем плоха связь "многие ко многим"...?
    #33301684
mir
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mir
Участник
softwarerВо-первых, попрошу таки ответить на заданный вопрос. Напомню его:

softwarer mir То есть одной записи в мастер-таблице соответствует много записей во вложенной таблице.
В таком случае я бы хотел увидеть пример "неправильного" проекта, в котором процитированное здесь утверждение не выполняется. Ну или понять, к чему было сказано про правильное/неправильное.

Надо ли объяснять, почему?
Было бы интересно услышать, чем неправильна таблица "Проекты" с полем "Разработчики проекта" И таблица "Разработчики" с полем "Проекты разработчика".Да хотя бы тем, что пока не заведем хоть один проект, в котором участвует разработчик X, данные о нем просто некуда записать. Это в теории называется аномалией добавления. Вот вам аномалия удаления: если удалим запись о проекте, единственном пока для разработчика X, данные о нем тоже исчезнут.
А вот аномалия обновления. Если разработчик X участвует в нескольких проектах, то для каждого такого проекта он войдет в одну из записей поля-таблицы (со всеми своими атрибутами). Теперь задача: изменить адрес разработчика X. Это придется сделать во всех копиях этой записи. Если где-то не обновить, то будет рассогласование данных.
...
Рейтинг: 0 / 0
03.10.2005, 16:12
| Ответить | Цитировать | Написать  
Чем плоха связь "многие ко многим"...?
    #33301840
aZm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
aZm
Участник
softwarer TemplarНарушением 1-й нормальной формы.
Затрудняюсь предположить, как именно Вас учили, поэтому попрошу уточнить, что с Вашей точки зрения нарушается.

ну рискну, пожалуй, влезть в дискуссию :) 1я нф - атомарность атрибутов.
но... можно предусмотреть извращенную ситуацию, что вопрос, а какие проекты вел разработчик имярек1 никогда не возникнет, а список разработчиков применяется только вместе... хотя за такую модель надо вешать аналитика :) ибо, как показывает практика, таки возникнет :)
...
Рейтинг: 0 / 0
03.10.2005, 17:00
| Ответить | Цитировать | Написать  
Чем плоха связь "многие ко многим"...?
    #33302249
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
mirДа хотя бы тем, что пока не заведем хоть один проект, в котором участвует разработчик X, данные о нем просто некуда записать.
Ошибаетесь. Эта аномалия относится как раз к реализации таблицы вида ПроектыРазработчиков - там разработчик может быть добавлен только вместе с проектом.

В данном случае все просто - добавляем запись в таблицу "Разработчики", поле "Проекты разработчика" оставляем пустым. Добавление проекта без разработчиков - аналогично.

mirЭто в теории называется аномалией добавления. Вот вам аномалия удаления: если удалим запись о проекте, единственном пока для разработчика X, данные о нем тоже исчезнут.
Боюсь, не очень интересно разговаривать с человеком, который цитирует книгу, не пытаясь соотнести цитируемое предмету обсуждения.
...
Рейтинг: 0 / 0
03.10.2005, 18:53
| Ответить | Цитировать | Написать  
Чем плоха связь "многие ко многим"...?
    #33302269
Naug
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Naug
Участник
авторЭта аномалия относится как раз к реализации таблицы вида ПроектыРазработчиков - там разработчик может быть добавлен только вместе с проектом.
o.O вдумавшись пришёл к выводу что вы имеете ввиду что уже существующего разработчика нельзя внести в таблицу ПроектыРазработчиков пока он не включён в какой-либо проект. Я правильно понял? Если да, то "ну и что?"
...
Рейтинг: 0 / 0
03.10.2005, 19:00
| Ответить | Цитировать | Написать  
Чем плоха связь "многие ко многим"...?
    #33302317
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
aZmну рискну, пожалуй, влезть в дискуссию :) 1я нф - атомарность атрибутов.
Согласен. А что есть атомарность атрибутов? Грубо говоря, означает, что тип атрибута адекватен требуемым по смыслу задачи и имеющимся в распоряжении операциям; нам не нужно писать substr (field, 2, 4) чтобы взять часть композитного значения и тому подобных действий.

В данном случае - проблем нет:

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
Connected to Oracle Database 10g Enterprise Edition Release  10 . 1 . 0 . 4 . 0  
Connected as test

SQL> create type TData as object ( j integer ) ;

Type created

SQL> create type TDataTable as table of TData ;

Type created

SQL> create table NT ( i integer, subdata TDataTable ) nested table subdata store as NT_subdata ;

Table created

SQL> insert into NT values (  1 , TDataTable ( TData (  1  ), TData (  2  ), TData (  3  ))) ;

 1  row inserted

SQL> insert into NT values (  2 , TDataTable ( TData (  3  ), TData (  4  ), TData (  5  ))) ;

 1  row inserted

SQL> insert into NT values (  3 , TDataTable ( TData (  5  ), TData (  6  ), TData (  1  ))) ;

 1  row inserted

SQL> column i format a10 ;
SQL> select i from NT
   2   where exists ( select  1  from table ( cast ( subdata as TDataTable )) where j =  3  ) ;

         I
----------
          1 
          2

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

aZmно... можно предусмотреть извращенную ситуацию, что вопрос, а какие проекты вел разработчик имярек1 никогда не возникнет,
Собственно, select выше - называет номера проектов, в которых участвовал разработчик номер 3 :)
...
Рейтинг: 0 / 0
03.10.2005, 19:22
| Ответить | Цитировать | Написать  
Чем плоха связь "многие ко многим"...?
    #33302327
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
Naugo.O вдумавшись пришёл к выводу что вы имеете ввиду что уже существующего разработчика нельзя внести в таблицу ПроектыРазработчиков пока он не включён в какой-либо проект. Я правильно понял? Если да, то "ну и что?"
То, что такой таблицей будет трудно отразить некоторые реалии нашего мира. Скажем, отдел HR не сможет внести в БД принятого на работу сотрудника, пока начальник не распределит его на тот или иной проект.

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

Я не понимаю другого - мой оппонент приводит аргумент, относящийся к работе с одной таблицей, к схеме, в которой их ЧЕТЫРЕ. Собственно, три - то, что mir назвал изначально - это простой случай, целиком соответствующий обычной практике с таблицей-развязкой. Целиком - в смысле, физически генерируется именно такая структура данных. Поэтому я попросил прокомментировать более яркий пример, с денормализацией, чтобы недостатки были ярче видны.
...
Рейтинг: 0 / 0
03.10.2005, 19:30
| Ответить | Цитировать | Написать  
Чем плоха связь "многие ко многим"...?
    #33302333
Naug
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Naug
Участник
автор
То, что такой таблицей будет трудно отразить некоторые реалии нашего мира. Скажем, отдел HR не сможет внести в БД принятого на работу сотрудника, пока начальник не распределит его на тот или иной проект.
Какая одна таблица?
mirПравильно: таблица "Разработчики", таблица "Проекты", таблица связности "Разработчики в проектах".

обычная псевдо м:м развязка. И разработчиков можно сколько угодно добавлять без проектов и ссылаться на них в других отношениях (РазработчикПродукт).
...
Рейтинг: 0 / 0
03.10.2005, 19:36
| Ответить | Цитировать | Написать  
Чем плоха связь "многие ко многим"...?
    #33302913
aZm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
aZm
Участник
2 softwarer
давайте не путать теплое и мягкое :)? вложенная таблица это очень частный случай, применимый только (?) в оракл. а в общем случае, получаем тильда/комма/дот/etc сепаратед валуес, в виде строчки, которые в общем случае при помощи sql не обработать :)

---
Vae victis!
...
Рейтинг: 0 / 0
04.10.2005, 10:13
| Ответить | Цитировать | Написать  
Чем плоха связь "многие ко многим"...?
    #33303051
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
aZm2 softwarer
давайте не путать теплое и мягкое :)?
Согласен.

aZm вложенная таблица это очень частный случай, применимый только (?) в оракл.
И? Если посмотрите выше - там был задан примерно следующий вопрос: "а не являются ли оракловые вложенные таблицы альтернативой?". Вроде как начали объяснять, что не являются. Согласитесь, "общий случай" тут совершенно не при чем, и не надо путать теплое и мягкое :)
...
Рейтинг: 0 / 0
04.10.2005, 10:49
| Ответить | Цитировать | Написать  
Чем плоха связь "многие ко многим"...?
    #33303081
aZm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
aZm
Участник
softwarerИ? Если посмотрите выше - там был задан примерно следующий вопрос: "а не являются ли оракловые вложенные таблицы альтернативой?". Вроде как начали объяснять, что не являются. Согласитесь, "общий случай" тут совершенно не при чем, и не надо путать теплое и мягкое :)

полностью согласен, в теме было много букв, прочел не все . в таком контексте - вы полностью правы. кроме того, по вложенным неплохо отписался mir, добавить, право, нечего.

mir
...
Не то. Это связь один ко многим, если проект правильный. То есть одной записи в мастер-таблице соответствует много записей во вложенной таблице. Если же вложенными таблицами пытаться сделать M:N, то хотя бы задумайтесь о проблемах согласованного обновления.

однако... в классической теории вроде бы про nested tables не говорится? (хотя возможно я и ошибаюсь) следовательно, формально , это нарушение 1й нф
...
Рейтинг: 0 / 0
04.10.2005, 10:59
| Ответить | Цитировать | Написать  
Чем плоха связь "многие ко многим"...?
    #33303084
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
aZmа в общем случае, получаем тильда/комма/дот/etc сепаратед валуес, в виде строчки, которые в общем случае при помощи sql не обработать
Хотя, сугубо вредности ради:

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
Connected to Oracle Database 10g Enterprise Edition Release  10 . 1 . 0 . 4 . 0  
Connected as test

SQL> create type TStringTable as table of varchar2( 4000 ) ;

Type created

SQL> create function Parse_Comma ( Str varchar2 ) return TStringTable pipelined as
   2     p integer ;
   3     s varchar2( 4000 ) ;
   4   begin
   5     s := Str ;
   6     while s is not null loop
   7       p := InStr ( s || ',', ',' ) ;
   8       pipe row ( Trim ( SubStr ( s,  1 , p -  1  ))) ;
   9       s := Trim ( SubStr ( s, p +  1  )) ;
  10     end loop ;
  11     return ;
  12   end ;
  13   /

Function created

SQL> create table ST as
   2     select  1  i#, '1,2,3,4,5' data from dual union
   3     select  2 , '3,4,5,6,7' from dual union
   4     select  3 , '5,6,7,8,9' from dual ;

Table created

SQL> select i# from ST
   2   where exists ( 
   3     select * from table ( cast ( Parse_Comma ( data ) as TStringTable )) 
   4     where column_value =  3  ) ;

        I#
----------
          1 
          2

К чему я это все: не надо относиться к подобным вещам как к заповедям. Надо понимать, откуда они идут и следовать не букве, но духу.
...
Рейтинг: 0 / 0
04.10.2005, 11:00
| Ответить | Цитировать | Написать  
Чем плоха связь "многие ко многим"...?
    #33303101
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
aZmкроме того, по вложенным неплохо отписался mir, добавить, право, нечего.
Боюсь, неплохости этой отписки я абсолютно не понял. Такое впечатление, что mir понимает под вложенными таблицами что-то совершенно другое, нежели то, чем они в действительности являются.

aZmоднако... в классической теории вроде бы про nested tables не говорится? (хотя возможно я и ошибаюсь) следовательно, формально , это нарушение 1й нф
Следование неверно. Прежде чем показать почему - комментарий к такому методу доказательства вообще: я абсолютно уверен, что в классической теории нормализации ничего не говорится про blob поля. Значит ли это, что таблицы с такими полями заведомо не нормализованы?

А "почему" - видите ли, nested table - это на самом деле обычная детальная таблица. Если мы рассмотрим варианты: "классический" (то есть создаются таблицы А, Б и развязочная таблица А_Б) и "вложенный" (создаются таблицы А, Б и в таблице Б есть поле типа "вложенная таблица с foreign key на таблицу А") - на самом деле в БД будут созданы абсолютно эквивалентные структуры данных. Глядя на ER-ку, вообще говоря, нельзя определить, какой именно из вариантов физической реализации имеется в виду. Разница в данном случае только в синтаксисе, в том, как мы логически рассматриваем эту таблицу и как предпочитаем с ней работать.
...
Рейтинг: 0 / 0
04.10.2005, 11:08
| Ответить | Цитировать | Написать  
Чем плоха связь "многие ко многим"...?
    #33303545
_hike_
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
_hike_
Участник
Позволю себе вставить свои 5 копеек.
ИМХО все эти NESTED TABLES, магические числа в полях и т.п. есть ничто иное как отход от теории заради практической выгоды.
Ибо реляционная БД много в чем не удовлетворяет разработчиков, но все равно используется так как наиболее провереная временем. И они (разработчики) по всякому извращаются над ней (а кто сказал что это плохо) дабы подогнать под свои нужды. Иногда им в этом помагают даже производители РБД (NESTED TABLES тому пример).
автор... Прежде чем показать почему - комментарий к такому методу доказательства вообще: я абсолютно уверен, что в классической теории нормализации ничего не говорится про blob поля. Значит ли это, что таблицы с такими полями заведомо не нормализованы?
а это смотря что хранить в BLOB полях
...
Рейтинг: 0 / 0
04.10.2005, 13:12
| Ответить | Цитировать | Написать  
Чем плоха связь "многие ко многим"...?
    #33304033
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
_hike_Позволю себе вставить свои 5 копеек.
ИМХО все эти NESTED TABLES, магические числа в полях и т.п. есть ничто иное как отход от теории заради практической выгоды.
Давайте не путать божий дар с яичницей. Магические числа в полях теорией никак не покрываются (за исключением разве что некоторых случаев), а говоря об отходе в случае nested table - будьте уж добры пояснить, в чем именно, причем так, чтобы из пояснения было понятно, что Вы хотя бы приблизительно знаете, что это такое.

Практически - это примерно такой же отход от теории, как и любые доработки SQL, например появившееся относительно недавно предложение WITH.

а это смотря что хранить в BLOB полях
Вот именно что. Причем не только "что хранить", но и "как с этим работать". Как и в случае nested tables - само по себе их применение не говорит в пользу того либо другого варианта; надо смотреть, как они применены.
...
Рейтинг: 0 / 0
04.10.2005, 15:25
| Ответить | Цитировать | Написать  
Чем плоха связь "многие ко многим"...?
    #33304068
_hike_
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
_hike_
Участник
автор....надо смотреть, как они применены
абсолютно согласен но беда в том что многие (может это только я таких встречал ????) пытаются использовать NESTED TABLE абсолютно неоправдано нарушая 1 н.ф. Может все дело в названии ? Может надаром в 10ке вместо него ввели XMLType ?
...
Рейтинг: 0 / 0
04.10.2005, 15:36
| Ответить | Цитировать | Написать  
Чем плоха связь "многие ко многим"...?
    #33304076
_hike_
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
_hike_
Участник
или там от него вообще отказались ?
...
Рейтинг: 0 / 0
04.10.2005, 15:38
| Ответить | Цитировать | Написать  
Чем плоха связь "многие ко многим"...?
    #33304098
mir
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mir
Участник
softwarer mirДа хотя бы тем, что пока не заведем хоть один проект, в котором участвует разработчик X, данные о нем просто некуда записать.
Ошибаетесь. Эта аномалия относится как раз к реализации таблицы вида ПроектыРазработчиков - там разработчик может быть добавлен только вместе с проектом. С чего это? Добавляю все данные о разработчике в таблицу «Разработчики». Вы считаете, что это невозможно? Почему это отсутствие проектов помешает мне это сделать? Признайтесь, что тут вы просто ошиблись. Как раз классическая схема из 3 таблиц позволяет вводить данные по обеим сущностям полностью независимо, а затем, по необходимости, добавлять данные об их связях.

softwarerВ данном случае все просто - добавляем запись в таблицу "Разработчики", поле "Проекты разработчика" оставляем пустым. Добавление проекта без разработчиков - аналогично. Айн момент. Рассмотрим такой вариант проекта БД: таблица «Проекты» с полем «Разработчики проекта» типа nested table. Если у меня есть на бумажке данные о разработчике X, но в таблице «Проекты» пока нет записей о проектах, в которых он участвует, то куда в БД поместить данные о разработчике X? Ответ: некуда. Никакими тут пустыми полями не поможешь. Аномалия добавления налицо, а значит и парная аномалия удаления (см. мой пред. пост).

softwarer mirЭто в теории называется аномалией добавления. Вот вам аномалия удаления: если удалим запись о проекте, единственном пока для разработчика X, данные о нем тоже исчезнут.
Боюсь, не очень интересно разговаривать с человеком, который цитирует книгу, не пытаясь соотнести цитируемое предмету обсуждения.Вы можете со мной не разговаривать, но способны ли вы возразить по сути вопроса? В частности, вы ничего не сказали по поводу моего пример аномалии обновления.
Итак, рассмотрим тот же вариант проекта БД: таблица «Проекты» с полем «Разработчики проекта» типа nested table. Пусть разработчик X участвует в проектах Y и Z. Это значит, что данные о нем продублированы: одна копия в записи (таблица «Проекты») по проекту Y, другая копия в записи (таблица «Проекты») по проекту Z. Возникает возможность некорректного обновления: в одной копии данные изменили, в другой нет.

А по поводу цитирования книги... Я не держал перед глазами книгу, если вы об этом. Подобные сведения об аномалиях денормализации у каждого, по моему, в памяти, как 2*2=4. У вас разве нет?
...
Рейтинг: 0 / 0
04.10.2005, 15:43
| Ответить | Цитировать | Написать  
Чем плоха связь "многие ко многим"...?
    #33304103
_hike_
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
_hike_
Участник
автор... вместо него ввели XMLType ?
причем тут XMLType - это вообще отдельный тип.
...
Рейтинг: 0 / 0
04.10.2005, 15:45
| Ответить | Цитировать | Написать  
Чем плоха связь "многие ко многим"...?
    #33304147
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
mirС чего это? Добавляю все данные о разработчике в таблицу «Разработчики». Вы считаете, что это невозможно? Почему это отсутствие проектов помешает мне это сделать? Признайтесь, что тут вы просто ошиблись. Как раз классическая схема из 3 таблиц позволяет вводить данные по обеим сущностям полностью независимо, а затем, по необходимости, добавлять данные об их связях.
Признайтесь уж, что Вы тут ошиблись.

Да, классическая схема позволяет вводить данные независимо. Я нигде это не оспариваю. Схема с nested table, как вариант той же классической, не отличающийся ER-кой, также позволяет их вводить (что, как я понимаю, оспариваете Вы). Названный мной вариант с денормализацией (четыре таблицы вместо трех) тем более позволяет их вводить.

Вы почему-то выдвигаете претензией к такой схеме аномалию, действующую в случае одной таблицы (Проекты_И_Разработчики_Вместе). Я не понимаю Вашей логики.

mirАйн момент. Рассмотрим такой вариант проекта БД:
Айн момент. Давайте уж рассматривать те варианты дизайна, которые назывались, а не те плохие с использованием того или иного инструмента, которые можно придумать. Полагаю, Вы согласитесь с тем, что для абсолютно любого технического приема несложно придумать дизайн, использующий его, и постановку задачи, где этот дизайн будет неудачным.

mirАномалия добавления налицо, а значит и парная аномалия удаления (см. мой пред. пост).
Да, после того как Вы проведете совершенно необязательную денормализацию (в Вашем примере - слили в одну таблицу сущности Проекты и ПроектыРазработчиков) появятся аномалии.

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

mirВы можете со мной не разговаривать, но способны ли вы возразить по сути вопроса? В частности, вы ничего не сказали по поводу моего пример аномалии обновления.
Я могу обсуждать суть вопроса, но не могу возражать на виртуальный пример, не имеющий к этой сути никакого отношения. Если хотите начать какую-то новую ветвь дискуссии - начните ее явно. Например, сейчас Вы указали новый, ранее не упоминавшийся дизайн - и я согласился с его недостатками, как в случае близкого к классическому решению, так и в случае решения с nested tables.

mirА по поводу цитирования книги... Я не держал перед глазами книгу, если вы об этом. Подобные сведения об аномалиях денормализации у каждого, по моему, в памяти, как 2*2=4. У вас разве нет?
Вопрос не в том, в памяти эти данные или нет. Вопрос в том, что когда информация "из книги" выдается безотносительно обсуждаемой ситуации - возникает подозрение, что она прошла "из глаз в руки", минуя этап осмысления.
...
Рейтинг: 0 / 0
04.10.2005, 15:57
| Ответить | Цитировать | Написать  
Чем плоха связь "многие ко многим"...?
    #33304164
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
_hike_Может надаром в 10ке вместо него ввели XMLType ?
Во-первых, XMLType ввели не в десятке. Во-вторых, его ввели не вместо nested table, и даже не в дополнение, а просто независимо. В-третьих, по реализации он куда проще nested table - это попросту специфический объект, и в принципе начиная с восьмерки никто не мешал написать аналогичный и использовать - XMLType попросту является стандартным решением. Не составляет проблемы реализовать, например, HTMLType или CSVType и точно так же ими пользоваться - а вот реализовать на пользовательском уровне близкую альтернативу nested tables, боюсь, не удастся, разве что через INDEXTYPE.
...
Рейтинг: 0 / 0
04.10.2005, 16:03
| Ответить | Цитировать | Написать  
Чем плоха связь "многие ко многим"...?
    #33304178
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
_hike_
Кстати, неоправданных использований XMLType я бы ожидал встретить куда больше, нежели неоправданных использований nested tables. По той причине, что последний не дает чего-то принципиально нового; просто удобный в некоторых случаях взгляд на старое; XMLType же вызывает у пионеров крики типа "а давайте всю базу сделаем как одну таблицу с xml-ем".
...
Рейтинг: 0 / 0
04.10.2005, 16:06
| Ответить | Цитировать | Написать  
Чем плоха связь "многие ко многим"...?
    #33304266
_hike_
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
_hike_
Участник
авторДа, классическая схема позволяет вводить данные независимо. Я нигде это не оспариваю. Схема с nested table, как вариант той же классической, не отличающийся ER-кой, также позволяет их вводить (что, как я понимаю, оспариваете Вы)
А как в Вашей схеме:
автор"Проекты" с полем "Разработчики проекта" И таблица "Разработчики" с полем "Проекты разработчика"
поддерживать целосность ? Насколько я понял в Вашей схеме в "Проекты" в поле "Разработчики проекта" типа NESTED TABLE вписываются Id разработчиков и соответсвенно для "Разработчики проекта" в поле "Проекты" типа NESTED TABLE вписываются Id проектов. А разве NESTED TABLE позволяют делать на себе ограничения типа foreign key ??? Если нет то как вы собираетесь поддерживать целосность ?
...
Рейтинг: 0 / 0
04.10.2005, 16:38
| Ответить | Цитировать | Написать  
Чем плоха связь "многие ко многим"...?
    #33304532
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
_hike_А разве NESTED TABLE позволяют делать на себе ограничения типа foreign key ??? Если нет то как вы собираетесь поддерживать целосность ?
Тут наблюдается забавная картина - к сожалению, у меня нет под рукой базы, на которой я рискну прогнать соответствующий скрипт, чтобы продемонстрировать.

"Обычный" foreign key специально запрещен к созданию над nested tables. У меня есть подозрение, что дело тут в маркетинге, в продвижении объектных технологий, поскольку если создать его хакерским образом, он работает (я когда-то делал такой эксперимент). Вместо этого предполагается к использованию аналогичный "объектный" constraint (object ref / scope for). Полагаю, в следующих версиях разблокируют и нормальную возможность - поскольку сейчас имхо ясно, что "объектность" особым спросом не пользуется.
...
Рейтинг: 0 / 0
04.10.2005, 17:49
| Ответить | Цитировать | Написать  
Чем плоха связь "многие ко многим"...?
    #33305144
mir
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mir
Участник
softwarer mirС чего это? Добавляю все данные о разработчике в таблицу «Разработчики». Вы считаете, что это невозможно? Почему это отсутствие проектов помешает мне это сделать? Признайтесь, что тут вы просто ошиблись. Как раз классическая схема из 3 таблиц позволяет вводить данные по обеим сущностям полностью независимо, а затем, по необходимости, добавлять данные об их связях.
Признайтесь уж, что Вы тут ошиблись. Да, классическая схема позволяет вводить данные независимо. Я нигде это не оспариваю. Ну, если так, то по этому пункту у нас согласие. Возможно, я вас здесь не так понял.
softwarerСхема с nested table, как вариант той же классической, не отличающийся ER-кой, также позволяет их вводить (что, как я понимаю, оспариваете Вы). Названный мной вариант с денормализацией (четыре таблицы вместо трех) тем более позволяет их вводить.
Вы почему-то выдвигаете претензией к такой схеме аномалию, действующую в случае одной таблицы (Проекты_И_Разработчики_Вместе). Я не понимаю Вашей логики. Все просто. Вы писали: softwarerБыло бы интересно услышать, чем неправильна таблица "Проекты" с полем "Разработчики проекта" И таблица "Разработчики" с полем "Проекты разработчика".Я понял это как просьбу прокомментировать недостатки обоих вариантов:
Вариант 1: таблица "Проекты" с полем "Разработчики проекта"
Вариант 2: таблица "Разработчики" с полем "Проекты разработчика".
Как я теперь предполагаю, вы предлагали не это, а обсуждение варианта 3: таблица "Проекты" с полем "Разработчики проекта" + таблица "Разработчики" с полем "Проекты разработчика".
Явное недопонимание друг друга, в итоге разговор о разных вариантах. Поэтому все ваши дальнейшие (довольно острые) высказывания по поводу меня я считаю следствием этого недоразумения.

Ну, а если говорить о недостатках вашего варианта (вариант 3), то об этом уже сказал _hike_: проблемы с поддержанием целостности.
...
Рейтинг: 0 / 0
05.10.2005, 07:33
| Ответить | Цитировать | Написать  
Чем плоха связь "многие ко многим"...?
    #33306060
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
mirЯвное недопонимание друг друга, в итоге разговор о разных вариантах.
Видимо, так. У Вас употреблялось слово "или", поэтому в своем тексте я специально выделил "и" - тем не менее, увы..

mirНу, а если говорить о недостатках вашего варианта (вариант 3), то об этом уже сказал _hike_: проблемы с поддержанием целостности.
_hike_ я ответил в силу своего разумения. Что ж, здесь можно написать некий минус, хотя даже в моей схеме (с четырьмя таблицами вместо трех) заметных проблем я не вижу. Это полный список?
...
Рейтинг: 0 / 0
05.10.2005, 12:48
| Ответить | Цитировать | Написать  
Чем плоха связь "многие ко многим"...?
    #33307842
mir
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mir
Участник
softwarer mirЯвное недопонимание друг друга, в итоге разговор о разных вариантах. Видимо, так. У Вас употреблялось слово "или", поэтому в своем тексте я специально выделил "и" - тем не менее, увы..
"И" я заметил, но понял так: <<чем неправильна таблица "Проекты" с полем "Разработчики проекта" И чем неправильна таблица "Разработчики" с полем "Проекты разработчика">>. Ну ладно, проехали...
mirНу, а если говорить о недостатках вашего варианта (вариант 3), то об этом уже сказал _hike_: проблемы с поддержанием целостности.
_hike_ я ответил в силу своего разумения. Что ж, здесь можно написать некий минус, хотя даже в моей схеме (с четырьмя таблицами вместо трех) заметных проблем я не вижу. Это полный список?[/quot]Ну разве что еще избыточность. То есть новые данные о том, что (существующий в базе) разработчик подключился к (существующему в базе) проекту надо добавлять в 2 места сразу. Соответственно, и удалять их надо парно, и обновлять парно. Это опять же и приводит к проблемам обеспечения целостности. То есть делать так по любому хуже, чем классическим путем.
...
Рейтинг: 0 / 0
06.10.2005, 09:12
| Ответить | Цитировать | Написать  
Чем плоха связь "многие ко многим"...?
    #33311371
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
mirНу разве что еще избыточность. То есть новые данные о том, что
OK. Что я хотел отметить - естественное следствие денормализации; то же, что можно было бы отметить у четырех обычных таблиц с теми же данными.

Соответственно, если мы теперь уберем избыточность и оставим три таблицы - останется только необходимость использовать object ref вместо foreign key. Ничего априори страшного я в этом не вижу.

mirТо есть делать так по любому хуже, чем классическим путем.
"По любому хуже" - истиной не может быть никогда, если, конечно, Вы не собираетесь отстаивать позицию "любая БД должна находиться как минимум в пятой нормальной форме".
...
Рейтинг: 0 / 0
07.10.2005, 12:51
| Ответить | Цитировать | Написать  
Чем плоха связь "многие ко многим"...?
    #33311570
mir
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mir
Участник
softwarer mirНу разве что еще избыточность. То есть новые данные о том, что OK. Что я хотел отметить - естественное следствие денормализации; то же, что можно было бы отметить у четырех обычных таблиц с теми же данными. Соответственно, если мы теперь уберем избыточность и оставим три таблицы - останется только необходимость использовать object ref вместо foreign key. Ничего априори страшного я в этом не вижу.Я не знаю, что такое object ref. Соответственно, не могу ничего сказать по поводу "страшности" его использования. Одно не могу пока понять, если есть 3 таблицы, то 2 явно "Проекты" и "Разработчики", а третья, видимо, таблица связности. Вложенных таблиц вроде в таком проекте нет. Зачем же тогда какие-то object ref вместо foreign key? Что это даст? softwarer mirТо есть делать так по любому хуже, чем классическим путем."По любому хуже" - истиной не может быть никогда, если, конечно, Вы не собираетесь отстаивать позицию "любая БД должна находиться как минимум в пятой нормальной форме".Давайте-ка проясним этот момент. Если бы я сказал только бездоказательную фразу про "По любому хуже" и больше ничего , вы бы имели полное право на ваше заявление. Однако я высказал такое резюме только после того, как высказал чисто технические аргументы по поводу того, что для приведенного мной примера все решения с вложенными таблицами имеют недостатки по сравнению с классическим решением (2 таблицы + таблица связности). Замечу только, что вы наличие этих недостатков не оспаривали (т. е. согласились). Так почему вы считаете возможным столь снисходительно поучать меня подобным образом? Я считаю, что такого не заслужил. И при чем здесь, черт возьми, 5 нормальная форма?
...
Рейтинг: 0 / 0
07.10.2005, 13:52
| Ответить | Цитировать | Написать  
Чем плоха связь "многие ко многим"...?
    #33311599
_hike_
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
_hike_
Участник
Прошу прощения за оффтоп уважаемые SOFTWARER и MIR но Вам не кажется что это уже спор ради спора ? Так сказать для самоутверждения ? ...
...
Рейтинг: 0 / 0
07.10.2005, 13:59
| Ответить | Цитировать | Написать  
Чем плоха связь "многие ко многим"...?
    #33311800
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
mirОдно не могу пока понять, если есть 3 таблицы, то 2 явно "Проекты" и "Разработчики", а третья, видимо, таблица связности. Вложенных таблиц вроде в таком проекте нет.
Отнюдь. Могут быть - три "обычных" таблицы. Могут быть - две таблицы, в одной из которых вложенная таблица связности (1).

mirОднако я высказал такое резюме только после того, как высказал чисто технические аргументы по поводу того, что для приведенного мной примера все решения с вложенными таблицами имеют недостатки по сравнению с классическим решением
Аргументы - хорошая вещь, но отличающаяся от фактов. Избыточность - относится только к одной структуре, которую я предложил как промежуточную в обсуждении, к названной выше структуре (1) - не относится. Остается целостность. Ваше подозрение по поводу ее отсутствия сводится к фразе "я не знаю, что такое object ref". Итого - обоснованных аргументов, фактов - не остается. Или я что-то пропустил?

(2 таблицы + таблица связности). Замечу только, что вы наличие этих недостатков не оспаривали (т. е. согласились).
Я не оспаривал избыточности в приведенной мной схеме - поскольку для этого ее и строил :) Относительно целостности - я отослал Вас к ответу на этот аргумент; если Вы считаете это "согласились" - хм...

Так почему вы считаете возможным столь снисходительно поучать меня подобным образом?
Хм. Каждый видит то, что он хочет. Единственное, что я могу - если хотите, постараюсь ограничить общение с Вами.

И при чем здесь, черт возьми, 5 нормальная форма?
Возможно, я здесь не понял Вас, поскольку решил, что "по любому хуже" относится в первую очередь к избыточности. А я - так не уверен, что избыточность "по любому плоха".
...
Рейтинг: 0 / 0
07.10.2005, 14:45
| Ответить | Цитировать | Написать  
Чем плоха связь "многие ко многим"...?
    #33311943
mir
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mir
Участник
softwarer mirОдно не могу пока понять, если есть 3 таблицы, то 2 явно "Проекты" и "Разработчики", а третья, видимо, таблица связности. Вложенных таблиц вроде в таком проекте нет. Отнюдь. Могут быть - три "обычных" таблицы. Могут быть - две таблицы, в одной из которых вложенная таблица связности (1). OK. В этом (последнем) случае не вижу недостатков, если при этом декларативно можно обеспечить ссылочную целостность, причем со всеми потребными вариантами реакций вроде ON DELETE/UPDATE CASCADE/RESTRICT. Если же декларативно обеспечить ссылочную целостность в полном объеме нельзя, то есть требуется написание дополнительного программного кода, то этот способ опять же хуже классического. Хотя бы за счет:
(1) дополнительных трудозатрат на написание и отладку этого кода,
(2) возможного снижения производительности, поскольку СУБД заведомо реализует декларативную RI более эффективно, чем это могут сделать приложения или даже триггеры/ХП
(3) снижения уровня управляемости системы, поскольку «размазанные» по коду действия поддержания RI сложнее контролировать.
...
Рейтинг: 0 / 0
07.10.2005, 15:26
| Ответить | Цитировать | Написать  
Чем плоха связь "многие ко многим"...?
    #33312224
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
mirесли при этом декларативно можно обеспечить ссылочную целостность, причем со всеми потребными вариантами реакций вроде ON DELETE/UPDATE CASCADE/RESTRICT
Затруднюсь сходу ответить, поскольку желание сделать каскадную операцию для меня примерно в 100% случаев означает неудачный дизайн БД.
...
Рейтинг: 0 / 0
07.10.2005, 16:34
| Ответить | Цитировать | Написать  
Чем плоха связь "многие ко многим"...?
    #33312439
ModelR
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ModelR
Участник
softwarerжелание сделать каскадную операцию для меня примерно в 100% случаев означает неудачный дизайн БД.Интересно, почему именно неудачный дизайн? Пример delete Документ cascade Строки - вроде с дизайном все в порядке и желание разумное? Другое дело, на строки еще много чего может быть навешено и каскад не прокатит, придется разбираться... - но дизайн то менять не нужно?
...
Рейтинг: 0 / 0
07.10.2005, 17:37
| Ответить | Цитировать | Написать  
Чем плоха связь "многие ко многим"...?
    #33312571
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
ModelRИнтересно, почему именно неудачный дизайн?
Статистическое наблюдение по моему личному опыту. Я не собираюсь утверждать, что "совсем никогда не нужно", но как-то оказывалось, что в каждом случае предпочтительнее другое решение.

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

ModelRПример delete Документ cascade Строки - вроде с дизайном все в порядке и желание разумное?
Не совсем. Чаще всего документ нужно не "удалять", а "перенести в архив", "пометить как ошибочно введенный" итп. И то, и другое - update. Далее, даже если говорить об удалении, обычно следует проверить какие-то бизнес-правила "можно ли удалять", которые не описываются ограничениями ссылочной целостности.

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

Код: plaintext
1.
2.
3.
4.
5.
create or replace procedure DeleteDocument ( DocumentId integer ) is
begin
  delete from Positions where document_id = DocumentId ;
  delete from Documents where document_id = DocumentId ;
end ;

и не иметь потенциальных проблем с тем, что "здесь так, а здесь иначе", или "сосед случайно и незаметно удалил половину базы".

ModelRДругое дело, на строки еще много чего может быть навешено и каскад не прокатит, придется разбираться... - но дизайн то менять не нужно?
Сейчас я пришел к использованию каскадной системы в движке системы, в разработке которой участвую. Там метаинформация грузится в память того, что можно считать "движком" или "промежуточным звеном", связи между объектами задаются так же объектами, выполняющими некоторые каскадные операции - это удобно, поскольку оказывается возможным реализовать на уровне структуры хранения многие бизнес-правила. Но в БД каскадность в результате тем более не требуется. Можно ли было бы сделать то же на уровне каскадных возможностей БД? Вряд ли; во всяком случае задача "найти объект, который не дает удалить данный, и задать вопрос, не нужно ли удалить и его тоже" вряд ли хорошо решается средствами сервера.
...
Рейтинг: 0 / 0
07.10.2005, 18:22
| Ответить | Цитировать | Написать  
66 сообщений из 66, показаны все 3 страниц
  все  
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Чем плоха связь "многие ко многим"...?
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]