Алексей Сундуков

Судя по всему у вас id это суррогатный PK. Есть есть уникальное поле field1, то держать в таблице суррогатный PK имеет смысл только ради удобства человека, в остальном он совершенно не нужен. С таблицей 2 ситуация аналогичная.

Как правильно организовать связь между таблицами?

Если один-ко-многим, то поля table1_field1 достаточно.

Будет ли разница между внешним ключом

О какой разнице речь? В такой формулировке как у вас, то нет, не будет.

id - цифровое, а field1 - строковое поле. Это может иметь значение?

field1 случайно не UUID? В большинстве случаев разницы не будет. Все равно на них вешать индекс.

Не понимаю, зачем все так усложнять, когда все укладывается в простую схему. Весь контент сайта условно можно разделить на 3 части:
1) редко меняющиеся данные (они обычно зашиты в файла шаблона);
2) часто меняющие данные либо контент генерируемый пользователями/администраторами/модераторами;
3) бинарные данные в духе картинок, прикрепляемых файлов.

Вся статика находится в папке skin/имя_скина/цветовая_схема/язык (например, /skin/modern/red/ru, у меня по умолчанию /skin/default/default/ru), в базе любой текстовой контент требующий перевода имеет столбцы под каждый требуемый целевой язык. Это могут быть столбцы с постфиксом оригинальное_имя_язык (к примеру, topic_content, topic_content_ru) для mysql или же наследование таблиц из postgresql.

Реализация:
1) вся текстовая информация сосредотачивается в файлах шаблона с использованием gettext-а.
2) постфиксные столбцы во всех таблицах.
3) статические картинки связанные со скином распределены по языковым папкам, адреса же до динамически добавляемых картинок хранятся в базе и при запросе согласно п.2 получаем адрес до нужной языковой картинки.

Единственная трудность с которой тут можно столкнуться, это gettext и переводы требующие контекста. Поскольку переводчик на руки получает po файл, то он не знает, на какой странице сайта используется то или иное слово и какой у него контекст. Но это не очень частый случай и просто требует привлечение к работе разработчика.

Разница в том, что ограничения (сonstraints) призваны обеспечивать целостность данных, а индексы (index) — скорость доступа к данным. Это две абсолютно не связанные сущности. Причем если первое — часть SQL стандарта, то второе нет (ибо ни как не связанно с функциональностью языка, введение индексов — вынужденная мера). Разработчик сам решает, в каких случая применить эти механизмы и использование одного вовсе не требует использование другого.

Теперь касательно уникальности (unique). В данном случае при добавлении ограничения уникальности (unique constraint) Postgresql сам навешивает на указанное поле индекс. Это просто особенность реализации в данной СУБД. Разработчики решили, что вот так оно будет работать и все тут (причем небезосновательно). В другой же схожей ситуации они решили, что разработчик сам думает, нужно ли ему использовать этих два механизма вместе, или нет. Я говорю об ограничении целостности по внешнему ключу (foreign key). В Postgresql индексы по полям с данным видом ограничения не создаются (Индексы по внешним ключам в Postgresql). А, к примеру, в MySQL создаются. Это особенность реализации в MySQL.

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