Заполнение полей в существующих записях в postgresql с использованием идентификатора записи, чтобы определить, что и куда идет

260
Sirach Matthews

Сценарий

У меня есть база данных postgresql, содержащая список вариантов продукта, который, однако, заполняется автоматически, без номеров деталей. Я экспортировал таблицу, чтобы запустить некоторые формулы для генерации номеров деталей для каждого варианта продукта. Это дало мне таблицу, содержащую соответствующий идентификатор записи и связанный номер детали.

Чего я пытаюсь достичь

Теперь, когда у меня есть таблица с отсутствующей информацией, как мне вернуть эту информацию обратно в таблицу postgresql?

Пример данных из таблицы Postgresql [product_product]

 id create_date weight default_code product_templ_id ... 1 2016-12-15 18:57 0 000-000000-000 1 ... 2 2016-12-16 19:00 0 000-000000-000 2 ... 3 2016-12-16 20:42 0 000-000000-000 31 ... 4 2016-12-16 20:43 0 000-000000-000 31 ... 5 2016-12-16 20:44 0 000-000000-000 31 ... 6 2016-12-16 20:45 0 31 ... ... ................ ... .............. 31 ... 1603 2016-12-16 21:51 0 31 ... 1604 2016-12-16 21:52 0 31 ... 

Примерный список рассчитанных номеров деталей

 id default_code  6 000-000000-000 ... .............. 1604 000-000000-000 

Что я пробовал

Итак, я установил соединение ODBC с базой данных, связав таблицу в MS Access 2010. Я отфильтровал по product_templ_idполю и отсортировал по ним id, чтобы соответствовать тому, что было в моей электронной таблице Excel. Затем я скопировал номера деталей из default_codeколонки и попытался вставить в начальную точку, но получил сообщение об ошибке, в котором сообщалось, что я пытался вставить слишком много информации. Я понял, Access пытался вставить содержимое буфера обмена в одну ячейку. Не то поведение, на которое я надеялся.

Какой маршрут лучше?

Этот конкретный продукт имеет 1440 вариантов, каждый со своим собственным номером детали и спецификацией. Я действительно не хочу тратить свое время на генерацию всего этого построчно. Я всегда говорю людям, что данные - это данные, и вы можете делать с данными все что угодно. Это просто вопрос разработки как.

--РЕДАКТИРОВАТЬ--

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

В результате я попробовал следующую команду:

COPY product_product (default_code) from '/csv/file/location/file.csv' CSV HEADER delimiter ';' null '/n'; 

В результате чего:

ERROR: extra data after last expected column CONTEXT: COPY product_product, line 2: "203;000-000000-000" 

Я думаю, хорошо, я упоминаю одно поле, но мой CSV имеет два поля. Это потому, что я хочу убедиться, что импортированное default_codeполе связано с правильной записью.

Далее я попробовал:

COPY product_product FROM '/csv/file/location/file.csv' CSV HEADER delimiter ';' null '\n'; 

В результате чего:

ERROR: duplicate key value violates unique constraint "product_product_pkey" DETAIL: Key (id)=(2) already exists. 

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

Если бы я знал, как редактировать значение записи в postgresql, я мог бы написать скрипт для генерации необходимых команд для редактирования всех 1440 записей соответственно.

1

1 ответ на вопрос

1
FrankerZ

Вы должны экспортировать ваши данные в формате CSV и использовать либо pgAdmin, либо команду raw COPY в postgres, чтобы импортировать ваши данные обратно в:

См. Этот пост для получения информации о том, как это сделать: https://stackoverflow.com/questions/19400173/how-should-i-import-data-from-csv-into-a-postgres-table-using-pgadmin-3

--РЕДАКТИРОВАТЬ--

После этого поста вы можете использовать свои навыки сценариев для создания следующего SQL-запроса:

UPDATE product_product SET default_code = CASE id WHEN 6 THEN 000-000000-000 ... ... WHEN 1603 THEN 000-000000-000 WHEN 1604 THEN 000-000000-000 ELSE default_code END; 

Затем с помощью pgAdmin подключитесь к базе данных и выполните запрос. Это позволит проанализировать записи в product_productтаблице и обновить default_codeполе записи, соответствующее относительному idзначению. Если idзначение отсутствует в вашем списке, оно просто сохраняет default_codeзначение.

Этот пост заканчивает запрос дополнительным оператором:

 ... END WHERE id IN(6,...,...,1603,1604); 

В этом конкретном случае нет необходимости перечислять конкретные idзначения. Кроме того, INсписок из более чем 1440 значений приведет к ошибке. Это нормально, потому что ELSE default_codeоператор действует как ловушка, обрабатывая idзначения, которых нет в нашем caseсписке.

Это решение было проверено и подтверждено ФП.

Я был в состоянии экспортировать из pgAdmin, но не импортировать. Я отредактировал свой вопрос с изложением дальнейших шагов, которые я предпринял. Спасибо, что поделились этой ссылкой. Это было полезно. Sirach Matthews 7 лет назад 0
@SirachMatthews После [этого поста] (https://www.postgresql.org/message-id/20050627145211.GA16186%40webserv.wug-glas.de) они рекомендуют импортировать в новую таблицу и использовать существующий SQL для замены записей. в целевой таблице. Смотрите также [этот пост] (http://stackoverflow.com/questions/13947327/to-ignore-duplicate-keys-during-copy-from-in-postgresql) FrankerZ 7 лет назад 1

Похожие вопросы