2009-02-24 2 views
1

Этот вопрос является продолжением другого вопроса, также озаглавленного Entity Relationship.Связь с субъектом

Dejene: вы должны перенести материал в исходный вопрос, а затем удалить этот вопрос.


Разработка: Да, 'поле' имеет в виду участки земли. У нас есть несколько полей для выращивания тростника в разных местах. Он [каждый поле?] Назван и имеет бюджет.

Пользователь не имеет отношения к человеку, работающему на машине. Это отделы. Я использовал таблицу isDone, чтобы связать userDept с машиной. Машина может использоваться несколькими отделами, и многие машины могут работать для пользователя.

Определенная машина может использоваться для нескольких задач при заданном сдвиге. Он может работать в течение 2 часов и может начать другую задачу в другом поле. У нас есть три смены в день, каждый из 8 часов!

Если я использую Auto increment PK, считаете ли вы, что важны другие ключи? Я не хочу его использовать!

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

Dejene

+0

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

+0

Примечание: дополнительная информация здесь теперь передается на главный вопрос. –

ответ

1

Отношения между таблицами ("внешние ключи") являются определены между столбцами, а не ценности. Пример:

create table machine (id identity); 
create table owner (id identity); 
create table isDone (machineId, ownerId); 

Теперь вы можете сказать: «isDone.machineId должен существовать в machine таблице»:

ALTER TABLE isDone 
    ADD CONSTRAINT machineFK 
    FOREIGN KEY (machineId) 
    REFERENCES machine (id) 
; 

Это приводит к тому, что база данных будет возвращать ошибку, если вы попытаетесь вставить строку в isDone со значением для столбца machineId, который не существует нигде в таблице machine (где select Count(*) from machine where id = machineId возвращает 0).

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

Когда вы используете эту функцию своей базы данных, вы должны убедиться, что машина и владелец существуют в то время, когда вы создаете новую строку в isDone. Это обычно просто: каждый день появляются новые смены, но нет новых машин и отделов. Таким образом, вы можете создавать новые машины и отделы, когда они будут куплены/основаны. Первая смена с использованием одного из них, вероятно, произойдет долгое время после этого.

Что касается других ключей: столбец с автоматическим приращением должен быть основным ключом (PK) вашего стола и ничего больше. Позже вы можете создавать индексы в другом столбце, если обнаружите, что некоторые запросы работают плохо. Но для начала достаточно автоколонка PK-столбца. Это упрощает формирование ограничений внешнего ключа.

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

Кроме того, я предлагаю вам использовать реальное имя объектов (например, «отдел» или «владелец» вместо «пользователь») в вашем дизайне. Это упростит просмотр того, что и что искать, когда вы что-то ищете.

Смежные вопросы