Глюки мобильности SQL

Я не уверен, что это правда в драйверах, поставляемых с Python, но в версии "Horrable", которую я использовал, если столбец в наборе результатов возвращает NULL для всех значений в столбец, сам столбец не возвращается в структуре набора результатов . Это могло (и часто приводило) к производственным ошибкам, которые было невозможно воспроизвести в процессе разработки.

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

У Oracle, похоже, нет проблем с курсорами, это огромная проблема производительности SQL-сервера.

На самом деле почти вся настройка производительности зависит от базы данных (вот почему стандартный код ANSII часто работает очень плохо по сравнению с лучшими методами, разработанными для специфической разновидности SQL, зависящей от базы данных).

Даты - еще одна вещь, которая, кажется, обрабатывается по-разному от базы данных к базе данных.

Типы данных также не эквивалентны. Одна вещь, которая имеет тенденцию привлекать новичков к SQL Server, заключается в том, что тип данных timestamp не имеет абсолютно ничего общего с датами и временем и не может быть преобразован в значение datatime.

Установить поддержку оператора.

За исключением UNION / UNION ALL, поддержка операторов множеств во всех базах данных весьма неоднородна. Oracle и SQL-сервер поддерживают большинство из них, но Oracle поддерживает операцию MINUS, а также эквивалентную стандартную операцию EXCEPT DISTINCT. AFIK, MySQL поддерживает только UNION (без поддержки INTERSECT или EXCEPT).

Различные базы данных по-разному обрабатывают двоичные данные. Так, например, это будет работать в MySQL:

mysql> CREATE TABLE t (c BINARY(3));
Query OK, 0 rows affected (0.01 sec)

mysql> INSERT INTO t SET c = 'z';
Query OK, 1 row affected (0.01 sec)

Однако Oracle полагается, что эти значения являются шестнадцатеричными:

SQL> CREATE TABLE t (c RAW(3));

Table created.

SQL> INSERT INTO t VALUES ('z');
INSERT INTO t VALUES ('z')
                 *
ERROR at line 1:
ORA-01465: invalid hex number

Вместо этого мы должны преобразовать их в шестнадцатеричные:

SQL> INSERT INTO t VALUES (rawtohex('z'));

1 row created.

Непонятный синтаксис соединения, такой как синтаксис Oracle (+) для внешних соединений. В компании, в которой я работал, этот синтаксис использовался повсеместно, а не стандартный синтаксис LEFT OUTER JOIN / LEFT JOIN, из-за чего перенос некоторых вещей в MySQL был довольно сложной задачей.

Oracle не позволяет использовать несколько вставок в одном запросе. MySQL позволяет это:

INSERT INTO test(id, name) VALUES (1, 'foo'),(2, 'bar');

Список имеющихся у меня несоответствий между SQL Server и Oracle возникает при переносе:

Думаете, стандартный SQL ANSI полностью переносится между базами данных? Подумайте еще раз.

Написание стандартного SQL ANSI нецелесообразно

Каковы некоторые общие «подводные камни» с точки зрения переноса SQL с одной платформы на другую?

То же, что и попытки перевода с английского на русского , подставляя словарные слова прямо во фразы.

Работает на здравствуйте и до свидания , но не работает на У Мэри был ягненок , чтобы ничего не сказать Шекспира.

Различные СУБД имеют разные культуры, несмотря на наличие SQL в их имени.

Например, ограничение строк.

В Oracle :

WHERE rownum = 1

В SQL Server :

SELECT TOP 1

В MySQL и PostgreSQL :

LIMIT 1

В DB2 :

SELECT * ... FETCH FIRST 1 ROW ONLY

Четыре различных пункта .

Oracle имеет другой подход к кавычкам, чем MySQL.

MySQL: `object_name`, 'string', "string"
Oracle: "object_name", 'string'

Кроме того, , экранирование отличается.

MySQL: 'It\'s easy'
Oracle: 'It''s slightly confusing'

(Обратите внимание, что чтобы избежать чего-либо, кроме кавычек в Oracle, вы можете использовать в своем запросе директиву ESCAPE; SELECT * FROM testTable WHERE percent = '50 \% 'ESCAPE' \ ')

Oracle не позволяет вставлять пустые строки: они автоматически преобразуются в NULL.

Многозначные запросы предложения IN. Раньше я все время использовал их в Oracle и был удивлен, обнаружив, что вы не можете сделать это в SQL Server. Например, этот запрос:

SELECT * FROM mytable WHERE (col1, col2) IN ( SELECT col1, col2 FROM othertable )

Другой пример - создание уникальных (обычно суррогатных) первичных ключей.

Многие базы данных, такие как SQL Server и sqlite, позволяют объявить столбец как идентификатор: обычно, если значение для этот столбец отсутствует при вставке, база данных сгенерирует уникальное значение для столбца.

В Oracle, напротив, вы создаете последовательность отдельно от таблицы, а затем используете nextval в последовательности для генерации следующего значения:

CREATE SEQUENCE test_seq;
SELECT test_seq.nextval FROM dual;

] Или, что более типично:

INSERT INTO foo(id, title) VALUES (test_seq.nextval, 'bar');

Oracle не допускает использование оператора select без предложения FROM. Следовательно, вы не можете выполнять такие запросы:

SELECT 1

Вместо этого вы должны сказать, что запрос взят из таблицы DUAL :

SELECT 1 FROM DUAL

Проблемы с производительностью - большая проблема. Например, представления в Oracle, AFAIK, почти такие же быстрые, как и таблицы. С SQLServer этого не было, когда мне приходилось их использовать. Представления эффективно убивали производительность, замедляя те же выборки на порядок или более (запрос прямо из таблиц занял, скажем, 0,5 секунды, а использование представления могло занять минуту). Также было много ограничений на их использование, например, не все функции SQL можно было использовать в представлениях.

Обратите внимание, что это было верно 5-6 лет назад, я не знаю, улучшила ли Microsoft это с тех пор.

Я вспоминаю странную проблему Oracle, которая меня совершенно сбила с толку. Я не уверен, что это была конфигурация экземпляра или настройки по умолчанию, но мы не могли иметь более 1000 элементов в операторе IN. Так что нам пришлось заставить его делать то, что мы хотели:

SELECT Col1,Col2 
FROM Table
WHERE Code IN (1,2,3,...,1000)
OR Code IN (1001,1002,1003,...,2000)

и т. Д.

Ужасно, но это сработало.

(Прежде чем кто-либо укажет очевидное решение подзапроса или встроенного представления, запрос был сгенерирован в совершенно другой системе)

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

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

Физический дизайн базы данных в основном связан с особенностями инфраструктуры, на которой основана структура таблицы. Почти все системы поддерживают индексы, а тип индекса по умолчанию - B-дерево, хотя его можно назвать как-нибудь иначе. Но с этого момента каждая система имеет свои собственные физические особенности, которые могут полностью отличаться от одной системы к другой. Типичная физическая особенность Oracle - табличные пространства. С табличными пространствами тесно связано сопоставление таблиц и табличных пространств. Физическое проектирование должно выполняться для конкретной системы.

В дополнение к тому, какую систему RDM вы используете, вам необходимо принять во внимание объем данных, нагрузку, время отклика и системные ресурсы, такие как диски. Хорошая новость заключается в том, что можно внести множество изменений в физический дизайн без изменения кода приложения. Это известно как физическая независимость данных. Это означает, что вы в некоторой степени свободны настраивать внешний вид после того, как вы » Мы написали код приложения и загрузили некоторые данные.

Возможно, вы захотите просмотреть несколько книг по проектированию баз данных, чтобы получить более глубокое представление о логическом и физическом дизайне и различиях между ними. Некоторые популярные авторы - CJ Date и Joe Celko.

Временные таблицы - Oracle против SQL Server / MySQL. Переход с Oracle на MS / MySQL без проблем. Напротив, немного иначе.