andrushokЯ просто небыл уверен, стоит ли мне настаивать на собственном ключе как PK. Теперь задачка еще сложнее. Итак, есть 2 группы таблиц - продукты и public data...Я все-таки хочу вернуться к исходному вопросу (который про то, стоит ли иметь собственный ключ как PK) и посмотреть на него вот с какой стороны. Кто владеет этим ключем? Не andrushok, а некто посторонний. Если публичная таблица берется один раз, и более не меняется, то это не имеет никакого значения. Но если регулярно выходят новые релизы публичной таблицы, и их планируется обновлять, то как раз вопрос владения и выплывает.
Все мы знаем и соблюдаем правила дорожного движения. И знаем, что в этих правилах написано, в частности, что на дороге мы должны предполагать от других участников такого же знания и соблюдения этих правил. Тем не менее, аварии, почему-то, случаются.
Так же и в этом случае. Допустим, andrushok доверится разработчику публичной таблицы, так как он считает, что правила реляционной теории так же строги, общеизвестны и обязательны к применению, как ПДД. И он решит использовать в качестве ключа в своих таблицах ключ таблицы публичной. А где гарантия, что тот разработчик, например, в случае удаления записей, не станет использовать удаленный ключ повторно, для идентификации совершенно другой записи? Или вообще, тот ключ, который получает публикуемая таблица, не формируется непосредственно при экспорте из родной системы как простой автонумератор?
Нет уж, если ключ внешней по отношению к системе таблицы внедряется в систему, мы косвенно пускаем в нашу систему чужого разработчика. Я в таких случаях предпочитаю действовать крайне осторожно. И даже если у меня со сторонним разработчиком будут заранее провентилированы все аспекты интерфейса подключения к моей системе его таблицы, включая поведение PK, я не буду торопиться использовать его ключ в моей системе. Я его буду перекодировать и проверять на вшивость при каждом выходе нового релиза его таблицы (ну, то есть, при обновлении данных в таблице, подключенной к моей системе).