Соответствие типов oracle и ms sql

Обновлено: 06.07.2024

В языке SQL /89 поддерживаются следующие типы данных:

CHARACTER(n) или CHAR(n) — символьные строки постоянной длины в n символов. При задании данного типа под каждое значение всегда отводится n символов, и если реальное значение занимает менее, чем n символов, то СУБД автоматически дополняет недостающие символы пробелами.
NUMERIC[(n,m)] — точные числа, здесь n — общее количество цифр в числе, m — количество цифр слева от десятичной точки.
DECIMAL[(n,m)] — точные числа, здесь n — общее количество цифр в числе, m — количество цифр слева от десятичной точки.
DEC[(n,m)] — то же, что и DECIMAL[(n,m)] .
INTEGER или INT — целые числа.
SMALLINT — целые числа меньшего диапазона.

Несмотря на то, что в стандарте SQL1 не определяется точно, что подразумевается под типом INT и SMALLINT (это отдано на откуп реализации), указано только соотношение между этими типами данных, в большинстве реализаций тип данных INTEGER соответствует целым числам, хранимым в четырех байтах, а SMALLINT — соответствует целым числам, хранимым в двух байтах. Выбор одного из этих типов определяется размером числа.

В стандарте SQL92 добавлены следующие типы данных:

VARCHAR(n) — строки символов переменной длины.
NCHAR(N) — строки локализованных символов постоянной длины.
NCHAR VARYING (n) — строки локализованных символов переменной длины.
BIT(n) — строка битов постоянной длины.
BIT VARYING (n) — строка битов переменной длины.
DATE — календарная дата.
TIMESTAMP(точность) — дата и время.
INTERVAL — временной интервал.

Большинство коммерческих СУБД поддерживают еще дополнительные типы данных, которые не специфицированы в стандарте. Так, например, практически все СУБД в том или ином виде поддерживают тип данных для представления неструктурированного текста большого объема. Этот тип аналогичен типу MEMO в настольных СУБД . Называются эти типы по -разному, например в ORACLE этот тип называется LONG , в DB2 — LONG VARCHAR , в SYBASE и MS SQL Server — TEXT .

Однако следует отметить, что специфика реализации отдельных типов данных серьезным образом влияет на результаты запросов к БД . Особенно это касается реализации типов данных DATE и TIMESTAMP . Поэтому при переносе приложений будьте внимательны, на разных платформах они могут работать по -разному, и одной из причин может быть различие в интерпретации типов данных.

При выполнении сравнений в операциях фильтрации могут использоваться константы заданных типов. В стандарте определены следующие константы . Для числовых типов данных определены константы в виде последовательности цифр с необязательным заданием знака числа и десятичной точкой. То есть правильными будут константы :

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

Строковые константы должны быть заключены в одинарные кавычки:

В некоторых реализациях, например MS SQL Server и Informix, допустимы двойные кавычки в строковых константах:

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

Константы даты, времени и временного интервала в реляционных СУБД представляются в виде строковых констант. Форматы этих констант отличаются в различных СУБД . Кроме того, формат представления даты различен в разных странах. В большинстве СУБД реализованы способы настройки форматов представления дат или специальные функции преобразования форматов дат, как сделано, например, в CУБД ORACLE . Приведем примеры констант в MS SQL Server :

В СУБД ORACLE та же константа запишется как

Кроме пользовательских констант в СУБД могут существовать и специальные системные константы . Стандарт SQL1 определяет только одну системную константу USER , которая соответствует имени пользователя, под которым вы подключились к БД .

В операторах SQL могут использоваться выражения, которые строятся по стандартным правилам применения знаков арифметических операций сложения (+), вычитания (-), умножения (*) и деления (/). Однако в ряде СУБД операция деления (/) интерпретируется как деление нацело, поэтому при построении сложных выражений вы можете получить результат, не соответствующий традиционной интерпретации выражения. В стандарт SQL2 включена возможность выполнения операций сложения и вычитания над датами. В большинстве СУБД также определена операция конкатенации над строковыми данными, обозначается она, к сожалению, по -разному. Так, например, для DB2 операция конкатенации обозначается двойной вертикальной чертой, в MS SQL Server — знаком сложения (+), поэтому два выражения, созданные в разных СУБД , эквивалентны:

В стандарте SQL1 не были определены встроенные функции, однако в большинстве коммерческих СУБД такие функции были реализованы, и в стандарт SQL2 уже введен ряд стандартных встроенных функций:

Типы данных Oracle и типы данных Microsoft SQL Server не всегда полностью совпадают. Там, где это возможно, выбор подходящего типа данных при публикации таблицы Oracle осуществляется автоматически. В случаях, когда выбор однозначного соответствия типов данных не очевиден, предлагаются альтернативные сопоставления типов данных. Сведения о выборе альтернативных соответствий типов данных см. ниже в разделе «Указание альтернативных сопоставлений типов данных».

Следующая таблица показывает, как по умолчанию осуществляется преобразование типов данных между Oracle и SQL Server , когда данные передаются издателем Oracle распространителю SQL Server . В столбце «Альтернатива» показано, допустимы ли альтернативные соответствия.

Вопросы сопоставления типов данных

При репликации данных из базы данных Oracle нужно помнить о следующих особенностях типов данных.

Неподдерживаемые типы данных

Следующие типы данных не поддерживаются; столбцы, имеющие эти типы, невозможно реплицировать.

Столбцы, использующие REF

Тип данных DATE

Даты в диапазоне SQL Server от 1753 нашей эры. до 9999 г. нашей эры, тогда как даты в Oracle распределяются в диапазоне от 4712 г. до нашей эры до 4712 г. нашей эры. Если столбец, имеющий тип DATE, содержит значения, выходящие за диапазон SQL Server, выберите для столбца альтернативный тип данных, которым является VARCHAR(19).

Типы FLOAT и NUMBER

Масштаб и точность, задаваемые при сопоставлении типов данных FLOAT и NUMBER, зависят от масштаба и точности, указанных для столбца, использующего этот тип данных в базе данных Oracle. Точность представляет собой количество цифр в числе. Масштаб представляет собой количество цифр справа от десятичной запятой в числе. Например, у числа 123,45 точность равна 5, а масштаб равен 2.

Oracle позволяет определять числа, имеющие масштаб больший, чем точность, например NUMBER(4,5), в то время как SQL Server требует, чтобы точность была не меньше масштаба. Чтобы исключить усечение данных, когда в данных издателя Oracle масштаб больше, чем точность, при преобразовании данных точность приравнивается к масштабу: тип данных NUMBER(4,5) преобразуется в NUMERIC(5,5).

Если для типа NUMBER не указать масштаб и точность, SQL Server будет использовать по умолчанию максимальные масштаб (8) и точность (38). Для оптимизации хранения данных и производительности при репликации данных рекомендуется установить специальные значения масштаба и точности в Oracle.

Типы больших объектов

Oracle поддерживает до 4 гигабайт (ГБ), в то время как SQL Server поддерживает до 2 ГБ. Реплицируемые данные свыше 2 ГБ усекаются.

Если таблица Oracle включает столбец типа BFILE, данные для этого столбца хранятся в файловой системе. Административной учетной записи репликации должно быть предоставлено право доступа в каталог, в котором хранятся данные. С этой целью должно использоваться следующее синтаксическое выражение:

GRANT READ ON DIRECTORY <directory_name> TO <replication_administrative_user_schema>

Дополнительные сведения о типах больших объектов см. в разделе с рекомендациями по большим объектам статьи Рекомендации по структуре и ограничения для издателей Oracle.

Указание альтернативных сопоставлений типов данных

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

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

Глобальная замена значений по умолчанию для всех последующих статей с помощью хранимых процедур (значения по умолчанию для существующих статей не изменяются).

Чтобы указать альтернативные сопоставления типов данных, см. раздел Указание сопоставления типов данных для издателя Oracle.

Типы баз данных Oracle отличаются от SQL Server типов баз данных. При преобразовании объектов базы данных Oracle в SQL Server объекты необходимо указать, как сопоставлять типы данных из Oracle с SQL Server . Можно принять сопоставления типов данных по умолчанию или настроить сопоставления, как показано в следующих разделах.

Сопоставления по умолчанию

SSMA имеет набор сопоставлений типов данных по умолчанию. Список сопоставлений по умолчанию см. в разделе Project Settings (Type mapping) (OracleToSQL).

Наследование сопоставления типов

Сопоставления типов можно настраивать на уровне проекта, на уровне категории объектов (например, во всех хранимых процедурах) или на уровне объектов. Параметры наследуются от более высокого уровня, если они не переопределены на более низком уровне. Например, при сопоставлении smallmoney с money на уровне проекта все объекты в проекте будут использовать это сопоставление, если не настроить сопоставление на уровне объекта или категории.

При просмотре вкладки Сопоставление типов в SSMA фон задается цветом, чтобы показать, какие сопоставления типов наследуются. Фон сопоставления типов желтый для любого унаследованного сопоставления типа и белый для любого сопоставления, указанного на текущем уровне.

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

В следующей процедуре показано, как сопоставлять типы данных на уровне проекта, базы данных или объекта.

Для отображения типов данных

Чтобы настроить сопоставление типов данных для всего проекта, откройте диалоговое окно " Параметры проекта ":

В меню Сервис выберите пункт Параметры проекта.

На левой панели выберите Сопоставление типов.

На правой панели отобразятся диаграмма сопоставления типов и кнопки.

Чтобы настроить сопоставление типов данных на уровне базы данных, таблицы, представления или хранимой процедуры, выберите базу данных, категорию объектов или объект в обозревателе метаданных Oracle.

В обозревателе метаданных Oracle выберите папку или объект для настройки.

На панели справа перейдите на вкладку Сопоставление типов .

Чтобы добавить новое сопоставление, выполните следующие действия.

В разделе тип источника выберите тип данных Oracle для отображения.

Если для типа требуется длина, укажите минимальную длину данных для сопоставления в поле " от " и максимальную длину данных в поле " Кому ".

Это позволяет настроить сопоставление данных для меньших и больших значений одного и того же типа данных.

В разделе тип целевого объекта выберите целевой SQL Server тип данных.

Для некоторых типов требуется длина целевого типа данных. Если это необходимо, введите новую длину данных в поле заменить на .

Чтобы изменить сопоставление типов данных, выполните следующие действия.

В разделе тип источника выберите тип данных Oracle для отображения.

Это позволяет настроить сопоставление данных для меньших и больших значений одного и того же типа данных.

В разделе тип целевого объекта выберите целевой SQL Server тип данных.

Чтобы удалить пользовательское сопоставление типа данных, выполните следующие действия.

Выберите строку в списке Сопоставление типов, содержащую сопоставление типов данных, которое необходимо удалить.

Унаследованные сопоставления удалить нельзя. Однако унаследованные сопоставления переопределяются пользовательскими сопоставлениями для определенного объекта или категории объектов.

Next Steps

Следующим шагом процесса миграции является Создание отчета оценки или Преобразование объектов базы данных Oracle в SQL Server синтаксис. При создании отчета об оценке объекты Oracle автоматически преобразуются во время оценки.

Типы данных MySQL

Типы данных MySQL разделяются на следующие типы:

Типы данных Oracle

Типы данных Oracle разделяются на следующие группы:

ANSI SQL стандарт распознает только текст и число, в то время как большинство коммерческих программ используют другие специальные типы, такие как DATЕ и TIME — фактически почти стандартные типы. Некоторые пакеты также поддерживают такие типы, как, например, MONEY и BINARY. Типы данных, распознаваемые с помощью ANSI, состоят из строк символов и различных типов чисел, которые могут классифицироваться как точные числа и приблизительные числа.

CHARACTER(length) определяет спецификацию строк символов, где length задает длину строк заданного типа. Значения этого типа должны быть заключены в одиночные кавычки. Большинство реализаций поддерживают строки переменной длины для типов данных VARCHAR и LONG VARCHAR (или просто LONG).

В то время, как поле типа CHAR всегда может распределить память для максимального числа символов, которое может сохраняться в поле, поле VARCHAR при любом количестве символов может распределить только определенное количество памяти, чтобы сохранить фактическое содержание поля, хотя SQL может установить некоторое дополнительное пространство памяти, чтобы следить за текущей длиной поля. Поле VARCHAR может быть любой длины, включая реализационно-определяемый максимум. Этот максимум может меняться от 254 до 2048 символов для VARCHAR и до 16000 символов для LONG. LONG обычно используется для текста пояснительного характера или для данных, которые не могут легко сжиматься в простые значения полей; VARCHAR может использоваться для любой текстовой строки, чья длина может меняться.

Извлечение и модифицирование полей VARCHAR — более сложный, и, следовательно, более медленный процесс, чем извлечение и модифицирование полей CHAR. Кроме того, некоторое количество памяти VARCHAR, остается всегда неиспользованной для гарантии вмещения всей длины строки. При использовании таких типов следует предусматривать возможность полей к объединению с другими полями.

Точные числовые типы — это числа, с десятичной точкой или без десятичной точки, которые могут представляться в виде [+|-]<целое без знака>[.<целое без знака>] и специфицироваться как:

DECIMAL(precision [, scale]) — аргумент размера имеет две части: точность и масштаб. Масштаб не может превышать точность. Точность указывает сколько значащих цифр имеет число. Масштаб указывает максимальное число цифр справа от десятичной точки. Масштаб = нулю делает поле эквивалентом целого числа.

NUMERIC(precision [, scale]) — такое же как DECIMAL за исключением того, что максимальное десятичное не может превышать аргумента точности

INTEGER — число без десятичной точки. Эквивалентно DECIMAL, но без цифр справа от десятичной точки, т.е. с масштабом равным 0. Аргумент размера не используется (он автоматически устанавливается в реализационно-зависимое значение).

SMALLINT — такое же как INTEGER, за исключением того, что, в зависимости от реализации, размер по умолчанию может ( или не может ) быть меньше чем INTEGER.

Приблизительные числовые типы — это числа в показательной (экспоненциальной по основанию 10) записи, представляемые как <литеральное значение точного числа>Е<целое со знаком> и специфицирущиеся следующим образом:

FLOAT[(precision)] — число с плавающей запятой. Аргумент размера состоит из одного числа, определяющего минимальную точность.

REAL — такое же как FLOAT, за исключением того, что никакого аргумента размера не используется. Точность устанавливается реализационно-зависимой по умолчанию.

DOUBLE PRECISION — такое же как REAL, за исключением того, что реализационно-определяемая точность для DOUBLE PRECISION должна превышать реализационно-определяемую точность REAL.

Типы данных Access

Типы данных Access разделяются на следующие группы:

Типы данных SQL Server

Microsoft SQL Server поддерживает большинство типов данных SQL 2003. Также SQL Server поддерживает дополнительные типы данных, используемые для однозначной идентификации строк данных в таблице и на многих серверах, например UNIQUEIDENTIFIER , что соответствует аппаратной философии «роста в ширину», исповедуемой Microsoft (т. е. внедрение базы на множестве серверов на платформах Intel), вместо «роста в высоту» (т. е. внедрение на одном огромном мощном UNIX-сервере или Windows Data Center Server).

Типы данных, используемые в SQL Server:

Типы данных PostgreSQL

База данных PostgreSQL поддерживает большинство типов данных SQL2003 плюс огромный набор типов для хранения пространственных и геометрических данных. PostgreSQL может похвастаться богатым набором операторов и функций, специально предназначенных для геометрических типов данных. Сюда входят такие средства, как поворот, поиск пересечений и масштабирование. В PostgreSQL также есть поддержка дополнительных версий существующих типов данных, которые характерны тем, что занимают меньше места на диске, чем соответствующие исходные версии. Например, в PostgreSQL предлагается несколько вариантов типа INTEGER для хранения больших и небольших чисел, соответственно занимающих больше или меньше места.

Ну, информацию из этой таблицы посмотреть не сложно
Администрирование\Запросы\Информация о БД

Но я там что-то не нашел соответствия типов

Естественно искать таблицу надо в БД. В АОТ её нету. (для 3-ки по крайней мере)

2 mazzy: SqlSystemVariables != SqlDictionary
Таблица SqlSystemVariables в тройке не присутствует в АОТ вообще, даже в System Documentation. И в SQL Administration тоже.

Увидеть данные из неё можно действительно только в форме Администрирование\Запросы\Информация о БД, как отметил Кашперук.
При этом форма генерит "прямой" запрос к БД:

и зполняет на его основе таблицу SqlParameters, в которой на постоянной основе данных нет.

используются данные именно из этой таблице. Где-то в ядре. Класса "оупенсорс" какого-то, отвечающего за это дело нет. (По крайней мере я не нашёл)

. соответствие типов X++ (перечисление Types) типам MS SQL/Oracle.

Вот, теперь по сути.

Вот часть данных из этой таблицы:

Ой сдается мне что это не аксаптовское соответствие, а стандарта SQL а аксаптовское где-то в ядре прописано. К примеру int64 там отсутствует. Даже интересно, а как вам удалось добавить в таблицу поле типа Int64?

Здесь именно соответствие между базовыми типами (Аксапты или просто базовыми типами, как тут правильно с точки зрения терминологии - затрудняюсь ответить ) и соответсвующими им типами MS SQL/Oracle. Используются они именно для генерации DDL при работе ядра с БД.

То что в аксапте есть и другие типы - ни для кого не секрет. Просто в DDL они либо не используются, либо прибодятся к "более базовому" типу.

Даже интересно, а как вам удалось добавить в таблицу поле типа Int64? Дык это базовый тип для DAX4 от него RecId происходит и еще куча всего, так он перекручивается в SQL в тип bigint Даже интересно, а как вам удалось добавить в таблицу поле типа Int64? В 4ке поля RecId имеют тип Int64 что соответствует типу BIGINT в MS SQL Server.

Сдаецца мне там все по другому:
1. сначала по EDT определяется базовый тип
2. далее базовый тип преобразуется в стандартный тип "Стандарта SQL", который и отправляется на сервер (SQL или Oracle)
3. А вот уже сервер самостоятельо интерпретирует типы "Стандарта SQL" в свои собственные! Я же сразу оговорился, что говорю про третью (3) версию. Там recid это обычный Int.

Открыл для интереса 4-ку и посмотрел: там в этой таблице больше нет соответствий типов вообще.

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

Сдаецца мне там все по другому:
1. сначала по EDT определяется базовый тип
2. далее базовый тип преобразуется в стандартный тип "Стандарта SQL", который и отправляется на сервер (SQL или Oracle)
3. А вот уже сервер самостоятельо интерпретирует типы "Стандарта SQL" в свои собственные! Думаю, что п.2 и 3. делается в ядре. Как вы себе представляете "сервер БД, решающий самостоятельно, какой тип использовать"?
Нее, в концепции Аксапты наверняка всё это решает ядро.

Открыл для интереса 4-ку и посмотрел: там в этой таблице больше нет соответствий типов вообще.

Думаю, что п.2 и 3. делается в ядре. Как вы себе представляете "сервер БД, решающий самостоятельно, какой тип использовать"?
Нее, в концепции Аксапты наверняка всё это решает ядро.

Элементарно представляю, т.к. ВСЕ сервера обязаны соответствовать стандарту (IEEE по моему) SQL-91 как минимум. И все внешние коннекты, например через ODBC работают именно с этим стандартом.

Поэтому таки п.3. на SQL сервере отрабатывается

зы: мот в написнии стандарта ошибся а в целом все именно так

Извините, логику не прослеживаю?
При чём здесь ODBC? Во-первых, ODBC и SQL Server - это не одно и то же.

А стандарт то они поддерживают, но это не значит, что они за вас будут переписывать ваши запросы.

Не буду говорить про 4-ку, я там во многом ещё не разбирался, возможно они там и унифицировали все используемые типи, но в тройке разница между используемыми типами в оракле и скл имеется, и задана она явно для каждой базы, как я уже показал выше. Думаю, что в 4-ке это соответсвие просто зашили где-то в ядре.

Более того, я думаю, п.3 "сервер самостоятельо интерпретирует . " наверняка вообще отсутствует. Запрос DDL формирует непосредственно ядро.

Читайте также: