Vérificateur de portabilité des identifiants SQL
Collez un nom de table ou de colonne envisagé — ou une liste, un nom par ligne — pour voir précisément lesquels PostgreSQL, MySQL, SQL Server et SQLite rejetteraient, renommeraient silencieusement ou traiteraient différemment, et pourquoi.
Traitement effectué localement dans votre navigateur. Votre fichier n’est jamais téléversé.
Comment utiliser cet outil outil
- Collez un identifiant par ligne : nom de table, de colonne ou lot de noms. Rien ne quitte votre navigateur.
- Sélectionnez « Vérifier les identifiants ».
- Examinez chaque nom signalé : moteurs concernés et non concernés, et pourquoi.
- Utilisez la réécriture proposée lorsqu'elle existe. Les collisions avec les mots réservés et le choix du style de délimitation sont laissés à votre décision, car l'outil ne doit pas trancher à votre place.
Hypothèses
- Entrée : un identifiant par ligne, nom nu ou déjà entouré du style d'un moteur (guillemets doubles, accents graves ou crochets). Ce n'est pas un analyseur SQL : les instructions `CREATE TABLE` complètes et les définitions multicolonnes ne sont pas analysées, seule la forme de l'identifiant l'est.
- Les quatre moteurs cibles sont PostgreSQL, MySQL, SQL Server (T-SQL) et SQLite, fréquemment concernés par la portabilité entre bases.
- La table des mots réservés est une sélection de collisions courantes et documentées, pas la liste exhaustive d'un moteur ; voir les limites.
Sources et données de référence
Méthodologie
Chaque identifiant est vérifié selon six pièges de portabilité documentés : collision avec un mot réservé (par moteur), différences de conversion de casse (PostgreSQL met en minuscules les identifiants non cités ; sensibilité MySQL selon système/réglages ; SQL Server insensible à la casse mais la préserve ; SQLite sensible à la casse), syntaxes de délimitation (guillemets doubles, accents graves, crochets), limites de longueur (63 octets pour PostgreSQL avec troncature silencieuse, 64 caractères MySQL, 128 SQL Server, aucune limite pratique SQLite), caractères non valides sans délimitation et convention du souligné initial. Réécriture seulement dans deux cas mécaniquement clairs : mettre en minuscules pour éviter les divergences de casse et remplacer les caractères invalides par des soulignés. Aucun renommage de mot réservé ni choix de guillemets.
Exemple détaillé
Mot réservé dans certains moteurs seulement
Données d’entrée: limit
Résultat: `limit` est réservé dans PostgreSQL, MySQL et SQLite, mais SQL Server n'a pas de clause LIMIT (il utilise TOP / OFFSET-FETCH) ; le mot n'y est donc pas réservé. Erreur indiquant les trois moteurs concernés.
Identifiant à casse mixte
Données d’entrée: CustomerOrder
Résultat: Sans délimitation, PostgreSQL le convertit silencieusement en `customerorder` ; MySQL, SQL Server et SQLite ont chacun leurs règles de casse. Avertissement et proposition de `customerorder`, convention portable sûre.
Espaces et tiret
Données d’entrée: customer order-id
Résultat: Identifiant nu invalide dans les quatre moteurs ; chacun exige une délimitation avec un caractère différent. Erreur et proposition de `customer_order_id`, convention sûre avec soulignés.
Identifiant PostgreSQL dépassant la limite en octets
Données d’entrée: identifiant encodé de plus de 63 octets
Résultat: PostgreSQL limite les identifiants à 63 octets et tronque les noms plus longs ; des noms distincts peuvent alors entrer en collision. Pour du texte multioctet, octets et caractères ne coïncident pas toujours. Le vérificateur applique un ensemble de règles sélectionnées, pas une validation exhaustive de chaque identifiant ou configuration.
Conseils pratiques
- Préférez les noms en minuscules avec soulignés (`snake_case`) pour toute table ou colonne susceptible d'être interrogée depuis plusieurs moteurs ; cela évite les divergences de casse.
- Évitez les mots réservés plutôt que de dépendre de la délimitation : chaque requête devra conserver les guillemets propres au moteur.
- Gardez les identifiants bien en dessous de 63 caractères si PostgreSQL est une cible possible : sa troncature silencieuse à cette longueur peut être dangereuse.
Erreurs fréquentes
- Supposer qu'un nom est sûr parce qu'il n'est pas réservé dans la base testée : des mots comme order, user, limit, key et index sont réservés dans certains moteurs seulement.
- Traiter les guillemets comme une solution universelle : le caractère dépend du moteur et un identifiant délimité copié tel quel peut échouer ailleurs.
- Ignorer la troncature PostgreSQL à 63 octets ; l'identifiant tronqué semble fonctionner jusqu'à la collision de deux noms longs.
Questions fréquentes
Pourquoi `limit` est-il signalé dans trois moteurs mais pas SQL Server ?
SQL Server n'a pas de clause LIMIT ; il utilise TOP ou OFFSET/FETCH. LIMIT n'y est donc pas réservé, contrairement à PostgreSQL, MySQL et SQLite qui l'emploient dans leur syntaxe.
Délimiter un mot réservé règle-t-il toujours le problème ?
En pratique dans les quatre moteurs, oui, mais le délimiteur varie : guillemets doubles pour PostgreSQL/SQLite, accents graves pour MySQL et crochets pour SQL Server. Le nom délimité d'un moteur ne s'analyse donc pas nécessairement dans un autre. L'outil montre les formes de chacun sans en choisir une.
Un souligné initial est-il vraiment un problème ?
Non, il ne s'agit que d'une note informative mineure. Il est valide dans les quatre moteurs, mais les objets de catalogue internes PostgreSQL et certains ORM utilisent conventionnellement des noms commençant par un souligné.
Dernière vérification : 2026-09-26
La table des mots réservés est une sélection de collisions courantes vérifiables, pas une liste exhaustive de PostgreSQL, MySQL, SQL Server ou SQLite. Pour une vérification définitive, consultez la référence officielle du moteur. L'outil n'analyse pas des instructions SQL entières : un identifiant par ligne, pas tout un corps `CREATE TABLE`.
Les préférences de thème et d’outils, ainsi que les listes enregistrées et récemment utilisées, sont stockées uniquement dans ce navigateur.