Форум программистов [Powered by Invision Power Board]

Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате

Форум программистов > СУБД, общие вопросы > Проблема распухания ключа в производных таблицах

Автор: CyraxZ 20.3.2008, 21:21

Некоторая таблица Т1 имеет простое ключевое поле П1 (т.н. "суррогатный" ключ в терминологии учебников по БД). Некоторая дочерняя таблица Т2 имеет составной ключ, одно из полей которого - поле П1 в роли вторичного ключа. В третью таблицу в состав ключа помимо составного ключа таблицы Т2 входит некоторый простой ключ ещё одной таблицы Т8. Далее 4-я таблица (производная от 3-й), к которой добавляем ещё одно поле в состав ключа. И т.д. В зависимости от предметной области составной ключ некоторой таблицы может распухать до 5-6 полей, как в моём случае.
Например, ключ может сотоять из полей:
Код сотрудника (FK)
Код столбца некоторого документа
Код (номер) строки документа
Год
Код вида работ (FK)

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

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

Автор: Magnifico 21.3.2008, 19:19

т.е
имеем Эксель книгу:
Эксель
(
АйДиКниги,
Название книги
)

ЛистыКниги
(
АйДиКниги,
АйДиЛиста,
НазваниеЛиста
)

ЯчейкиЛиста
(
АйДиЛиста,
АйДиЯчейки,
ЗначениеЯчейки
)

при select  t3. ЗначениеЯчейки   from Эксель t1
        inner join ЛистыКниги  t2   on t1.АйДиКниги = t2.АйДиКниги
         inner join ЯчейкиЛиста  t3   on t2.АйДиЛиста = t3.АйДиЛиста

мы однозначно идентифицируем ЗначениеЯчейки определеного листа определенной книги (т.е спускаемся по уровню иерархии)

зачем нам (по твоему примеру) добавлять в таблицу ЯчейкиЛиста  ->  АйДиКниги:
так:
ЯчейкиЛиста
(
АйДиКниги,
АйДиЛиста,
АйДиЯчейки,
ЗначениеЯчейки
)

переизбыток ключевых полей

добавим таблицу Формулы:

Формула
(
АйДиЯчейки,
АйДиФормулы,
НазваниеФормулы
)
зачем нам сюда запихивать:
АйДиКниги,
АйДиЛиста
Мы же не собираемся выбирать данные только из одной последней таблицы.

или у кого есть другое мнение  - будет интерсно ?

Автор: CyraxZ 21.3.2008, 20:13

Ничего не понял...

Автор: Magnifico 21.3.2008, 22:38

у тебя примерно такая структура

http://ipicture.ru/Gallery/Viewfull/994096.html

можно добавить доп. таблицу чтобы разгрузить таблицу Записи

http://ipicture.ru/Gallery/Viewfull/994100.html

Автор: Akina 21.3.2008, 22:54

И вот это "распухание ключей" делается исключительно для того, чтобы при выборках оставаться в рамках одной таблицы, а не использовать связывание? Как по мне, так это чистый бред. Пора отвыкать от грязных стилей программирования времен Clipper Summer...

Автор: CyraxZ 23.3.2008, 08:37

Цитата

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

Akina, не знаю, что такое Clipper Summer, но ты, как я понял, категорически против естественных ключей.
Здесь стоит выбор между распуханием естественных ключей и длинным связыванием при выборках (в моём случае придётся связывать 3 таблицы в случае с суррогатными ключами против 1 таблицы в случае с естественным ключом из 5 полей).

Оказывается, в нете этот вопрос уже обсасан от и до:
http://www.sqlbooks.ru/readarticle.aspx?part=01&file=design01_1
http://www.sqlbooks.ru/readarticle.aspx?part=01&file=design01_2&sm=id1_2
http://ru.wikipedia.org/wiki/Суррогатный_ключ
http://www.sdteam.com/?tid=709

Итог: однозначное решение в пользу суррогатных ключей...

Автор: Akina 23.3.2008, 22:21

Цитата(CyraxZ @ 23.3.2008, 09:37

)

ты, как я понял, категорически против естественных ключей

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

Цитата(CyraxZ @ 23.3.2008, 09:37

)

Здесь стоит выбор между распуханием естественных ключей и длинным связыванием при выборках (в моём случае придётся связывать 3 таблицы в случае с суррогатными ключами против 1 таблицы в случае с естественным ключом из 5 полей).

Вас пугает связывание трех таблиц? ну тогда я пас...

Цитата(CyraxZ @ 23.3.2008, 09:37

)

Оказывается, в нете этот вопрос уже обсасан от и до:
[skipped]
Итог: однозначное решение в пользу суррогатных ключей...

То есть решение Вы уже приняли, и оставалось только подогнать под него факты. ИМХО.

Автор: CyraxZ 24.3.2008, 11:24

Цитата

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

Нисколько. Но оба варианта имеют свой вес.

Цитата

То есть решение Вы уже приняли, и оставалось только подогнать под него факты. ИМХО.

Решение я принял, когда почитал эти статьи. Для большинства баз данных оптимальным решением являются суррогатные ключи, что обосновывается в тех статьях. Моя база данных - не исключение (никакой экзотики)...