на эту тему уже не один десяток страниц форума исписали, ищите по словосочеатниям "суррогатный ключ", "естесственный ключ"
например, тынц

Имхо, обычно лучше делать суррогатный (искусственный) ключ в числовой форме. Но бывают (хоть и не многочисленные) ситуации, когда естесственный удобнее.

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

SELECT CL.NAME, STR.NAME
FROM CLIENTS CL, STREETS STR
WHERE CL.STREET_ID = STR.ID

можно будет написать

SELECT CL.NAME, CL.STREET_NAME
FROM CLIENTS CL

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

miksoft Владимир П.Еще учитывайте такой момент: строковый (и вообще любого типа естественный) ключ часто помогает уменьшить соединения таблиц в запросах. Грубо говоря (за суть примера не пинайте, он надуманный, просто для иллюстрации), вместо

SELECT CL.NAME, STR.NAME
FROM CLIENTS CL, STREETS STR
WHERE CL.STREET_ID = STR.ID

можно будет написать

SELECT CL.NAME, CL.STREET_NAME
FROM CLIENTS CL

, потому что STREET_NAME, хотя и ссылается через внешний ключ на таблицу STREETS, но в CLIENTS хранится в полной форме.Не соглашусь. Вы говорите не о выборе между строковыми/числовыми ключами, а о выносе части данных в отдельную сущность, что уже изменяет логику базы.Простите, наврал, прочитал ваш пост снизу вверх. Но все равно не соглашусь, т.к. вы предлагаете просто денормализацию базы, а не критерий выбора строкового или числового ключа.