Какая колонка для первичного ключа (ов)

Question

Примеры данных для гаек и болтов Thread Series. Я пытаюсь определить первичный ключ (ключи) для этого набора данных. Вот пример нескольких допустимых комбинаций.

size  form  tpi 
1/4  UNC  20 
1/4  UNF  28 
1/4  UNEF  32 
5/16  UNC  18 
5/16  UN  20 
5/16  UNF  24 
5/16  UN  28 
5/16  UNEF  32 
3/8  UNC  16 
3/8  UN  20 
3/4  UNC  10 

В конце концов я пытаюсь создать выпадающее меню в веб-приложение, которое позволяет пользователю выбрать правильный болт, такие как 3/4-10UNC-2A HEX Head.3/4-6UNC-2A HEX Head не действует, потому что они не производим болт 3/4" с 6 нитями на дюйм (он не будет загружен в эту таблицу).

Первый выталкиватель выбирает тип болта, а второй выталкивает размеры болтов, которые доступны на основе типа болта (определенного в другом дБ таблица)

Третий вытащил бы конечную часть определения болта. Поэтому, если пользователь выбирает HE X Head, то 5/16 ", они увидели бы выбор для UNC-18, UN-20, UNF-24, UN-28 и UNEF-32.

Мои варианты для ПК (ы) может быть:

• суррогат и создавать уникальные ограничения.
• размера использования и форма, как составной PK, который определяет TPI
• использовать размер и TPI в качестве составного PK, который определяет, образует
• использовать форму и TPI как ПК, который определяет размера
• всех три поля, как PK (вероятно, неправильно!)

Кажется, что не имеет значения, какую опцию PK я выбираю в отношении запроса, потому что я буду запрашивать на основе диаметра болта, чтобы получить два других значения. Что-то, что я забыл, это значения 2А, относящиеся к формам ООН в другой таблице, и «doozey» требования, которое дополнительно ограничивает использование ThreadSeries с типом болта.

Я делаю это в Java EE, используя JSF и JPA Сущности, если это имеет значение

Answer 1

размера использования и форма, как составной PK, который определяет TPI
размера использования и TPI в качестве составного PK, который определяет форму
формы использования и TPI как ПК, который определяет размер

Все они являются ложными предположениями. По мере роста базы данных нет ничего, чтобы остановить одно из этих предположений, сделанное ложным. Например. a 1/4 UNC 28 добавляется на склад.

• Таким образом, если вы создали ПК из любого из них, это приведет к поломке базы данных, и вам придется изменить весь набор таблиц, зависящих от этого ПК.

Вы не можете определить Ключи через FD (кроме как теоретическое упражнение в классе, используя a и b и cs). Это не классная комната. Колонки являются реальными, они имеют смысл (a и b, и c не имеют смысла). Вы совершенно правильно описали проблемы, смысл.

Определение ключевых слов - это логическое упражнение с прямой логикой, частичное и частичное моделирование данных.

Каждый из ваших строк примеров - это факт. Это должно быть сохранено. Это должно быть уникальным.

все три поля как PK (вероятно, неправильно!)

Это является единственно правильным PK. Это единственная комбинация, которая обеспечивает уникальность строк, чтобы убедиться, что в таблице нет повторяющихся строк.

суррогат и создавать уникальные ограничения.

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

Суррогат не предоставляет логическую уникальность строк, которая требуется в реляционной модели (они обеспечивают уникальность идентификатора физической записи).

Если вы не понимаете, что я говорю, пожалуйста, прочитайте this Answer, сверху лжеучителей

Что-то я ушел из это значения 2А, которые относятся к формам ООН в другой таблицы и «doozey» требования, которое дополнительно ограничивает использование ThreadSeries с типом болта.

реляционной модели основан на исчислениях предикатов первых порядка, широко известные как первый порядок Логика (ВОЛП). В FOL ничего не может быть сказано. Поэтому нет ничего, что невозможно было бы смоделировать в реляционной базе данных.

• В «Теоретиках *, которые пишут книги, считающие о реляционной модели или реляционных базах данных, не понимают эти фундаментов, они пишут, что разные вещи, не могут быть сделаны, они используют суррогаты (анти-реляционный) для все таблицы, что приводит к подаче системы записи, ни с реляционной целостности (в отличие от ссылочной целостности), мощность или скорость реляционной базы данных.

Открыть новый вопрос повторно в «doozey» и пинг я.

Answer 2

Ваш вопрос не является ключевыми ценностями вообще. То, что вы делаете, это «сверление», чтобы найти единственную уникальную комбинацию значений в трех столбцах. Этот процесс не использует ключи.

Однако, я бы сделал одно предложение. Основное поле группировки - form. Это не произвольный фиксированный список известных значений. По этой причине вы можете иметь таблицу Forms с одной записью для каждого типа формы: UN, UNC, UNF и т. Д. Поле form будет определено как внешний ключ к этой таблице.

Это обеспечит два преимущества.

1. целостности данных: Значение не может существовать в этом form поле, которое не было ранее определено в Forms таблице.
2. Производительность: таблица форм обеспечит легкий источник первого раскрывающегося списка. Вместо выполнения select distinct form from ThreadSeries вы можете выполнить select form from Forms. Каждая форма имеет одну и только одну запись, не нужно использовать distinct - и любые формы, которые не были указаны в поле ThreadSeries (например, когда вы создаете новую форму, если не по какой-либо другой причине), будут отображаться.

Что касается первичного ключа, у вас есть два варианта.Один - суррогатный ключ. Это дает возможность однозначно идентифицировать строку, используя только одно значение. Недостатком является то, что это значение не будет иметь никакого значения для ваших пользователей. Когда они ищут 3/4-10UNC-2A HEX Head, они знают, как это указать. Вероятно, они не знают (и будут очень противны тому, чтобы учиться), что значение для этого конкретного винта составляет 9383934747 или даже 117. Эти значения (по определению) бессмысленны. Вы предотвратили бы любую путаницу пользователя и/или антипатию к ПК, скрыв ее от них. Это обычная практика.

Другое - использовать три поля в качестве составного ПК. Это имеет преимущество, заключающееся в том, что пользователь может построить значение PK на основе того, что они ищут или развернуть, когда он просматривает. Недостатком, конечно же, является работа с тремя полями вместо одного. Но если содержимое трех полей является значениями, которые вы, как правило, будете иметь для вас в любом случае, это не является недостатком. Но, и это важно, эти три поля определяют естественный ключ, независимо от того, явно ли вы определяете их как Первичный ключ. Поэтому, даже если вы решите пойти с суррогатным ключом, эти поля должны быть определены как ключ: каждое отдельное поле определено NOT NULL и уникальный индекс, построенный с использованием всех трех - unique(form, size, tpi).

Это подробный анализ. Есть дополнительные плюсы и минусы с обеих сторон, но они незначительные, обычно зависящие от разных факторов, поэтому могут или не могут применяться к вашим обстоятельствам, и, кроме того, я не пишу книгу здесь.