![]() |
|
Модераторы: LSD |
![]()
|
|
| dizpers |
|
|||
|
Новичок Профиль Группа: Участник Сообщений: 15 Регистрация: 8.9.2009 Репутация: нет Всего: нет |
Всем добрый вечер! Подскажите пожалуйста ответ на такой вопрос. Собственно в качестве СУБД используется Interbase. Есть две таблицы, допустим такие:
1) Справочник имен id smallint not null unique, name varchar(20) not null unique первичным ключем здесь я выбрал поле name 2) Человек id smallint not null unique name smallint not null, deocument varchar(50) not null unique первичным ключем я здесь выбираю поля name и document Так вот, мне надо связать эти две таблицы. А именно сделать поле name внешним ключем, и подставлять в него поле id из таблицы "Справочник имен". Можно ли такое делать? Меня смущает то, что поле id в таблице (1) не входит в первичный ключ. И второй вопрос - корректно ли я выбрал в таблице (2) в качестве первичного ключа поле name (у него не указано unique)? Заранее спасибо. |
|||
|
||||
| Zloxa |
|
|||
|
Чо? ![]() ![]() ![]() ![]() Профиль Группа: Завсегдатай Сообщений: 3473 Регистрация: 12.9.2008 Репутация: 11 Всего: 161 |
Да, это не запрещено Меня тоже Обычно именно его и делают ключем. И даже название ID, то как бы и подразумевает.
Первичный ключ не может быть не уникален, потому всякий раз, когда вы накладываете ограничение первичного ключа, он становится уникальным. Поэтому, если Вам не нужна уникальность поля name, становится очевидным что Вы слегка погорячились. И с нормализацией, мне думается, вы тоже малость погорячилиль. Перенормализовали малость. Мне думается выделение двух сущностей тут избыточно. Это сообщение отредактировал(а) Zloxa - 27.9.2010, 19:29 -------------------- Достоверно известно, что 89% людей доверяют статистике взятой с потолка |
|||
|
||||
| dizpers |
|
|||
|
Новичок Профиль Группа: Участник Сообщений: 15 Регистрация: 8.9.2009 Репутация: нет Всего: нет |
К вопросу о том, что id лучше выбирать в качестве первичного ключа. Нам препод все время втирал, что искуственные ключи - зло. (а так ли это на самом деле - и почему?) И правильно ли я понял, что поля, которые я включу в PK - автоматом будут проверяться на уникальность и UNIQUE там ставить не надо?
UPD а что с нормализацией - в планах (для базы студентов) сделать справочники Фамилий, Имен, Отчеств, Групп, Предметов. Это я что-то загнул - или это реально оправдано? Это сообщение отредактировал(а) dizpers - 27.9.2010, 19:37 |
|||
|
||||
| Zloxa |
|
|||
|
Чо? ![]() ![]() ![]() ![]() Профиль Группа: Завсегдатай Сообщений: 3473 Регистрация: 12.9.2008 Репутация: 11 Всего: 161 |
Имеется в виду суррогатные? Может быть и зло, но это не мешает его использовать повсеместно. Следует ли использовать суррогатный ключ, когда существует ярко выраженный натуральный - большой вопрос, ответ от который зависит от конкретной задачи. В вашем случае, тип и номер документа могут идентифицировать личность. Однако человек может поменять паспорт, если для вашей системы он не должен при этом стать другим человеком, то выбор такого ключа не оправдан. Этот вопрос лучше адресовать преподу.
PK ≡ unique + not null -------------------- Достоверно известно, что 89% людей доверяют статистике взятой с потолка |
|||
|
||||
| Gluttton |
|
|||
![]() Начинающий ![]() ![]() ![]() Профиль Группа: Завсегдатай Сообщений: 1170 Регистрация: 28.8.2008 Где: Феодосия Репутация: 10 Всего: 54 |
Зло - это когда препод постоянно, что то втирает! На самом деле этот вопрос достаточно холиварен. Есть случаи, когда использования сурогатных ключей оправдано, например это может упростить создание связей между сущностями с составными первичными ключами. Так же не стоит забывать о том, что используя сурогатные ключи мы в качестве бонуса получаем таблицу в третьей нормальной форме. dizpers, имя столбца id, как бы намекает на то, что это первичный ключ (и может даже сурогатный). Т.е. у двух человек с одинаковым именем быть не может? -------------------- Слава Україні! |
|||
|
||||
| Deniz |
|
|||
|
Эксперт ![]() ![]() ![]() Профиль Группа: Завсегдатай Сообщений: 1251 Регистрация: 16.10.2004 Где: Новый Уренгой Репутация: 7 Всего: 44 |
Я что-то упустил, с каких пор первичный ключ можно делать внешним? можно. Добавлено @ 06:02 У него же, в обоих таблицах name первичный ключ. А далее пишет: Это сообщение отредактировал(а) Deniz - 29.9.2010, 11:05 -------------------- "Для того чтобы сделать шаг вперед, достаточно пинка сзади" (с) |
|||
|
||||
| Zloxa |
|
|||
|
Чо? ![]() ![]() ![]() ![]() Профиль Группа: Завсегдатай Сообщений: 3473 Регистрация: 12.9.2008 Репутация: 11 Всего: 161 |
Прости что отвечаю вопросом на вопрос, но с каких пор и по каким причинам этого делать нельзя?
Совсем другое, что ограничение перивчного ключа по полю человек.name выглядит несколько абсурдно, однако вполне допутсимо. Добавлено через 46 секунд хотя.... может ограничение платформы? Если да, то я нахожу его весьма странным. -------------------- Достоверно известно, что 89% людей доверяют статистике взятой с потолка |
|||
|
||||
| Deniz |
|
|||
|
Эксперт ![]() ![]() ![]() Профиль Группа: Завсегдатай Сообщений: 1251 Регистрация: 16.10.2004 Где: Новый Уренгой Репутация: 7 Всего: 44 |
Можно делать первичный ключ еще и внешним. Ограничения платформы ни при чем. -------------------- "Для того чтобы сделать шаг вперед, достаточно пинка сзади" (с) |
|||
|
||||
| Akella |
|
|||
![]() Творец ![]() ![]() ![]() ![]() Профиль Группа: Модератор Сообщений: 18485 Регистрация: 14.5.2003 Где: Корусант Репутация: 3 Всего: 329 |
||||
|
||||
![]()
|
| Правила форума "Общие вопросы по базам данных" | |
|
|
Данный форум предназначен для обсуждения вопросов о базах данных не попадающих под тематику других форумов:
Данный форум не предназначен для:
Если вы не соблюдаете эти правила, не удивляйтесь потом не найдя свою тему/сообщение.
Полезные советы: Если Вам понравилась атмосфера форума, заходите к нам чаще! С уважением, LSD, Zloxa. |
| 1 Пользователей читают эту тему (1 Гостей и 0 Скрытых Пользователей) | |
| 0 Пользователей: | |
| « Предыдущая тема | СУБД, общие вопросы | Следующая тема » |
|
|
По вопросам размещения рекламы пишите на vladimir(sobaka)vingrad.ru
Отказ от ответственности Powered by Invision Power Board(R) 1.3 © 2003 IPS, Inc. |