Номер VS Varchar (2) Первичные ключи

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

STATUS (max 6)
AC --> Active
DE --> Deleted

COUNTRIES (total 30)
UK --> United Kingdom
IT --> Italy
GR --> Greece

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

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

Итак, мой вопрос в том, будут ли эти ключи VARCHAR (2) оказывать влияние на производительность при запросе соединения 3 таблиц. Первый будет значительно медленнее второго?

SELECT m.*,
       s.status_name,
       c.country_name
  FROM main m, status s, countries c
 WHERE m.status_cd = s.status_cd
   AND m.country_cd = c.country_cd
   AND m.status_cd = 'AC'
   AND m.country_cd = 'UK'

SELECT m.*,
       s.status_name,
       c.country_name
  FROM main m, status s, countries c
 WHERE m.status_cd = s.status_cd
   AND m.country_cd = c.country_cd
   AND m.status_cd = 1
   AND m.country_cd = 2

Разъяснение:

Состояние не является двоичным ( "max 6" рядом с именем таблицы). Значения, вероятно, будут:

* active
* deleted
* draft
* send
* replaced

и нам нужно отобразить декодированные значения для пользователя, поэтому нам нужны имена.

Ответы

Ответ 1

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

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

Итак, идите с натуральными кодами. В остальном, SQL в первом примере более ясен; "Великобритания" и "AC" гораздо более значимы, чем 1 и 2.

В СУБД, отличной от Oracle, вы, вероятно, используете CHAR (2) для значений статуса и кода страны. Пользователи Oracle, как правило, используют VARCHAR2 для всего; Я не уверен, есть ли штраф за использование столбца CHAR (2), тем более, что значения столбца являются фиксированной длиной. (В разделе Informix, например, поле VARCHAR (2) - поле длиной до двух символов - будет хранить 3 байта, длину (всегда 2 в вашем случае) и 2 байта данных. Напротив, CHAR (2) будет занимать всего 2 байта.)

Ответ 2

Откроется ссылка . В нижней строке нет большой разницы в производительности между varchar и num. Поэтому вы должны пойти, для чего когда-либо имеет смысл для столбца. Здесь валчар, кажется, имеет больше смысла.

Ответ 3

Если "статус" (и всегда будет?) является двоичным активным/удаленным полем, которое вообще беспокоит таблицу. Похоже, что нормализация взята на непрактичную крайность.

Было бы проще, не говоря уже проще, просто использовать поле tinyint (1) и записать активное/удаленное состояние как 1 или 0.

Это полностью исключает одно из ваших объединений, которое должно быть хорошим.

Ответ 4

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