Quels sont les avantages et les inconvénients de l'utilisation d'alias de table dans SQL? Personnellement, j'essaie de les éviter, car je pense qu'ils rendent le code moins lisible (surtout lors de la lecture de grandes déclarations où / et), mais je serais intéressé par tout contre-argument à cela. Quand est-ce généralement une bonne idée d'utiliser des alias de table et avez-vous des formats préférés?
Réponses
Trop de publicités?Eh bien, il ya certains cas, vous devez les utiliser, comme lorsque vous avez besoin d'adhérer à deux fois la même table dans une requête.
Cela dépend aussi si vous avez unique des noms de colonnes dans les tableaux. Dans notre ancienne base de données, nous avons 3-lettre de préfixes pour toutes les colonnes, issu d'une forme abrégée de la table, simplement parce que l'ancien système de base de données, nous avons été une fois compatible avec n'a pas de support des alias de table très bien.
Si vous avez des noms de colonnes qui se produisent dans plus d'une table, en précisant le nom de la table comme une partie de la colonne de référence est un must, et donc un alias de la table pour permettre une syntaxe plus courte.
Les alias de table sont un mal nécessaire lorsqu'il s'agit de schémas hautement normalisés. Par exemple, et comme je ne suis pas l’architecte de cette base de données, soyez patient avec moi, cela peut prendre 7 jonctions pour obtenir un enregistrement propre et complet incluant le nom, l’adresse, le numéro de téléphone et l’affiliation de la société.
Plutôt que les alias à caractère unique quelque peu standard, j'ai tendance à privilégier les alias de mots courts, de sorte que le code SQL de l'exemple ci-dessus se présente comme suit:
select person.FirstName
,person.LastName
,addr.StreetAddress
,addr.City
,addr.State
,addr.Zip
,phone.PhoneNumber
,company.CompanyName
from tblPeople person
left outer join tblAffiliations affl on affl.personID = person.personID
left outer join tblCompany company on company.companyID = affl.companyID
... etc
Suis-je la seule personne ici qui déteste vraiment eux?
Généralement, je ne les utilise pas, sauf si je dois le faire. J'ai vraiment la haine d'avoir lu quelque chose comme
select a.id, a.region, a.firstname, a.blah, b.yadda, b.huminahumina, c.crap
from table toys as a
inner join prices as b on a.blah = b.yadda
inner join customers as c on c.crap = something else
etc
Quand j'ai lu SQL, je voudrais savoir exactement ce que je suis en sélection quand je l'ai lu; alias réellement me confondre plus parce que j'en ai à slog par le biais de lignes de colonnes avant que je reçois pour le nom de la table, ce qui représente en général des informations sur les données que l'alias n'est pas. Peut-être qu'il est bon si vous faites les alias, mais j'ai souvent lu des questions sur StackOverflow avec le code qui semble utiliser des alias pour aucune bonne raison. (En outre, parfois, quelqu'un va créer un alias dans une déclaration et juste de ne pas l'utiliser. Pourquoi?)
Je pense que des alias de table sont utilisés de manière beaucoup parce que beaucoup de gens sont opposés à la frappe. Je ne pense pas que c'est une bonne excuse, si. Cette excuse est la raison pour laquelle nous retrouver avec de terribles appellation variable, terrible fonction acronymes, le mauvais code...je prendrais le temps de taper le nom complet. Je suis un rapide typer, bien que, peut-être qui a quelque chose à faire avec elle. (Peut-être dans le futur, quand j'ai le syndrome du canal carpien, je vais revoir mon avis sur les alias. :P ) surtout je déteste courir à travers les alias de table dans le code PHP, où je pense qu'il n'y a absolument aucune raison d'avoir à faire, il vous suffit de taper une fois!
J'ai toujours utiliser la colonne qualificatifs dans mes déclarations, mais je ne suis pas opposé à la saisie d'un lot, donc je serai heureux de taper le nom complet de multiples reprises. (Certes, je ne l'abus de MySQL onglet achèvement.) Sauf si c'est une situation où je dois utiliser un alias (comme décrit dans les autres réponses), je trouve la couche d'abstraction supplémentaire encombrants et inutiles.
Edit: (Plus d'un an plus tard) je m'occupe de certaines procédures stockées que l'utilisation d'alias (je n'ai pas écrit et je suis nouveau sur ce projet), et ils sont un peu douloureux. Je me rends compte que la raison pour laquelle je n'aime pas les alias est parce que de la façon dont elles sont définies. Vous savez comment il est généralement une bonne pratique de déclarer les variables au-dessus de votre portée? (Et généralement au début d'une ligne?) Alias SQL ne respectent pas cette convention, ce qui fait de moi grince des dents. Ainsi, je recherche un code pour un seul alias pour savoir où il est (et ce qui est frustrant, c'est, je dois lire à travers la logique avant que je trouve l'alias de la déclaration). Si ce n'était pas pour que, honnêtement, je pourrais, comme le système le mieux.
Si jamais je écrire une procédure stockée que quelqu'un d'autre aura à traiter avec, je suis en train de mettre mon alias définitions dans un bloc de commentaire au début du fichier, comme une référence. Honnêtement, je ne comprends pas comment les gars, vous n'allez pas fou sans elle.
L'optimiseur de requêtes de Microsoft SQL tire profit de l'utilisation de noms qualifiés complets ou d'alias.
Personnellement, je préfère les pseudonymes et, à moins que je n'ai beaucoup de tables, elles ont tendance à être des lettres simples.
--seems pretty readable to me ;-)
select a.Text
from Question q
inner join Answer a
on a.QuestionId = q.QuestionId
Il existe également une limite pratique sur la durée d'exécution d'une chaîne Sql - les alias facilitent son évitement.
Bon
Comme il a été mentionné à plusieurs reprises avant, c'est une bonne pratique de préfixer tous les noms de colonne de voir facilement la colonne qui appartient à la table - et alias sont plus courtes que d'une table des noms de sorte que la requête est plus facile à lire et donc de comprendre. Si vous utilisez un bon aliasing schéma de cours.
Et si vous créez ou lire le code d'une application, qui utilise stockées à l'extérieur, ou généré dynamiquement les noms de table, puis, sans alias, c'est vraiment dur de dire au premier coup d'œil ce que tous ces "%s"es ou d'autres espaces réservés à défendre. Il n'est pas un cas extrême, par exemple, de nombreux web apps permettent de personnaliser la table de préfixe de nom au moment de l'installation.