Tableau de compatibilité SQL (types de données esp)

Question

Alors ... je travaille sur du code qui ... va finir par être utilisé sur différents serveurs sql en même temps.

Bien que le code SQL soit différent en fonction du serveur, les types de données et les colonnes ne le sont pas. Par conséquent, j'ai besoin de savoir quels sont les types de données communs à (au moins) la plupart des types de serveurs SQL.

Comme point de départ, je les types suivants:

byte, char, float, int, text, varchar, blob 

S'il vous plaît noter que l'orthographe est très important, puisque le nom du type de données se termine dans la requête tout comme (par exemple: bien que les deux int et entier sont pris en charge, j'ai besoin du commun). Donc, la question est, est-ce que quelqu'un sait d'un tableau comparant la compatibilité entre les serveurs SQL? Ou peut-être quelqu'un qui a fait des recherches dans le domaine? En ce qui concerne le biais, je suis évidemment biaisé à un SGBDR particulier, donc pas besoin de réponses sur lesquelles RDBMS se trouve être mieux. Gardons cela concentré et sur le sujet, d'accord?

Answer 1

Je regarderais dans la spécification standard ANSI SQL et j'utiliserais les types de données spécifiés ici. Un livre like this peut vous aider.

Ils ont tous une bonne documentation, donc je voudrais juste lire sur leurs types de données. Aurait probablement toutes les informations dont vous avez besoin. Le only other information que j'ai pu trouver auparavant est pretty old.

espoir qui aide.

Éditer: Juste une autre idée ... vous pourriez utiliser le modèle de stratégie pour votre SQL, de cette façon cela n'aurait pas d'importance s'il était différent, vous pourriez utiliser les fonctionnalités plus avancées. Bien que de cette façon vous ayez plus de travail à faire et plus à maintenir:/

Answer 2

Je pense que vous finirez par écrire des instructions SQL spécifiques, cas par cas, pour chaque type de serveur de base de données. Certainement je l'ai fait.

J'ai été dans votre situation, y compris avoir l'intention d'écrire du code agnostique de base de données, mais à la longue cela ne fonctionne tout simplement pas. Une base de données ne traitera pas, par exemple, des chaînes multi-octets alors qu'une autre les exigera (par exemple, SQL Server CE), ce qui vous forcera à utiliser Varchar vs NVarchar sur les colonnes, par exemple. Certaines bases de données supporteront des chaînes multi-octets, mais avec des performances terribles. On utilisera VARCHAR2 (Oracle), et tout le monde utilisera VARCHAR. L'un manipulera les BLOB d'une façon tandis que l'autre les fera différemment. Ne me lancez pas sur les types de données de date, non plus. Plutôt que de trouver le sous-ensemble magique du langage SQL et des types de données qui fonctionnent dans toutes les bases de données, il serait plus judicieux de rechercher une méthode/bibliothèque d'accès aux données qui peut masquer les différences pour vous (peut-être une bibliothèque ORM Comme je l'ai dit, je suis (et je suis toujours) dans votre situation de devoir supporter plusieurs bases de données et la meilleure solution pour moi est d'écrire du code optimal pour chaque base de données. , plutôt que d'essayer de trouver les types de données SQL et le code qui fonctionne dans chacun d'eux (je n'étais pas capable de, pas à un niveau satisfaisant).En outre, vous pouvez extraire davantage de performances de chaque base de données si vous créez un texte SQL distinct pour chaque base de données (par exemple, les paramètres liés aux performances que vous pouvez spécifier lors de la création d'une table Oracle qui ne s'appliquent pas). créer une table dans une autre base de données).

Je dis, ne vous battez pas les différences de syntaxe dans les différentes bases de données, vous ne gagnerez pas. C'est une meilleure idée de supporter et d'utiliser ces différences à votre avantage autant que possible.