Уменьшение размера поля.

[trigger]

Уменьшение размера поля.

Есть 2 таблицы. Записи в первой уникально идентифицируются с помощью недлинной varchar-строки. (6-12 англ символов). Вторая должна ссылатся в отношении 1/* по внешнему ключу на первую. Вопрос: имеет ли смысл заводить в первой таблице int ключ для ссылки? Имеет ли смысл уменьшать размер записи во второй таблице?

В первой(parent) таблице эта уникальная строка(name) все равно должна присутствовать.
Отношение примерно 1/3 - 1/5000


Если поможет код:
[sql]
CREATE TABLE parent( name VARCHAR(12) PRIMARY KEY
);

CREATE TABLE child(
id INT4 PRIMARY KEY,
parent VARCHAR(12) NOT NULL,

FOREIGN KEY (parent)
REFERENCES parent(name)
ON DELETE CASCADE ON UPDATE CASCADE
);
[/sql]

 

[Nime]

Заведи отдельно искусственный ключ.

http://www.akzhan.midi.ru/devcorner/articles/NaturalKeysVersusAtrificialKeysByTentser.html

 

[trigger]

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

Один из многих ляпов: Звучали аргументы, что БД может сама оптимизировать хранение ЕК, подставив вместо него в People некую хэш-функцию (фактически создав СК сама). Hо ни один из реально существующих коммерческих серверов БД так не делает, и есть основания полагать, что и не будет делать.
Я не думаю, что из списка MySQL, PostgreSQL, Oracle хотя бы одна не строит простейшего хеша, строя при этом b-trees...

PS: по-моему, легко будет замерить время самому, чем и займусь.

 

[!ataMAN]

Автор того документа всё время упирает в то, что INDEX SCAN по VARCHAR очень тормознутый, не ровня INTEGER... Однако раньше, по-моему, на этом форуме приходили к немного другому заключению..
А где правда? Если кто тестировал, можно выводы и/или цифры?
--
thx