Зависимые связи - хорошо ли это? / Проектирование БД

ReSQL.ru

Мобильная версия Контакт Правила FAQ Помощь

Гость

Войти | Регистрация | Профиль | Очистить

Новые сообщения | Избранное

Форумы | Пользователи | Статистика | Мод. лог | Поиск

Цитировать

Написать

Автор*:

Ввести пароль для входа

Тема*:

Сообщение

Данное сообщение тематическое

Сообщение содержит картинки или видео 18+

Автор:

ВНИМАНИЕ! На данном подфоруме действуют строгие правила. Удостоверьтесь, что ваше сообщение соответствует им!

Форум или тема закрыты для гостей. Необходима авторизация!

Загрузить последнюю сохраненную версию

Вложение:

Вставить как галерею

Максимальный размер вложений: 4,0 МБ, аудио/видео: 8,0 МБ. Картинки большего размера ужимаются, если возможно.

Введите код, изображенный на картинке. Если код нечитаемый, кликните картинку, чтобы загрузить другой вариант.

Отправляя сообщение, я выражаю свое согласие с правилами форума и принимаю пользовательское соглашение.

Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр

Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Зависимые связи - хорошо ли это?

10 сообщений из 10, страница 1 из 1

Зависимые связи - хорошо ли это?

#34427400

Vetal

Участник

Откуда: Киев

Сообщения: 1 024

Рейтинг: 0 / 0

Всем привет!

Есть издательство, выпускающие различные журналы. Соответственно, есть выпуски журналов, в каждом журнале есть страницы, на каждой странице есть материалы.

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

Другими словами, выпуск связан зависимой связью с журналом, а страница связана зависимой связью с выпуском.

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

Вот структура данных:

Код: 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.

CREATE TABLE Journal(
	jrn_id int NOT NULL PRIMARY KEY,
	jrn_data varchar( 128 )
)

CREATE TABLE Issue(
	jrn_id int NOT NULL,
	iss_id int NOT NULL,	
	iss_data varchar( 128 ))
 CONSTRAINT [PK_Issue] PRIMARY KEY CLUSTERED (jrn_id,iss_id)

ALTER TABLE Issue ADD  FOREIGN KEY(jrn_id)
REFERENCES Journal (jrn_ID)

CREATE TABLE Cover(
	jrn_id int NOT NULL,
	iss_id int NOT NULL,
	cvr_id smallint NOT NULL,
	cvr_date varchar( 128 ))
 CONSTRAINT [PK_COVER] PRIMARY KEY NONCLUSTERED (jrn_id,iss_id,cvr_id)

ALTER TABLE Cover ADD  FOREIGN KEY(jrn_id, iss_id)
REFERENCES Issue (jrn_id, iss_id)


CREATE TABLE Material(
	mtr_id char( 32 ) PRIMARY KEY,
	jrn_id int NOT NULL,
	iss_id int NOT NULL,
	cvr_id smallint NOT NULL,
	mtr_data varchar( 128 )
)

ALTER TABLE Material ADD  FOREIGN KEY(jrn_id, iss_id,cvr_id)
REFERENCES Cover (jrn_id,iss_id,cvr_id)
)

Как видите, в таблице Material внешний ключ уже состоит из трех полей jrn_id, iss_id и cvr_id. И это не одна таблица, в которой есть внеший ключ на Cover.

Подскажите, пожалуйста, нормальный ли такой подход? Или правильнее было бы создать суррогатный ключ по таблицам выпусков и страницам?

Всем заранее спасибо!

...

Рейтинг:

0 / 0

30.03.2007, 13:35

| Ответить | Цитировать | Написать

Зависимые связи - хорошо ли это?

#34427447

Lamazoid

Участник

Откуда: Оттуда

Сообщения: 388

Рейтинг: 0 / 0

Vetal
Как видите, в таблице Material внешний ключ уже состоит из трех полей jrn_id, iss_id и cvr_id. И это не одна таблица, в которой есть внеший ключ на Cover.

Подскажите, пожалуйста, нормальный ли такой подход? Или правильнее было бы создать суррогатный ключ по таблицам выпусков и страницам?

Всем заранее спасибо!
А зачем в таблице material ключ на журнал : ведь от материала к журналу можно прийти через таблицу со страницами - хотя в твоей конфигурации проще обработка данных именно с 3-мя ключами - хотя помоему налицо некоторая избыточность

...

Рейтинг:

0 / 0

30.03.2007, 13:46

| Ответить | Цитировать | Написать

Зависимые связи - хорошо ли это?

#34427545

mcureenab

Участник

Откуда: Murmansk

Сообщения: 5 968

Рейтинг: 0 / 0

Vetal
Подскажите, пожалуйста, нормальный ли такой подход? Или правильнее было бы создать суррогатный ключ по таблицам выпусков и страницам?

Подход нормальный.
Разве jrn_id , iss_id и .т.д. это не суррогатные ключи?
На счёт правильнее - вопрос оптимизации. Длинный ключ занимает больше места в БД, для составных ключей получаются громоздкие условия соединения таблиц в запросах, но имея в таблице Material поле jrn_id мы можем сразу найти Journal без длинной цепочки соединений с промежуточными таблицами, из-за некоторой избыточности БД становится более устойчивой к ошибкам и сбоям.

ИМХО, физические связи лучше реализовывать суррогатными ключами. В данном случае материалы физически связаны (напечатаны) со страницами, а страницы физически сшиты и образуют выпуск журнала. Связь выпуска с журналом логическая. О том что данная подшивка является известным журналом мы узнаём по надписи на обложке.

PS. А если статья размещена на нескольких страницах?
PPS. А что собственно интересного в странице. Ведь это по сути просто лист бумаги. Индивидуальность странице придают надписи и механическое размещение в журнеале.

...

Рейтинг:

0 / 0

30.03.2007, 14:11

| Ответить | Цитировать | Написать

Зависимые связи - хорошо ли это?

#34427636

Vetal

Участник

Откуда: Киев

Сообщения: 1 024

Рейтинг: 0 / 0

LamazoidА зачем в таблице material ключ на журнал : ведь от материала к журналу можно прийти через таблицу со страницами
В том от и дело, что у меня первичный ключ в таблице со страницами состоит из трех полей: jrn_id, iss_id и cvr_id.

...

Рейтинг:

0 / 0

30.03.2007, 14:38

| Ответить | Цитировать | Написать

Зависимые связи - хорошо ли это?

#34427668

Vetal

Участник

Откуда: Киев

Сообщения: 1 024

Рейтинг: 0 / 0

mcureenabРазве jrn_id , iss_id и .т.д. это не суррогатные ключи?
Не совсем. jrn_id содержит номер журнала, который имеет смысл в нашей компании. iss_id - это номер журнала, который везде указан в самом журнале. cvr_id - да, суррогатный.
На самом деле, я хотел спросить следующее: нормально ли использовать составной ключ jrn_id, iss_id, cvr_id для таблицы страниц, или лучше завести суррогатный ключ с одного поля для таблицы страницы?
И еще. А если бы jrn_id и iss_id были не integer, а, например, varchar(256), это бы меняло ответ на мой вопрос?

mcureenabPS. А если статья размещена на нескольких страницах?

В наших журналах этого быть не может по определению. Потому что журнал электронный.

mcureenabPPS. А что собственно интересного в странице. Ведь это по сути просто лист бумаги. Индивидуальность странице придают надписи и механическое размещение в журнеале.

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

...

Рейтинг:

0 / 0

30.03.2007, 14:46

| Ответить | Цитировать | Написать

Зависимые связи - хорошо ли это?

#34427703

зоранее благодарень

Участник

Сообщения: 5 572

Рейтинг: 0 / 0

VetalВсем заранее спасибо!

таблица "Статьи"
Таблица "Журналы"
Таблица "Публикации"

поскольку статья, в принципе, может быть запросто опубликована в разных журналах или в одном издании в разных выпусках (вариации: в одном журнале но с продолжениями)

а общая идея в том, что статья это отдельная сущность - литературное или публицистическое произведение не имеющее отношения к любому журналу до тех пор пока она именно в нем не опубликована

tblPublications

PublicationID
ArticleID
IssueID
PageNum

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

tblIssues
IssueID
MagazineID
IssueNuber
IssueDate

и таблица статей авторов

tblArticles
ArticleID
AutorID
KeyWords

...

Рейтинг:

0 / 0

30.03.2007, 14:56

| Ответить | Цитировать | Написать

Зависимые связи - хорошо ли это?

#34427729

Vetal

Участник

Откуда: Киев

Сообщения: 1 024

Рейтинг: 0 / 0

2зоранее благодарень:
Спасибо огромное за мнение! Обязательно учту на будущее.

зоранее благодарень
поскольку статья, в принципе, может быть запросто опубликована в разных журналах или в одном издании в разных выпусках (вариации: в одном журнале но с продолжениями)

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

зоранее благодарень
tblPublications

PublicationID
ArticleID
IssueID
PageNum

tblIssues
IssueID
MagazineID
IssueNuber
IssueDate

Исходя из этого, я так понимаю, вы предлагает в tblIssues все-таки за первичный ключ вы предлагаете взять простой ключ из одного поля IssueID, а не составной IssueID + MagazineID? Чем такой вариант лучше чем составной ключ? Именно этот вопрос я и задавал в моем топике.

...

Рейтинг:

0 / 0

30.03.2007, 15:02

| Ответить | Цитировать | Написать

Зависимые связи - хорошо ли это?

#34427773

зоранее благодарень

Участник

Сообщения: 5 572

Рейтинг: 0 / 0

VetalИменно этот вопрос я и задавал в моем топике.

здесь нет заведомо верного решения, ножно смотреть предметку...

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

я рекомендовал бы (и делал бы сам) именно Issue как MainTable а MagazineID как атрибут Issue

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

по IssueID можно легко поднять Magazine, также легко делать выборки за период по IssueDate, например...

ИМХО это совершенно очевидное решение

...

Рейтинг:

0 / 0

30.03.2007, 15:13

| Ответить | Цитировать | Написать

Зависимые связи - хорошо ли это?

#34460331

Vetal

Участник

Откуда: Киев

Сообщения: 1 024

Рейтинг: 0 / 0

зоранее благодаренья рекомендовал бы (и делал бы сам) именно Issue как MainTable а MagazineID как атрибут Issue
Issue - это страница журнала. А в журнале может быть много страниц. А одна страница может быть только в одном журнале. Именно поэтому Magazine является главной таблицей, а Issue ей быть не может.

...

Рейтинг:

0 / 0

13.04.2007, 18:31

| Ответить | Цитировать | Написать

Зависимые связи - хорошо ли это?

#34460356

softwarer

Участник

Откуда: 127.0.0.1

Сообщения: 51 965

Рейтинг: 0 / 0

VetalПодскажите, пожалуйста, нормальный ли такой подход?
На тему преимуществ и недостатков составных ключей уже сказано все, что можно сказать, в том числе на этом форуме, поиск в руки.

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

...

Рейтинг:

0 / 0

13.04.2007, 18:42

| Ответить | Цитировать | Написать

10 сообщений из 10, страница 1 из 1

Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Зависимые связи - хорошо ли это?

Читали тему (0):

Читали форум (0):

Пользователи онлайн (0):

start [/forum/topic.php?fid=32&msg=34427703&tid=1544608]:	0ms
get settings:	6ms
get forum list:	14ms
check forum access:	3ms
check topic access:	3ms
track hit:	169ms
get topic data:	11ms
get forum data:	2ms
get page messages:	43ms
get tp. blocked users:	1ms
others:	219ms

total:	471ms

	Необходимые cookie
	Cookie для сбора статистики
	Cookie для маркетинга и рекламы