2013-11-11 5 views
3

Я никоим образом не эксперт по SQL, поэтому я уверен, что я сделал что-то неправильно. Здесь я прочитал несколько вопросов о необходимости первичного ключа. Как я создал эту таблицу, я не могу найти способ иметь уникальный ключ. Это база данных типа опроса. У меня есть таблица для основных деталей, таких как дата, номер сортировки и вовлеченный человек. Другая таблица для ответов на вопросы и другая для комментариев. Я бы сделал сортировку уникальной, но может быть задействовано более одного человека, поэтому один и тот же номер сортировки будет использоваться более одного раза. Причастные люди могут появляться не один раз. Единственная поистине уникальная вещь - это комбинировать человека с сортировкой. Я думал об авто ключе, но это нецелесообразно. Может ли использование двух идентификаторов быть приемлемой практикой для таблицы типа опроса?Таблица нуждается в нескольких идентификаторах

+2

Похоже, что у вас есть много разных отношений. –

+0

Что дает ответ на последний вопрос, Да. –

+0

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

ответ

2

важная часть:

«... больше, чем один человек может быть вовлечен так же число сортировки будет использоваться более чем один раз Вовлеченные люди могут оказаться более чем один раз, а также.»

на основе ваших комментариев, данные в этих двух областях, например:

Triage Person 
------ ------ 
    1  PersonA 
    1  PersonB 
... 
    7  PersonA 
    7  PersonB 

хорошо в этом классификационные и Человек может сделать составной ключ, при условии, каждый человек, записанный в поле Person однозначно идентифицировать. То есть, если ea. значение человека - это имя типа «Джон Смит», у вас может возникнуть проблема, если есть два или более Джон Смит, отвечая на опрос. Таким образом, ваша ценность Person сама должна идентифицировать людей однозначно. Предполагая сортировку nos. (т. е. никакое количество триамов не представляет собой более чем семантически релевантную позицию сортировки), эти два поля в качестве составного ключа будут работать для вас тогда и только тогда, когда ваше исследование создаст более одной уникальной комбинации сортировки ,

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

2

Ваш вопрос довольно общий, и у меня недостаточно информации, чтобы дать вам определенный ответ, но, надеюсь, мои комментарии ниже могут помочь.

Нет проблем с использованием составного первичного ключа (ключ, состоящий из 2 или более столбцов). Он чаще используется для связывания таблиц, например. во многих отношениях.

Следует учитывать, что если вы хотите также обратиться к таблице с составным первичным ключом из других таблиц, вам придется ссылаться на 2 столбца во внешнем ключе, на всех объединениях и т. Д. Это может быть проще создать отдельный столбец для первичного ключа (например, автоинкрементный номер).

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