 |
|
Модераторы: LSD |
 
|
|
Проблема распухания ключа в производных таблицах 
| CyraxZ |
|
|||
 Опытный  Профиль Группа: Участник Сообщений: 251 Регистрация: 10.12.2006 Репутация: нет Всего: нет |
Некоторая таблица Т1 имеет простое ключевое поле П1 (т.н. "суррогатный" ключ в терминологии учебников по БД). Некоторая дочерняя таблица Т2 имеет составной ключ, одно из полей которого - поле П1 в роли вторичного ключа. В третью таблицу в состав ключа помимо составного ключа таблицы Т2 входит некоторый простой ключ ещё одной таблицы Т8. Далее 4-я таблица (производная от 3-й), к которой добавляем ещё одно поле в состав ключа. И т.д. В зависимости от предметной области составной ключ некоторой таблицы может распухать до 5-6 полей, как в моём случае.
Например, ключ может сотоять из полей: Код сотрудника (FK) Код столбца некоторого документа Код (номер) строки документа Год Код вида работ (FK) Т.е. таблица хранит значения полей некоторой таблицы (документа), относящейся к некоторому сотрднику при выполнении некоторого вида работ в таком-то году. Т.е. вполне обычная ситуация. Можно ввести простой уникальный ключ, а все эти 5 полей перегнать в число неключевых полей. Есть какие-нибудь общепринятые рекомендации ? |
|||
|
||||
Загрузка ...
| Magnifico |
|
|||
|
Опытный Профиль Группа: Участник Сообщений: 418 Регистрация: 23.1.2008 Где: Московская област ь Репутация: 1 Всего: 17 |
т.е
имеем Эксель книгу: Эксель ( АйДиКниги, Название книги ) ЛистыКниги ( АйДиКниги, АйДиЛиста, НазваниеЛиста ) ЯчейкиЛиста ( АйДиЛиста, АйДиЯчейки, ЗначениеЯчейки ) при select t3. ЗначениеЯчейки from Эксель t1 inner join ЛистыКниги t2 on t1.АйДиКниги = t2.АйДиКниги inner join ЯчейкиЛиста t3 on t2.АйДиЛиста = t3.АйДиЛиста мы однозначно идентифицируем ЗначениеЯчейки определеного листа определенной книги (т.е спускаемся по уровню иерархии) зачем нам (по твоему примеру) добавлять в таблицу ЯчейкиЛиста -> АйДиКниги: так: ЯчейкиЛиста ( АйДиКниги, АйДиЛиста, АйДиЯчейки, ЗначениеЯчейки ) переизбыток ключевых полей добавим таблицу Формулы: Формула ( АйДиЯчейки, АйДиФормулы, НазваниеФормулы ) зачем нам сюда запихивать: АйДиКниги, АйДиЛиста Мы же не собираемся выбирать данные только из одной последней таблицы. или у кого есть другое мнение - будет интерсно ? -------------------- Всё в порядке - спасибо зарядке ! |
|||
|
||||
| CyraxZ |
|
|||
|
Опытный Профиль Группа: Участник Сообщений: 251 Регистрация: 10.12.2006 Репутация: нет Всего: нет |
Ничего не понял...
|
|||
|
||||
| Magnifico |
|
|||
|
Опытный Профиль Группа: Участник Сообщений: 418 Регистрация: 23.1.2008 Где: Московская област ь Репутация: 1 Всего: 17 |
у тебя примерно такая структура
http://ipicture.ru/Gallery/Viewfull/994096.html можно добавить доп. таблицу чтобы разгрузить таблицу Записи http://ipicture.ru/Gallery/Viewfull/994100.html -------------------- Всё в порядке - спасибо зарядке ! |
|||
|
||||
| Akina |
|
|||
|
Советчик Профиль Группа: Модератор Сообщений: 20581 Регистрация: 8.4.2004 Где: Зеленоград Репутация: 13 Всего: 454 |
И вот это "распухание ключей" делается исключительно для того, чтобы при выборках оставаться в рамках одной таблицы, а не использовать связывание? Как по мне, так это чистый бред. Пора отвыкать от грязных стилей программирования времен Clipper Summer...
-------------------- О(б)суждение моих действий - в соответствующей теме, пожалуйста. Или в РМ. И высшая инстанция - Администрация форума. |
|||
|
||||
| CyraxZ |
|
|||
|
Опытный Профиль Группа: Участник Сообщений: 251 Регистрация: 10.12.2006 Репутация: нет Всего: нет |
Akina, не знаю, что такое Clipper Summer, но ты, как я понял, категорически против естественных ключей. Здесь стоит выбор между распуханием естественных ключей и длинным связыванием при выборках (в моём случае придётся связывать 3 таблицы в случае с суррогатными ключами против 1 таблицы в случае с естественным ключом из 5 полей). Оказывается, в нете этот вопрос уже обсасан от и до: http://www.sqlbooks.ru/readarticle.aspx?pa...file=design01_1 http://www.sqlbooks.ru/readarticle.aspx?pa..._2&sm=id1_2 http://ru.wikipedia.org/wiki/Суррогатный_ключ http://www.sdteam.com/?tid=709 Итог: однозначное решение в пользу суррогатных ключей... |
|||
|
||||
| Akina |
|
||||||
|
Советчик Профиль Группа: Модератор Сообщений: 20581 Регистрация: 8.4.2004 Где: Зеленоград Репутация: 13 Всего: 454 |
Я - за оптимальность. Иногда такие ключи оптимальны, иногда нет. Да и критерии оптимальности в разных случаях различны - то скорость нужна, то компактность...
Вас пугает связывание трех таблиц? ну тогда я пас...
То есть решение Вы уже приняли, и оставалось только подогнать под него факты. ИМХО. -------------------- О(б)суждение моих действий - в соответствующей теме, пожалуйста. Или в РМ. И высшая инстанция - Администрация форума. |
||||||
|
|||||||
| CyraxZ |
|
||||
|
Опытный Профиль Группа: Участник Сообщений: 251 Регистрация: 10.12.2006 Репутация: нет Всего: нет |
Нисколько. Но оба варианта имеют свой вес.
Решение я принял, когда почитал эти статьи. Для большинства баз данных оптимальным решением являются суррогатные ключи, что обосновывается в тех статьях. Моя база данных - не исключение (никакой экзотики)... |
||||
|
|||||
|
|
| Правила форума "Общие вопросы по базам данных" | |
|
|
Данный форум предназначен для обсуждения вопросов о базах данных не попадающих под тематику других форумов:
Данный форум не предназначен для:
Если вы не соблюдаете эти правила, не удивляйтесь потом не найдя свою тему/сообщение.
Полезные советы: Если Вам понравилась атмосфера форума, заходите к нам чаще! С уважением, LSD, Zloxa. |
| 1 Пользователей читают эту тему (1 Гостей и 0 Скрытых Пользователей) | |
| 0 Пользователей: | |
| « Предыдущая тема | СУБД, общие вопросы | Следующая тема » |
[ Время генерации скрипта: 0.1119 ] [ Использовано запросов: 21 ] [ GZIP включён ]
Реклама на сайте Информационное спонсорство
|
|
По вопросам размещения рекламы пишите на vladimir(sobaka)vingrad.ru
Отказ от ответственности Powered by Invision Power Board(R) 1.3 © 2003 IPS, Inc. |