Модераторы: LSD
  

Поиск:

Ответ в темуСоздание новой темы Создание опроса
> Как правильно выбрать ключевые поля? 
V
    Опции темы
flyerTM
Дата 22.12.2007, 00:10 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Шустрый
*


Профиль
Группа: Участник
Сообщений: 54
Регистрация: 20.7.2007

Репутация: нет
Всего: нет
Всем привет!
Я в теории не силен, такая ситуация, подскажите как правильно сделать:
Есть таблица "Сотрудник" (Поля: Фамилия,Имя, Отчество,Дата рождения, Место рождения,Образование и т.п.). Первые три поля - ключевые.
Вторая таблица "Должность" (Фамилия, Имя, Отчество (как внешие ключи из первой таблицы), Наименование должности, Оклад, и т.п.)
Я слышал, что количесвто ключевых полей должно быть минимальным, да и вообще неудобно это - "таскать" в каждую таблицу (которая имеет отношение к сотруднику) по три поля. Объединять их в одно - не хотелось бы.
Мой вариант: Ввести в первую таблицу поле НомерСотрудника (неключевое, но обязательное, повторения не допускаются) и уже по этому полю свзать эту таблицу со второй. 
Я так в Аксессе реализовывал, цель достигнута - таскаем только одно поле, но хотелось бы знать правильно ли это с точки зрения теории и нет ли тут никаких подводных камней?
Спасибо! 
PM MAIL   Вверх
Deniz
Дата 22.12.2007, 08:41 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Эксперт
***


Профиль
Группа: Завсегдатай
Сообщений: 1251
Регистрация: 16.10.2004
Где: Новый Уренгой

Репутация: 7
Всего: 44
Прочитай статью, может вопрос снимется.


--------------------
"Для того чтобы сделать шаг вперед, достаточно пинка сзади" (с)
PM ICQ   Вверх
flyerTM
Дата 22.12.2007, 15:38 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Шустрый
*


Профиль
Группа: Участник
Сообщений: 54
Регистрация: 20.7.2007

Репутация: нет
Всего: нет
За статью спасибо, оч интересная, но вопрос до конца не снимается, т.к. автор предложил ввести дополнительное поле и сделать его ключевым - СК (а то поле, которое до этого было ключевым - ЕК - прописать UNIQUE), но как быть, если первоначально  ЕК - это 2 и более полей, и если вводить СК, а эти 2 и более полей сделать UNIQUE (например Фамилия, Имя, Отчество - ЕК, а КодСотрудника - СК), то по логике это будет неправильно, т.к. такая БД не позволит создать 2 сотрудников с разными фамилиями, но например с одинаковыми именами.
Поэтому я и поступил так: Поле КодСотрудника оставил неключевым, но UNIQUE,  а Фамилия, Имя, Отчество - составным ключем, т.к. именно эти 3 поля однозначно определяют сотрудника. Но не будет ли ошибочным связывать таким образом таблицы по неключевому уникальному полю КодСотрудника?
И еще, какие предложения по эффективной проверке 3 полей (Фамилия, Имя, Отчество) на повтор в БД, если не делать их ключевыми?
Спасибо!
P.S. СК - суррогатный ключ (например, КодСотрудника, т.е. поле, которое не несет смысловой нагрузки, а служит лишь для однозначного определения каждой записи таблицы). ЕК - естественный ключ - обычное ключевое поле (например, ФИО).

Это сообщение отредактировал(а) flyerTM - 22.12.2007, 15:40
PM MAIL   Вверх
LSD
Дата 22.12.2007, 15:48 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Leprechaun Software Developer
****


Профиль
Группа: Модератор
Сообщений: 15718
Регистрация: 24.3.2004
Где: Dublin

Репутация: 24
Всего: 538
Цитата(flyerTM @  22.12.2007,  15:38 Найти цитируемый пост)
т.к. такая БД не позволит создать 2 сотрудников с разными фамилиями, но например с одинаковыми именами.

Позволит, просто уникальность надо делать не по каждому полюч в отдельности, а по всем трем полям одновременно.


--------------------
Disclaimer: this post contains explicit depictions of personal opinion. So, if it sounds sarcastic, don't take it seriously. If it sounds dangerous, do not try this at home or at all. And if it offends you, just don't read it.
PM MAIL WWW   Вверх
flyerTM
Дата 22.12.2007, 15:58 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Шустрый
*


Профиль
Группа: Участник
Сообщений: 54
Регистрация: 20.7.2007

Репутация: нет
Всего: нет
А не подскажете как например в Аксессе создается уникальность по нескольким полям?
PM MAIL   Вверх
LSD
Дата 22.12.2007, 16:32 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Leprechaun Software Developer
****


Профиль
Группа: Модератор
Сообщений: 15718
Регистрация: 24.3.2004
Где: Dublin

Репутация: 24
Всего: 538
В Аксесе не знаю, но обычно достаточно при создании уникального ключа указать несколько столбцов. Например для Oracle:
Код

CREATE UNIQUE INDEX names_idx
   ON humans (first_name, last_name);



--------------------
Disclaimer: this post contains explicit depictions of personal opinion. So, if it sounds sarcastic, don't take it seriously. If it sounds dangerous, do not try this at home or at all. And if it offends you, just don't read it.
PM MAIL WWW   Вверх
Deniz
Дата 24.12.2007, 08:04 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Эксперт
***


Профиль
Группа: Завсегдатай
Сообщений: 1251
Регистрация: 16.10.2004
Где: Новый Уренгой

Репутация: 7
Всего: 44
Практически во всех нормальных СУБД синтаксис такой же, как показал LSD.
Access за нормальную СУБД не считаю.


--------------------
"Для того чтобы сделать шаг вперед, достаточно пинка сзади" (с)
PM ICQ   Вверх
flyerTM
Дата 24.12.2007, 23:52 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Шустрый
*


Профиль
Группа: Участник
Сообщений: 54
Регистрация: 20.7.2007

Репутация: нет
Всего: нет
так создается индекс или ключевое поле?
PM MAIL   Вверх
Akina
Дата 25.12.2007, 00:24 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Советчик
****


Профиль
Группа: Модератор
Сообщений: 20581
Регистрация: 8.4.2004
Где: Зеленоград

Репутация: 13
Всего: 454
Цитата(flyerTM @  22.12.2007,  16:38 Найти цитируемый пост)
Поле КодСотрудника оставил неключевым, но UNIQUE,  а Фамилия, Имя, Отчество - составным ключем, т.к. именно эти 3 поля однозначно определяют сотрудника.

Да-а-а? вы никогда не видели полных тезок-однофамильцев? а ведь бывает... и что - второго увольнять, чтобы базу данных не портил?

Никогда, слышите, НИКОГДА, БЕЗ СВЕРХ-ОСОБЫХ ПРИЧИН НЕ ДЕЛАЙТЕ КЛЮЧОМ СМЫСЛОВЫЕ ПОЛЯ! Ключ - отдельно, смысл - отдельно. Или применительно к вашей БД - ключ-счетчик (даже использование табельного номера нежелательно), а ФИО индексируйте, этого для нормального функционирования БД более чем достаточно. Даже уникальности не требуется (see above опять же).
Цитата(flyerTM @  22.12.2007,  16:58 Найти цитируемый пост)
как например в Аксессе создается уникальность по нескольким полям? 

Только программно.



--------------------
 О(б)суждение моих действий - в соответствующей теме, пожалуйста. Или в РМ. И высшая инстанция - Администрация форума.
PM MAIL WWW ICQ Jabber   Вверх
flyerTM
Дата 26.12.2007, 20:33 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Шустрый
*


Профиль
Группа: Участник
Сообщений: 54
Регистрация: 20.7.2007

Репутация: нет
Всего: нет
У ключа-счетчика есть недостаток - если я кого-нибудь удалю из БД, то этот номер уже никем никогда использоваться не будет (а наверное все имеет свой предел?) Я прав?
PM MAIL   Вверх
Akina
Дата 26.12.2007, 22:42 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Советчик
****


Профиль
Группа: Модератор
Сообщений: 20581
Регистрация: 8.4.2004
Где: Зеленоград

Репутация: 13
Всего: 454
Цитата(flyerTM @  26.12.2007,  21:33 Найти цитируемый пост)
У ключа-счетчика есть недостаток - если я кого-нибудь удалю из БД, то этот номер уже никем никогда использоваться не будет (а наверное все имеет свой предел?) Я прав?

В том что "номер" не будет использован - прав. В том, что это недостаток - нет. Это - достоинство. Он уникален - ты сам это задал в макете таблицы. И он выполняет свою функцию, пусть даже и по отношению к уже не существующей в БД записи.

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


--------------------
 О(б)суждение моих действий - в соответствующей теме, пожалуйста. Или в РМ. И высшая инстанция - Администрация форума.
PM MAIL WWW ICQ Jabber   Вверх
skyboy
Дата 26.12.2007, 22:45 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


неОпытный
****


Профиль
Группа: Модератор
Сообщений: 9820
Регистрация: 18.5.2006
Где: Днепропетровск

Репутация: 5
Всего: 260
flyerTM, это достоинства. сколько бы таблиц/полей/сущностей не ссылались на сущность с этим id, после его удаления они в худшем случае будут ссылаться на несуществующую запись, но не станут ссылаться на совсем не относящуюся к делу сущность, которой ты по ошибке присвоил тот же id. точнее, ты-то, конечно, можешь вставить запись с явно указанным значением для поля-счетчика(по крайней мере, в MySQL, FireBird/Interbase и MSSQL Server такое сделать возможно), но это будет явно твоя "вина" и ответственность будет на тебе.
PM MAIL   Вверх
ZMaximI
Дата 27.12.2007, 19:01 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Опытный
**


Профиль
Группа: Участник
Сообщений: 251
Регистрация: 18.5.2004
Где: Украина, г. Харьк ов

Репутация: нет
Всего: -1
flyerTM, почитай про реляционные БД , для начала.

какие три ключа ?????

вот первая таблица :

Код

CREATE TABLE `employees` (
  `ID` int(10) unsigned NOT NULL auto_increment, # первичный УНИКАЛЬНЫЙ ключ
  `FirstName` varchar(100) NOT NULL default '',
  `LastName` varchar(100) NOT NULL default '',
  `FathName` varchar(100) NOT NULL default '',
  PRIMARY KEY  (`ID`)
) ENGINE=MyISAM DEFAULT CHARSET=cp1251;


вот вторая :

Код

CREATE TABLE `posts` (
  `ID` int(10) unsigned NOT NULL auto_increment,
  `Employee_IDRef` int(11) NOT NULL default '0',
  `PostName` varchar(100) NOT NULL default '',
  PRIMARY KEY  (`ID`),
  KEY `FK_posts_1` (`Employee_IDRef`) # вторичный ключ, из первой таблици.
) ENGINE=MyISAM DEFAULT CHARSET=cp1251;


Это в MySQL.


--------------------
<удалено администрацией форума>
PM MAIL WWW ICQ   Вверх
  
 Ответ в темуСоздание новой темы Создание опроса
Правила форума "Общие вопросы по базам данных"
LSD
Zloxa

Данный форум предназначен для обсуждения вопросов о базах данных не попадающих под тематику других форумов:

  • вопросам по СУБД для которых нет отдельных подфорумов
  • вопросам которые затрагивают несколько разных СУБД (например проблема выбора)
  • инструменты для работы с СУБД
  • вопросы проектирования БД
  • теоретически вопросы о СУБД

Данный форум не предназначен для:

  • вопросов о поиске разлиных БД (если не понимаете чем БД отличается от СУБД то: а) вам не сюда; б) Google в помощь)
  • обсуждения проблем с доступом к СУБД из различных ЯП (для этого есть соответсвующие форумы по каждому ЯП)
  • обсуждения проблем с написание SQL запросов, для этого есть форум Составление SQL-запросов
  • просьб о написании курсовой, реферата и т.п., для этого есть Центр помощи или фриланс биржа
  • объявлений о найме специалистов, для этого есть раздел Объявления о найме специалистов

Если вы не соблюдаете эти правила, не удивляйтесь потом не найдя свою тему/сообщение. ;)

Полезные советы:

При написании сообщения постарайтесь дать теме максимально понятное название. В теме максимально подробно опишите проблему. Если применимо укажите: название базы данных и версии (MySQL 4.1, MS SQL Server 2000 и т.п.); используемых язык программирования; способа доступа (ADO, BDE и т.д.); сообщения об ошибках.

Для вставки кода используйте теги [code=sql] [/code].

Литературу по базам данных можно поискать здесь.

Действия модераторов можно обсудить здесь.

Если Вам понравилась атмосфера форума, заходите к нам чаще! С уважением, LSD, Zloxa.
 
0 Пользователей читают эту тему (0 Гостей и 0 Скрытых Пользователей)
0 Пользователей:
« Предыдущая тема | СУБД, общие вопросы | Следующая тема »

Подписаться на тему | Подписка на этот форум | Скачать/Распечатать тему


 




[ Время генерации скрипта: 0.0644 ]   [ Использовано запросов: 22 ]   [ GZIP включён ]


Реклама на сайте     Информационное спонсорство

 
 По вопросам размещения рекламы пишите на vladimir(sobaka)vingrad.ru
Отказ от ответственности     Powered by Invision Power Board(R) 1.3 © 2003  IPS, Inc.