Преобразование типов данных из SQL Server в Oracle

Question

В настоящее время я перемещаю продукт с SQL Server на Oracle. Я немного знаком с SQL Server и ничего не знаю об Oracle, поэтому прошу прощения, если простое присутствие этого вопроса оскорбляет кого-либо.

Исходя из этой страницы, http://download.oracle.com/docs/cd/E12151_01/doc.150/e12156/ss_oracle_compared.htm, может показаться, что преобразование типов данных из SQL Server в Oracle должно быть:

REAL = FLOAT (24) -> FLOAT (63)

FLOAT (p) -> FLOAT (p)

TIMESTAMP -> NUMBER

NVARCHAR (n) -> VARCHAR (n * 2)

NCHAR (n) -> CHAR (n * 2)

Вот мои вопросы относительно них:

Для FLOAT, учитывая, что FLOAT (p) -> FLOAT (p), не означает ли это, что FLOAT -> FLOAT (24)?

Для TIMESTAMP, поскольку Oracle также имеет свою собственную версию, не лучше ли будет TIMESTAMP -> TIMESTAMP?

Наконец, для NVARCHAR (n) и NCHAR (n), я думал, что проблема будет касаться Unicode. Затем, опять же, поскольку Oracle предоставляет свою собственную версию обоих, не имеет ли больше смысла, что NVARCHAR (n) -> NVARCHAR (n) и NCHAR (n) -> NCHAR (n)?

Было бы очень признательно, если бы кто-то подробно остановился на предыдущих 3 вопросах.

Заранее спасибо.

Answer 1

Похоже, что Oracle CHAR и VARCHAR2 (всегда используют VARCHAR2 вместо VARCHAR) уже поддерживают Unicode - документ, на который вы ссылаетесь, советует преобразовывать в типы данных SQL Server NCHAR и NVARCHAR.

SQL Server TIMESTAMP на самом деле вообще не является временной меткой - это своего рода идентификатор, основанный на времени, который используется только для указания того, что строка изменилась - его нельзя преобразовать обратно в любой тип DATETIME (в хотя бы так, как я знаю).

Для FLOAT использование 126 байтов было бы огромным - поскольку инструменты разработчика автоматически сопоставляют FLOAT SQL Server с FLOAT Oracle (53), почему бы не использовать это количество?

Answer 2

Следующее не является прямым ответом на ваш вопрос; но хорошо бы заглянуть в блог sqlteam

sqlteam - преобразование типов данных между Oracle и SQL Server, часть 2: число

Подробное объяснение того, как обращаться с numbers и т. Д.

Answer 3

Это больше к сведению, чем ответ на ваш вопрос, но вы потенциально можете столкнуться с особенно болезненной разницей между SQL Server и Oracle. В SQL Server вы можете определить строковый столбец (любого типа), чтобы он не допускал значения NULL, а затем вставить в этот столбец строки нулевой длины (или «пустые»), поскольку SQL Server не считает пустую строку такой же, как NULL.

Oracle считает пустую строку такой же, как NULL, поэтому Oracle не позволит вам вставить пустые значения в столбец NOT NULL. Это, очевидно, вызывает проблемы при копировании данных из таблицы в SQL Server в соответствующую таблицу в Oracle. Вы можете решить эту проблему:

1. Установите в Oracle некорректный строковый столбец, чтобы разрешить значения NULL (, поэтому не очень хорошая идея)
2. При копировании данных замените пустые строки на что-то еще (я не знаю, что вы должны здесь использовать)
3. Пропустить оскорбительные строки и притвориться, что ты их никогда не видел

Мне бы очень хотелось думать, что Oracle выбрала пустые строки как NULL (где они одни среди основных БД), заключалась в том, чтобы привязать клиентов к их платформе, но эта на самом деле работает в противоположном направлении. Вы можете переместить базу данных из Oracle во что-то другое, без разницы = NULL, вызывающей проблемы.

См. Этот предыдущий вопрос: Oracle считает пустые строки пустыми, а SQL Server нет - как это лучше всего обрабатывается?