Стоит ли делать составные внешние ключи в БД?
1. внешние ключи должны быть там и те, чтобы гарантировать ссылочную целостность. Должна быть ссылка сочетанием именно двух параметров - значит должна быть ссылка сочетанием пары параметров. Лучше или хуже сюда не применимо. Два разных fk и один составной имеют различное поведение.
2. для какой именно СУБД? Postgresql следуя стандарту SQL обязывает ссылаться только на уникальное поле. Mysql отступает и в этом вопросе от стандарта и позволяет проверять неуникальное индексированное поле.
3. см. coding standart конкретного проекта. Обычно никто не обижается против именования: имя таблицы _ имена полей _fk
4. можно упереться в предел размера индексируемого поля. У postgresql это 1/3 размера странички памяти = 2730 байт по дефолту, у mysql - зависит от кучи факторов.
Для мускуля:Стоит ли делать в БД составной внешний ключ из двух колонок?
Без контекста задачи на этот вопрос нельзя ответитьВ каких случаях составной ключ лучше/хуже набора из двух одинарных?
Если связка уникальна ИЛИ поиск будет выполняться строго по двум ключам - можно сэкономить и поставить составной.Правильно ли я понимаю, что внешний ключ должен быть помечен как: 1. key 2. как unique 
UNIQUE пишется, когда он уникальный. Можно вместо KEY писать INDEXКак принято задавать имена для ключей?
Вопрос из серии соглашений на проекте. Стандартов множество, единого всем нравящегося не существует. Например в моем текущем проекте принято соглашение: ключ именуется так же как и колонка, если ключ составной - то конкатенация через символ подчеркивания. Например userId, или userId_categoryIdКакие есть нюансы с внешними ключами для нецелочисленных типов?
Используйте только в случае, если БД не нагружена. Целостность через констрейнты стоит реально дорого.