У меня есть база данных PostgreSQL, которую я хочу переместить на SQL Server - как схему, так и данные. Я беден, поэтому я не хочу платить деньги. Я тоже ленив, поэтому я не хочу много работать. В настоящее время я делаю эту таблицу за столом, и есть около 100 таблиц. Это очень утомительно.
Есть ли какой-то трюк, который делает то, что я хочу?
Я считаю, что вы, возможно, получили пониженные голоса из-за удивительной легкости создания простого SQL script из PostgreSQL, который может (теоретически) запускаться снова практически в любой СУБД. Если вы являетесь обычным пользователем PostgreSQL, это звучит как немой вопрос.
Это не справедливо, так как выясняется, что это на самом деле умеренно трудная проблема (хотя больше из-за нечетного синтаксиса и интерфейса SQL Server, чем любой отказ PostgreSQL).
Вы должны найти полезную информацию в принятом ответе на этой странице Serverfault: https://serverfault.com/questions/65407/best-tool-to-migrate-a-postgresql-database-to-ms-sql-2005.
Если вы можете преобразовать схему без данных, вы можете сократить шаги для данных с помощью этой команды:
pg_dump --data-only --column-inserts your_db_name > data_load_script.sql
Эта загрузка будет довольно медленной, но опция --column-inserts генерирует самые общие инструкции INSERT для каждой строки данных и должна быть совместимой.
EDIT: Предложения по преобразованию схемы следует:
Я начал бы сбрасывать схему, но удаляя все, что связано с правами собственности или правами. Этого должно быть достаточно:
pg_dump --schema-only --no-owner --no-privileges your_db_name > schema_create_script.sql
Отредактируйте этот файл, чтобы добавить строку BEGIN TRANSACTION; в начало и ROLLBACK TRANSACTION; до конца. Теперь вы можете загрузить его и запустить в окне запроса на SQL Server. Если вы получите какие-либо ошибки, убедитесь, что вы переместились в нижнюю часть файла, выделите инструкцию ROLLBACK и запустите ее (нажав F5, когда вы подсвечиваете оператор).
В принципе, вы должны разрешить каждую ошибку до тех пор, пока script не пройдет чисто. Затем вы можете изменить ROLLBACK TRANSACTION на COMMIT TRANSACTION и выполнить одно последнее время.
К сожалению, я не могу помочь, с какими ошибками вы можете видеть, поскольку я никогда не переходил от PostgreSQL к SQL Server, только наоборот. Некоторые вещи, которые я ожидал бы быть проблемой, однако (очевидно, НЕ полный список):
NOT NULL INTEGER к SEQUENCE с помощью DEFAULT. В SQL Server это столбец IDENTITY, но они не совсем то же самое. Я не уверен, что они эквивалентны, но если ваша исходная схема заполнена полями "id", у вас могут быть проблемы. Я не знаю, имеет ли SQL Server CREATE SEQUENCE, поэтому вам, возможно, придется удалить их.CREATE FUNCTION и перевести алгоритмы вручную.pg_dump имеет опцию --encoding=, которая позволит вам установить конкретную кодировку. Я, кажется, помню, что Windows имеет тенденцию использовать двухбайтную кодировку UTF-16 для Unicode, где PostgreSQL использует UTF-8. У меня возникла проблема с SQL Server на PostgreSQL из-за вывода UTF-16, поэтому было бы интересно исследовать.TEXT - это просто VARCHAR без максимальной длины. В SQL Server TEXT является... сложным (и устаревшим). Каждое поле в исходной схеме, объявленное как TEXT, должно быть просмотрено для соответствующего типа данных SQL Server.UNICODE. Я недостаточно знаком с этим, чтобы делать предложения. Я просто указываю, что это может быть проблемой.Я нашел более быстрый и простой способ выполнить это.
Сначала скопируйте таблицу (или запрос) в файл с разделителями табуляции следующим образом:
COPY (SELECT siteid, searchdist, listtype, list, sitename, county, street,
city, state, zip, georesult, elevation, lat, lng, wkt, unlocated_bool,
id, status, standard_status, date_opened_or_reported, date_closed,
notes, list_type_description FROM mlocal) TO 'c:\SQLAzureImportFiles\data_script_mlocal.tsv' NULL E''
Затем вам нужно создать свою таблицу в SQL, это не будет обрабатывать какую-либо схему для вас. Схема должна соответствовать экспортированному TSV файлу в порядке и типах данных.
Наконец, вы запускаете утилиту SQL bcp для ввода файла tsv следующим образом:
bcp MyDb.dbo.mlocal in "\\NEWDBSERVER\SQLAzureImportFiles\data_script_mlocal.tsv" -S tcp:YourDBServer.database.windows.net -U YourUserName -P YourPassword -c
Несколько замечаний, которые я встретил. Postgres и SQL Server обрабатывают логические поля по-разному. Для вашей схемы SQL Server необходимо, чтобы ваши логические поля были установлены в varchar (1), а полученные данные будут "f", "t" или "null". Затем вам нужно будет немного перевести это поле. что-то вроде:
ALTER TABLE mlocal ADD unlocated bit;
UPDATE mlocal SET unlocated=1 WHERE unlocated_bool='t';
UPDATE mlocal SET unlocated=0 WHERE unlocated_bool='f';
ALTER TABLE mlocal DROP COLUMN unlocated_bool;
Другое дело, что поля географии/геометрии очень разные между двумя платформами. Экспортируйте поля геометрии как WKT с помощью ST_AsText(geo) и соответствующим образом конвертируйте в конец SQL Server.
Там может быть больше несовместимостей, требующих таких настроек.
ИЗМЕНИТЬ. Поэтому, когда этот метод технически работает, я пытаюсь передать несколько миллионов записей из 100 + таблиц в SQL Azure и bcp в SQL Azure, это довольно flaky получается. Я постоянно становлюсь прерывистым. Невозможно открыть ошибки в файлах файлах BCP-сервера, сервер прерывается с задержкой и по какой-то причине некоторые записи не передаются без каких-либо признаков ошибок или проблем. Таким образом, этот метод нестабилен для передачи больших объемов данных Azure SQL.