Начальная страница › Форумы › PostgreSQL › Вопросы по SQL и другие аспекты работы PostgreSQL

Мастерам Postgres про foreign key

Posted Декабрь 24th, 2010 by Polt_xl
in

Проблема такая. pg версии 7.4. Известны наименования двух таблиц.

table1, table2

Надо расшарить внешний ключ между ними. Он есть в БД, но о нет программа ничего не знает, она его определяет автоматически, стоит такая задача.А именно надо узнать наименование таблиц и полей между которыми установлен fk.

Юзаем инф. схему и несколько таблиц по констрейнтам и преференсам. Все было бы хорошо, если бы наименование внешнего ключа было бы уникальным. Однако наименование ключа в моем частном случае = $3, и ключей с таким наименованием еще 3 штуки, по другим таблицам.

fk1_name = $3
fk2_name = $3
fk2_name = $3

Как быть? Надеюсь найдется гуру psql который подскажет. Заранее спс.

‹ импорт в PostgreSQL Помогите создать запрос ›

Опции просмотра комментариев

Выберите предпочитаемый вами способ показа комментариев и нажмите "Сохранить настройки" для активации изменений.

Я бы попробовал вам

On Декабрь 24th, 2010 admin says:

Я бы попробовал вам подсказать, только совершенно не понял что вы спрашиваете.
1. Внешний ключ не расшаривается, он указывает в одной таблице на колонку (колонки) в другой
2. Программа может ничего не знать о fk, логика работы с таблицами от этого не меняется.
3. Если при задании внешнего ключа явно не указывается имя, то PostgreSQL генерирует его автоматически
4. Имя внешнего ключа УНИКАЛЬНО! Не может быть других внешних ключей с таким же именем
5. Что такое $3 вообще непонятно

...

On Декабрь 25th, 2010 Polt_xl says:

Хех)

1. Имя внешнего ключа не уникально. По крайней мере в pg7-8.
2. $3 это как раз имя внешнего ключа, которое сгенерировалось автоматически.
3. Вопрос уже решен, всем спс за советы)

Как жаль, что в рунете пока что так мало информации по пг, реально интересной, а не той, о которой написано во всех книгах по пг.

Тему можно закрывать.

1. Вы ошибаетесь. Оно

On Декабрь 25th, 2010 admin says:

1. Вы ошибаетесь. Оно уникально. Попробуйте создать два fk явно указав одно и то же имя - увидите ошибку
2. Я думаю, что в $3 знак $ наводит на мысль о том, что это переменная, а вот какое значение будет в неё подставлено наверное будет зависеть от конкретного случая. Возможно поэтому вы и подумали, что имя не уникальное, но это как аргумент в описании функции - имя одно и тоже, а значение каждый раз может быть другим.

Пока к сожалению всё что есть это в основном частичный перевод мануала. Там кстати fk довольно хорошо описаны.

Короче, попоже выложу скрин.

On Декабрь 25th, 2010 Polt_xl says:

Короче, попоже выложу скрин. Причем тут значение переменной, когда речь идет об наименовании внешнего ключа, которое отображается и системных таблицах под признаком f (foreign key) и в pdadmin, в моем конкретном случае. Если наименование внешнего ключа не задавать, создается ключ с наименованием $+число. Таких ключей, к примеру $2 или $22 может быть бесконечное количество. Короче опрелить таблицы между которыми настроены такие ключи через информационную схему у меня не получилось, а через pg_catalog норм.

Опять не понимаю, хотя слова

On Декабрь 25th, 2010 admin says:

Опять не понимаю, хотя слова знакомые: информационная схема, pg_catalog.
Что не получилось-то?
В мануале даны примеры, что не работает?

Увлекательная беседа) Речь

On Декабрь 25th, 2010 Polt_xl says:

Увлекательная беседа)

Речь шла о программировании с использованием psql бд. Прога выполняет ряд задач. Для выполнения некоторых необходима информация о внешних ключах между определенными таблицами. Логика проста. Функция получает набор таблиц. При условии что между ними есть внешние ключи, результат на выходе меняется. Необходимо было определить есть ли между таблицами внешние ключи и, если они есть, заполнить структуры данными по этим ключам, дабы функция выдала верный результат.

Если бы наименования внешнего ключа было уникальным (к примеру table_temp_fk), как было во всех случаях тестирования проги ранее, проблем бы не было. Я использовал инфсхему, там можно по каждой таблице получить список ограничений и, в случае fk узнать таблицу, на которую идет связь в случае уникальности имени, но! Но тут дали новую базу. И, о чудо, получилось так что в списке fk были fk с одинаковыми именами, такие как я писал выше. Отсюда вывод что об уникальности наименования fk говорить не приходится, если вы контролируете создание внешних ключей сами, то задавайте имена сами и делайте их уникальными руками, чтобы избежать возможных ошибок. Короче, возник затык, который я уже решил. Любой fk с любым наименованием мона вскрыть и все про него узнать через pg_catalog, немногочерезжопно, однако работает верно.

Если знаете занимательное чтиво по postgres кроме мануала и админки, буду благодарен.

О! Наконец-то я услышал то,

On Декабрь 26th, 2010 admin says:

О! Наконец-то я услышал то, что нужно было написать в первом посте :)
Не зря говорят, что хорошо заданный вопрос - это половина ответа.
Теперь мысли по поводу...

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

Да, безусловно. узнать есть ли у таблицы внешний ключ можно через системный каталог, если бы вопрос стоял КАК УЗНАТЬ, то был бы дан и соответствующий ответ. Да, я проверил, действительно имя fk в пределах одной БД может быть неуникальным. Откуда интересно я взял, что оно должно быть уникальным? Леший его знает, то ли MySQL то ли Informix попутал, прошу прощения за дезу :)

Мануал - это основное и достаточное чтиво, чтобы разобраться во всём. Другое дело, что в нём не всегда всё структурировано именно так как ожидается. Часть информации бывает находится совсем не в том разделе, где вы бы её искали.

Может такой запрос подойдет

On Декабрь 26th, 2010 Alarm says:

Может такой запрос подойдет

 SELECT 'K' AS key_flag, t.table_name AS k_tablename, l.column_name AS k_column_name, k.table_name AS f_table_name, k.column_name AS f_coumn_name, t.constraint_name
           FROM information_schema.constraint_table_usage t
      JOIN information_schema.constraint_column_usage l ON t.constraint_name::text = l.constraint_name::text
   JOIN information_schema.key_column_usage k ON t.constraint_name::text = k.constraint_name::text
   JOIN information_schema.table_constraints c ON t.constraint_name::text = c.constraint_name::text
  WHERE c.constraint_type::text = 'FOREIGN KEY'::text
UNION ALL 
         SELECT 'F' AS key_flag, k.table_name AS k_tablename, k.column_name AS k_column_name, t.table_name AS f_table_name, l.column_name AS f_coumn_name, t.constraint_name
           FROM information_schema.key_column_usage k
      JOIN information_schema.table_constraints c ON k.constraint_name::text = c.constraint_name::text
   JOIN information_schema.constraint_table_usage t ON k.constraint_name::text = t.constraint_name::text
   JOIN information_schema.constraint_column_usage l ON t.constraint_name::text = l.constraint_name::text
  WHERE c.constraint_type::text = 'FOREIGN KEY'::text
  ORDER BY 2, 1 DESC;

Опции просмотра комментариев

Выберите предпочитаемый вами способ показа комментариев и нажмите "Сохранить настройки" для активации изменений.

Back to top

(С) Виктор Вислобоков, 2008-2023