Уникальная ошибка ограничения при создании таблиц в PostgreSQL (перенесена из MySQL)

Question

Я с большим энтузиазмом прочитал вопрос, озаглавленный Миграция с MySQL на PostgreSQL в Linux (Kubuntu) .Тема Star Wars сделала его еще более увлекательным.Но я столкнулся с проблемой, касающейся уникальных ограничений в PostgreSQL.

Я внимательно следил за приведенным выше постом, чтобы создать DDL PostgreSQL, используя sqlt .Мысленный процесс заключался в том, чтобы сначала создать схему / таблицы, а затем импортировать данные.Однако 57 из моих 72 таблиц используют CONSTRAINT "userid" UNIQUE ("user_id", "key")

Вот пример одной из таблиц:

CREATE TABLE "account_otherserviceinfo" (
    "id" serial NOT NULL,
    "user_id" bigint NOT NULL,
    "key" character varying(50) NOT NULL,
    "value" text NOT NULL,
    PRIMARY KEY ("id"),
    CONSTRAINT "user_id" UNIQUE ("user_id", "key")
);

Когда я копирую эти таблицы в мою базу данных PostgreSQLиспользуя инструмент запросов в pgadmin3, я получаю следующую ошибку:

ОШИБКА: отношение "user_id" уже существует. Состояние SQL: 42P07

Я не проектировал эту схему базы данных.Я только помогаю с процессом миграции.При чтении документации по уникальным ограничениям кажется, что можно использовать одно и то же имя, если оно находится в другой таблице.http://www.postgresql.org/docs/8.3/static/ddl-constraints.html. Я неверно истолковал это?

Буду признателен за любые предложения или указатели.

Спасибо!

PS: Спасибо https://stackoverflow.com/users/59087/dave-jarvisи https://stackoverflow.com/users/26534/michael-trausch за то, что я зашел так далеко; -)

Answer 1

При чтении документации по уникальным ограничениям, кажется, что можно использовать одно и то же имя, если оно находится в другой таблице.документации, которую вы читаете, но вы ее неправильно истолковали.Имена ограничений должны быть глобально уникальными.Таким образом, вы можете иметь столько UNIQUE ("user_id", "key"), сколько захотите, но не можете назвать каждого из них "user_id".

Answer 2

Вы можете обойти этот тип проблемы, дав вашим ограничениям более подробные имена.

Вам нужно будет придумать стандарт именования для ваших объектов базы данных, чтобы избежать этого типа проблемы.Может быть что-то типа type_schema_tablename_columnname.Так, например, uidx_public_account_otherserviceinfor_user_id_key.Этот тип имени гарантирует, что у вас нет проблем, и позволяет легко определить, к какому объекту относится сообщение об ошибке.Вы можете обсудить самый ясный способ реализации того, что я сказал, но ключевой момент заключается в том, чтобы придумать стандарт, который будет использоваться для всех объектов, которые подходят для вашей среды.

Answer 3

Не следует использовать user_id в качестве имени ограничения, поскольку оно уже используется в качестве имени столбца.