Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате
Форум программистов > СУБД, общие вопросы > Связывание таблиц. Interbase.


Автор: dizpers 27.9.2010, 18:53
Всем добрый вечер! Подскажите пожалуйста ответ на такой вопрос. Собственно в качестве СУБД используется 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 27.9.2010, 19:23
Цитата(dizpers @  27.9.2010,  18:53 Найти цитируемый пост)
 Можно ли такое делать? 

Да, это не запрещено
Цитата(dizpers @  27.9.2010,  18:53 Найти цитируемый пост)
Меня смущает то, что поле id в таблице

Меня тоже smile 
Обычно именно его и делают ключем. И даже название ID, то как бы и подразумевает.
Цитата(dizpers @  27.9.2010,  18:53 Найти цитируемый пост)
И второй вопрос - корректно ли я выбрал в таблице (2) в качестве первичного ключа поле name (у него не указано unique)?

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

И с нормализацией, мне думается, вы тоже малость погорячилиль. Перенормализовали малость. Мне думается выделение двух сущностей тут избыточно.

Автор: dizpers 27.9.2010, 19:32
К вопросу о том, что id лучше выбирать в качестве первичного ключа. Нам препод все время втирал, что искуственные ключи - зло. (а так ли это на самом деле - и почему?) И правильно ли я понял, что поля, которые я включу в PK - автоматом будут проверяться на уникальность и UNIQUE там ставить не надо?

UPD

а что с нормализацией - в планах (для базы студентов) сделать справочники Фамилий, Имен, Отчеств, Групп, Предметов. Это я что-то загнул - или это реально оправдано?

Автор: Zloxa 27.9.2010, 19:42
Цитата(dizpers @  27.9.2010,  19:32 Найти цитируемый пост)
искуственные ключи - зло

Имеется в виду http://ru.wikipedia.org/wiki/%D0%A1%D1%83%D1%80%D1%80%D0%BE%D0%B3%D0%B0%D1%82%D0%BD%D1%8B%D0%B9_%D0%BA%D0%BB%D1%8E%D1%87?
Может быть и зло, но это не мешает его использовать повсеместно.
Следует ли использовать суррогатный ключ, когда существует ярко выраженный натуральный - большой вопрос, ответ от который зависит от конкретной задачи.
В вашем случае, тип и номер документа могут идентифицировать личность.
Однако человек может поменять паспорт, если для вашей системы он не должен при этом стать другим человеком, то выбор такого ключа не оправдан.
Цитата(dizpers @  27.9.2010,  19:32 Найти цитируемый пост)
почему?

Этот вопрос лучше адресовать преподу.
Цитата(dizpers @  27.9.2010,  19:32 Найти цитируемый пост)
 И правильно ли я понял, что поля, которые я включу в PK - автоматом будут проверяться на уникальность и UNIQUE там ставить не надо? 

PK ≡ unique + not null

Автор: Gluttton 27.9.2010, 20:29
Цитата(dizpers @  27.9.2010,  19:32 Найти цитируемый пост)
Нам препод все время втирал, что искуственные ключи - зло. 

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

dizpers, имя столбца id, как бы намекает на то, что это первичный ключ (и может даже сурогатный).

Цитата(dizpers @  27.9.2010,  18:53 Найти цитируемый пост)
в качестве первичного ключа поле name

Т.е. у двух человек с одинаковым именем быть не может?

Автор: Deniz 29.9.2010, 05:59
Цитата(Zloxa @ 27.9.2010,  21:23)
Цитата(dizpers @  27.9.2010,  18:53 Найти цитируемый пост)
 Можно ли такое делать? 

Да, это не запрещено

Я что-то упустил, с каких пор первичный ключ можно делать внешним? можно.

Добавлено @ 06:02
У него же, в обоих таблицах name первичный ключ. А далее пишет:
Цитата(dizpers @  27.9.2010,  20:53 Найти цитируемый пост)
сделать поле name внешним ключем

Автор: Zloxa 29.9.2010, 09:28
Цитата(Deniz @  29.9.2010,  05:59 Найти цитируемый пост)
Я что-то упустил, с каких пор первичный ключ можно делать внешним?

Прости что отвечаю вопросом на вопрос, но с каких пор и по каким причинам этого делать нельзя?
Код

SQL> create table a( id number primary key);
 
Table created
SQL> create table b( id number primary key, constraint b$a$fk foreign key (id) references a(id));
 
Table created


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

Добавлено через 46 секунд
Цитата(Zloxa @  29.9.2010,  09:28 Найти цитируемый пост)
но с каких пор и по каким причинам этого делать нельзя?

хотя.... может ограничение платформы?
Если да, то я нахожу его весьма странным.

Автор: Deniz 29.9.2010, 11:01
Цитата(Zloxa @  29.9.2010,  11:28 Найти цитируемый пост)
Прости что отвечаю вопросом на вопрос, но с каких пор и по каким причинам этого делать нельзя?
Извиняюсь, что-то я притормозил.
Можно делать первичный ключ еще и внешним. Ограничения платформы ни при чем.

Автор: Akella 3.10.2010, 17:33
Цитата(dizpers @  27.9.2010,  18:53 Найти цитируемый пост)
id smallint 

лучше Integer или вообще bigint

Добавлено через 55 секунд
Цитата(dizpers @  27.9.2010,  18:53 Найти цитируемый пост)
name smallint 

У человека что, имя будет состоять из цифр? О_о

Powered by Invision Power Board (http://www.invisionboard.com)
© Invision Power Services (http://www.invisionpower.com)