Dois-je toujours écrire des noms de table et de colonne en minuscules?
Je me demande si c'est un problème, si un nom de table ou de colonne contient des lettres majuscules. Quelque chose me permet de croire que les bases de données ont moins de problèmes lorsque tout est conservé en minuscules. Est-ce vrai? Quelles bases de données n'aiment aucun symbole majuscule dans les noms de table et de colonne?
J'ai besoin de savoir, car mon framework génère automatiquement le modèle relationnel à partir d'un modèle ER.
(cette question n'est pas de savoir si c'est un bon ou un mauvais style, mais seulement si c'est un problème technique pour une base de données)
Ce n'est pas un problème technique pour la base de données d'avoir des lettres majuscules dans vos noms de table ou de colonne, pour tout moteur de base de données que je connaisse. Gardez à l'esprit que de nombreuses implémentations DB utilisent des noms sensibles à la casse, donc faites toujours référence aux tables et aux colonnes en utilisant le même cas avec lequel elles ont été créées (je parle très généralement puisque vous n'avez pas spécifié une implémentation particulière).
Pour MySQL, voici quelques informations intéressantes sur la façon dont il gère la casse des identifiants. Il existe certaines options que vous pouvez définir pour déterminer comment elles sont stockées en interne. http://dev.mysql.com/doc/refman/5.0/en/identifier-case-sensitivity.html
Pour autant que je sache, il n'y a aucun problème à utiliser les majuscules et les minuscules. L'une des raisons de l'utilisation de la convention en minuscules est que les requêtes sont plus lisibles avec les noms de table et de colonne en minuscules et les mots clés sql en majuscules:
SELECT column_a, column_b FROM table_name WHERE column_a = 'test'
La norme SQL-92 spécifie que les identifiants et les mots clés ne respectent pas la casse (selon n guide de la norme SQL 4ème édition, Date/Darwen)
Cela ne veut pas dire qu'un SGBD particulier n'est ni (1) cassé, ni (2) configurable (et cassé)
Du point de vue du style de programmation, je suggère d'utiliser différents cas pour les mots clés et les identifiants. Personnellement, j'aime les identifiants majuscules et les mots clés minuscules, car cela met en évidence les données que vous manipulez.
Autant que je sache pour un L.A.M.P commun la configuration n'aura pas vraiment d'importance - mais sachez que MySQL hébergé sur Linux est sensible à la casse!
Pour garder mon code en ordre, je m'en tiens généralement aux noms en minuscules pour les tables et les colonnes, au code MySQL en majuscules et aux variables mixtes en majuscules et minuscules - comme ceci:
SELECT * FROM my_table WHERE id = '$ myNewID'
J'utilise la casse Pascal pour les noms de champ en minuscules pour les noms de table (généralement) comme suit:
students
--------
ID
FirstName
LastName
Email
HomeAddress
courses
-------
ID
Name
Code
[etc]
Pourquoi est-ce cool? parce qu'il est lisible et parce que je peux l'analyser comme:
echo preg_replace('/([a-z])([A-Z])/','$1 $2',$field); //insert a space
MAINTENANT, voici la partie amusante pour les tables:
StudentsCourses
--------------
Students_ID
Courses_ID
AcademicYear
Semester
remarquez que j'ai capitalisé S et C? De cette façon, ils pointent vers les tables primaires. Vous pouvez même écrire une routine pour analyser logiquement la structure db de cette façon et générer automatiquement des requêtes. J'utilise donc des majuscules dans les tableaux quand ce sont des tables JOIN comme dans ce cas.
De même, considérez le _ comme un -> dans ce tableau comme: Etudiants-> ID et Cours-> ID Pas student_id - au lieu de Students_ID - le parent du champ correspond au nom exact de la table.
L'utilisation de ces conventions simples produit un protocole lisible qui gère environ 70% de votre structure relationnelle typique.
La norme SQL requiert des noms stockés en majuscules
Le standard SQL requiert que les identifiants soient stockés en majuscules. Voir la section 5.2.13 du SQL-92 citée dans un projet de copie dans cette réponse sur une autre question. La norme vous permet d'utiliser des identifiants non délimités en minuscules ou en casse mixte, car le processeur SQL doit effectuer les conversions nécessaires pour effectuer la conversion vers la version en majuscules.
Cette exigence remonte probablement aux premiers jours de SQL, lorsque les systèmes mainframe étaient limités aux caractères anglais majuscules uniquement.
Pas de sortie
De nombreuses bases de données ignorent cette exigence par la norme. Postgres en particulier fait exactement le contraire, convertissant tous les identifiants sans guillemets ("non délimités") en minuscules - ceci malgré le fait que Postgres tienne autrement plus près de la norme que tout autre système que je connaisse. Certaines bases de données peuvent stocker l'identifiant dans le cas que vous avez spécifié.
Généralement, ce n'est pas un problème. Pratiquement toutes les bases de données effectuent une recherche insensible à la casse du cas utilisé par un identifiant au cas stocké par la base de données.
Il existe des cas de bizarrerie occasionnels où vous devrez peut-être spécifier un identifiant dans son cas stocké ou vous devrez peut-être spécifier tout en majuscules. Cela peut se produire avec certains utilitaires où vous devez passer un identifiant sous forme de chaîne en dehors du contexte de processeur SQL habituel. Rare, mais rangez-le à l'arrière de votre tête au cas où vous rencontriez un jour un mystérieux message d'erreur "ne peut pas trouver la table" lors de l'utilisation d'un outil/utilitaire inhabituel. M'est arrivé une fois.
Cas de serpent
De nos jours, la pratique courante semble être d'utiliser tous les minuscules avec des mots de séparation . Ce style est connu sous le nom de Snake case .
L'utilisation d'un trait de soulignement plutôt que cas Camel aide si vos identifiants sont jamais présentés en majuscules (ou en minuscules) et perdent ainsi la lisibilité sans la séparation de Word.
Astuce bonus: le standard SQL (SQL-92 section 5.2.11) promet explicitement de ne jamais utiliser de soulignement de fin dans un mot clé. Ajoutez donc un trait de soulignement à tous vos identifiants pour éviter tout risque de collision accidentelle.
Quoi que vous utilisiez, gardez à l'esprit que MySQL sous Linux est sensible à la casse, tandis que sous Windows il ne respecte pas la casse.
Si vous utilisez postgresql et PHP, par exemple, vous devrez écrire votre requête comme ceci:
$sql = "SELECT somecolumn FROM \"MyMixedCaseTable\" where somerow= '$somevar'";
"La citation d'un identifiant le rend également sensible à la casse, alors que les noms non cités sont toujours repliés en minuscules. Par exemple, les identifiants FOO, foo et" foo "sont considérés comme les mêmes par PostgreSQL, mais" Foo "et" FOO "le sont différents de ces trois et les uns des autres. (Le pliage des noms non cités en minuscules dans PostgreSQL est incompatible avec le standard SQL, qui dit que les noms non cités doivent être pliés en majuscules. Ainsi, foo doit être équivalent à "FOO" pas " foo "selon la norme. Si vous voulez écrire des applications portables, il est conseillé de toujours citer un nom particulier ou de ne jamais le citer.)" http://www.postgresql.org/docs/8.4/static/ sql-syntax-lexical.html # SQL-SYNTAX-IDENTIFIERS
Donc, parfois, cela dépend de ce que vous faites ...
Aucune base de données moderne ne peut gérer le texte en majuscule ou en minuscule.