Число VS Varchar (2) первичные ключи

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

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

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

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

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

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

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

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

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