Как можно проверить идентификатор на предмет неисключенной действительности в большинстве РСУБД?

Question

Я бы хотел, чтобы мое приложение работало с несколькими базами данных. Хотя я не собираюсь прямо поддерживать их прямо сейчас, я бы хотел иметь возможность определять свои схемы так, чтобы я не использовал зарезервированные идентификаторы. Причина? Разделители идентификаторов не являются стандартными между базами данных. Например, MySQL использует backticks (`) для кавычек идентификаторов, а MSSQL использует скобки ([]).

Однако я не уверен, какое подмножество имен «безопасно». Есть ли простой способ проверить это?

Answer 1

Главный ответ

Простой способ? Я так не думаю. Итак, НЕТ.

Способ сделать это

Единственный способ - найти документы для каждой поддерживаемой СУБД.

Причина

Вы всегда можете найти в ANSI SQL зарезервированные слова, но в конце каждая СУБД будет иметь свои особенности.

Обходной путь

Давайте посмотрим на это с другой стороны: вместо того, чтобы ваши SQL-запросы избегали зарезервированных имен, вы можете заставить часть вашего кода экранировать столбцы в соответствии с СУБД.

Другие проблемы, с которыми приходится сталкиваться

Имена столбцов - не единственная ваша проблема. Черт, это даже не ваша главная проблема!

Если вы знакомы с GROUP_CONCAT в MySQL, вы понимаете, о чем я. Его альтернативой в SQL Server является использование XML PATH. Firebird имеет встроенную агрегатную функцию LIST. В конце концов, у вас будет другой запрос к СУБД. Я знаю это из-за ...

Мой опыт

Мой анекдот "Был там, сделал это": я работал в компании, основной продукт которой должен был поддерживать существующую клиентскую RBDMS, которая может быть Oracle, SQL Server или Informix (не спрашивайте).

В конце концов это сработало так:

• Это простой запрос? Попробуйте написать так, чтобы он работал на всех СУБД;
• Разве это невозможно (имеется в виду: слишком сложно / займет много времени)? В вашем коде будет IF. Там нет выхода (BWAHAHA!), У вас будет один запрос для RDBMS.
• Все, что мы тестировали, мы тестировали 3 раза: по одному на СУРБД.

Заключение

Наличие в вашем приложении поддержки нескольких СУБД - отличная функция и очень убедительный аргумент в пользу продаж. Тем не менее, это не так просто поддерживать. Это действительно требует работы.

Вы можете подумать сейчас , что вы никогда не будете использовать специфичные для СУБД запросы. Но затем наступает день, когда нечетный запрос очень легко разрешается как SQL Server, так и Oracle, но по-своему. Однако попытается написать тот же запрос, используя ANSI SQL (конечно, почему бы и нет?), И это займет у вас несколько часов и может привести вас в бешенство. Опять "был там, сделал это". Но не верьте мне на слово: говорите с людьми и, самое главное, с прототипом!

Answer 2

• Придерживайтесь буквенно-цифровых символов (ASCII A-Z, 0-9) и подчеркивания.
• Не начинайте с подчеркивания (и вы должны начинать с букв).
• Не требовать идентификаторов с разделителями - предполагается, что регистр не учитывается.
• Возможно, вам придется исследовать ограничения длины - старые стандарты SQL (SQL-86, SQL-89) ограничивали имена до 18 символов, но большинство СУБД допускают как минимум 31 в эти дни.
• Избегайте ключевых слов (но список ключевых слов огромен - для каждой СУБД в отдельности и объединения всех ключевых слов во всех СУБД).

Answer 3

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

Вы также можете рассмотреть возможность использования режима ANSI_QUOTES в MySQL - тогда все ваши идентификаторы для SQL Server, Oracle и MySQL могут быть заключены в двойные кавычки - стандарт ANSI.

Например, SQL Server 2000 "Regular Indentifiers"undelimited: http://msdn.microsoft.com/en-us/library/aa223962%28v=sql.80%29.aspx

Те же документы для SQL Server 2005: http://msdn.microsoft.com/en-us/library/ms175874%28v=sql.90%29.aspx

Список зарезервированных слов SQL Server 2005: http://msdn.microsoft.com/en-us/library/ms189822%28v=SQL.90%29.aspx

Эквиваленты для Oracle 10g: http://download.oracle.com/docs/cd/B19306_01/server.102/b14200/sql_elements008.htm

Зарезервированные слова в MySQL: http://dev.mysql.com/doc/refman/5.6/en/reserved-words.html