Comment créer une table dans H2 avec une colonne nommée groupe? J'ai vu un exemple qui a utilisé quelque chose comme [*] il y a un moment, mais je ne peux pas sembler le trouver. P>
3 Réponses :
Vous devez entourer le nom de colonne de mots réservé dans des guillemets, comme p>
"groupe" p>
Source (lien direct): h2database.com p>
Mots-clés / mots réservés p>
Il existe une liste de mots-clés qui ne peuvent pas être utilisés comme identifiants (table noms, noms de colonne, etc.), à moins qu'ils ne soient cités (entouré avec des devis doubles). La liste est actuellement: p>
croix, courant_date, courant_time, courant_timestamp, distinct, Sauf, existez, faux, pour, de, plein,
groupe fort>, ayant, intérieur, Intersect, est, rejoindre, comme, limite, moins, naturel, pas, null, on, Ordre, primaire, rownum, sélectionner, sysdate, systtime, systême, aujourd'hui, Vrai, union, unique, où p> Certains mots de cette liste sont des mots-clés car ils sont des fonctions qui peut être utilisé sans '()' pour la compatibilité, par exemple Current_Timestamp. P> blockQuote>
Ne faites pas cela ... s'il vous plaît. Vous vous ferez mal à la fin; Appelez-le simplement quelque chose qui n'est pas un mot réservé.
Comme @ben l'a suggéré, ce n'est pas une bonne idée d'utiliser des mots réservés. Vous pouvez toujours pré-corriger ou suffixer le nom de la colonne pour le rendre non réservé. Parfois, si je ne peux tout simplement pas préfixer ou suffixer un nom de colonne, je viens d'utiliser "le". Comme "TheGroup". Mais plus souvent que non, vous pouvez trouver un préfixe logique ou un suffixe, comme "groupe groupe" ou "Authorist" (utilisez le nom représentant le groupe pour le préfixer.).
Ajouter un La spécification SQL explicitement promet † sup> qu'aucun mot clé n'aura jamais un soulignement de fuite. Donc, vous êtes assuré que tout nommage que vous créez avec un soulignement de fuite ne collide jamais avec un mot-clé ou un mot réservé. P>
Je nomme toutes mes colonnes, contraintes, etc. dans la base de données avec un soulignement de fin. Cela semble un peu bizarre au début, mais vous vous habituez à le voir. S'avère avoir un effet secondaire agréable: dans toute la programmation ainsi que les notes et les courriels, lorsque je vois le soulignement de fin, je sais que le contexte est la base de données par opposition à une variable de programmation ou à un terme d'entreprise. P>
Un autre avantage est la tranquillité d'esprit. Un tel soulagement pour éliminer une classe entière de bugs possibles et des problèmes étranges en raison de la collision de mots-clés. Si vous pensez, "Aucun gros problème - Quels sont quelques mots clés SQL pour mémoriser et éviter", repensez-y à nouveau. Il y a Zillion Mots-clés et mots réservés , un zillion em> étant plus de mille. p>
La réponse de Shiva est également correcte: ajout de citations autour du nom, Conseil supplémentaire: pour une compatibilité maximale sur diverses bases de données SQL, faites votre nommée en minuscules. La spécification SQL indique que tous les noms doivent être stockés en majuscule tout en tolérant minuscule. Mais malheureusement, certaines bases de données (la plupart?) Ne suivent pas les spécifications à cet égard. Après des heures d'étude de diverses bases de données, j'ai conclu que toutes les minuscules vous donnent une portabilité maximale. P>
Donc, je vous suggère de nommer votre colonne: Noms de mots multiples ressemblent à ceci: † sup> Je ne peux pas citer la spécification SQL car il est copyright protégé, malheureusement. Dans le SQL: 2011 SPEC, LIRE SECTION 5.4 Noms et identificateurs EM> Sous la rubrique Règles de syntaxe em> point 3, note 111. Dans SQL -92 Voir la section 5.2, point 11. Juste la recherche du mot Groupe _ CODE> P>
"groupe" code>, résout le problème. L'inconvénient est que se souvenir d'ajouter ces citations sera fastidieuse et gênante. P>
groupe _ code> p>
donné_name _ code> et
date_of_first_contact _ code> p> p>
Underscore code> fonctionnera. P>
Vous pouvez citer des travaux protégés par le droit d'auteur; L'utilisation équitable vous permet de citer des pièces insuffistantes tant que vous indiquez l'origine du travail et ne copiez pas les montants «substantiels» ...
@Ben je n'emploie pas de personnel d'avocats. ANSI et ISO font probablement.
La spécification SQL explicitement promet explicitement † qu'aucun mot clé n'aura jamais un soulignement de fuite. Code> <- C'est très important. Mais pourquoi dites-vous aussi à propos de
de soulignement principal code>? Je veux dire
que tout nommant que vous créez avec un soulignement de direction ou de fin de course>.
@Pavel_k je ne sais pas pourquoi j'ai écrit "leader ou la traînée" là-bas. Je l'ai corrigé, supprimant le "leader ou". Les brouillons disponibles au public des spécifications SQL que j'ai vus n'ont été promis uniquement pour éviter Trailing i> Un soulignement dans les identifiants / noms. Merci d'avoir souligné cela.
J'ai eu ce problème avec SQL généré par JPA ... La classe avait un champ appelé limite. p>
Le correctif consiste à spécifier le nom de la colonne comme p>
J'ai essayé avec quelques bases de données (PostgreSQL, MySQL, SQLite, Apache Derby, HSQLDB). Tous i> d'entre eux rejeter des colonnes nommées
groupe code>.