Senya_LВопрос 2: хорошо ли совмещать PK с FK? Не ожидаются ли какие-нибудь неожиданные грабли?Что в Вашем понимании совмещать ? Как PK, так и FK описывают ограничения на хранимые данные. Каждое из них имеет совершенно разный и независимый смысл, никоим образом не дублируя друг друга. Поэтому их существование определяется только вами: хотите ли вы доверить проверку этих ограничений СУБД или будете проверять их каким-либо другим способом. Или вообще не будете проверять и решите, что пользователь имеет право на любую ошибку. Правда, есть риск, что в случае инцидентов разгребать последствия придется вам, или, что гораздо хуже, тем, кто будет после вас сопровождать такую систему. В большинстве случаев такие ограничения лучше объявлять явно, иначе будет риск нарушить целостность данных совершенно случайным и непредсказумым образом.

Senya_Lчем чреват другой вариант, если не задать PK, а задать FK на столбец A.object_id с ограничением UNIQUE?
В качестве SQL сервера рассматриваются два варианта: MSSQL2005 и Firebird 2.1Почти ничем, за маленьким исключением, ограничения UNIQUE позволяют существование NULL в тех столбцах, на которые наложены. Поэтому если такое значение не является допустимым для данных в этих столбцах, то лучше, IMHO, использовать PRIMARY KEY, чтобы потом, опять же не удивляться и не исправлять ошибки в данных. Если же на соотвествующие столбцы наложить ограничение типа CHECK (Field IS NOT NULL), то UNIQUE по поведению становится практически полным аналогом PK. В MS SQL можно устанавливать FOREIGN KEY не только на PK, но и UNIQUE. Предполагаю, что Firebird в этом смысле вряд ли отличается от MS SQL.