L'alias de table est-il une mauvaise pratique?

Je me souviens avoir appris à le faire dans un cours SGBD pour les étudiants en Master of Information Services. Pour vous éviter de taper, vous pouvez taper:

SELECT t1.id, t2.stuff 
FROM 
              someTable    t1 
   INNER JOIN otherTable   t2 
      ON t1.id=t2.id
;

Mais ... Pourquoi est-ce acceptable dans les procédures stockées et autres? Il semble que tout ce qu'il fait est de nuire à la lisibilité de la déclaration tout en économisant un temps extrêmement mineur. Y a-t-il une raison fonctionnelle ou logique de le faire? Il semble ajouter de l'ambiguïté plutôt que la supprimer; la seule raison acceptable que je peux voir pour utiliser ce format est que vous ajoutiez un alias sémantiquement significatif - par exemple, FROM someTable idsTable- lorsque le nom de la table n'est pas suffisamment descriptif.

L'alias de table est-il une mauvaise pratique ou s'agit-il simplement d'une mauvaise utilisation d'un système utile?

Le repliement de table est une pratique courante et utile.

• Il vous évite les frappes lors du référencement des colonnes n'importe où dans votre requête.
• Il améliore la lisibilité de votre SQL lorsque vous référencez de nombreuses tables. Les alias vous permettent de donner à ces tables un nom court et un peu de sens à la façon dont elles sont utilisées.
• Il est même requis lorsque vous joignez une table à elle-même ou lorsque vous vous joignez à la même table plusieurs fois. C'est ainsi que l'optimiseur de requête sait à quelle table vous faites référence lorsque vous mentionnez une colonne.

L'extrait de rapport suivant illustre bien tous les points ci-dessus:

INSERT INTO reporting.txns_extract
SELECT 
    -- 30+ columns snipped
    -- 
    -- Would you want to type out full table names for each 
    -- column here?
FROM 
    -- ... and in the JOIN conditions here?
                billing.financial_transactions  ft_cdi   -- alias required here
    INNER JOIN  
                billing.cash_application_links  cal
            ON  ft_cdi.key_num = cal.applied_ft_key_num
    INNER JOIN  
                billing.financial_transactions  ft_pmt   -- alias required here
            ON  cal.owner_key_num = ft_pmt.key_num
    LEFT OUTER JOIN
                billing.invoice_lines           invl
            ON  ft_cdi.key_num = invl.invoice_key_num
    LEFT OUTER JOIN
                billing.charges                 chrg
            ON  invl.creator_key_num = chrg.key_num
    LEFT OUTER JOIN
                billing.customer_services       cs
            ON  chrg.cs_key_num = cs.key_num
    INNER JOIN
                billing.billers                 bil
            ON  ft_cdi.biller_account_key_num = bil.biller_account_key_num
    INNER JOIN
                billing.formal_entities         fe
            ON  bil.frml_key_num = fe.key_num
WHERE
    -- ... and in the WHERE conditions here?
        ft_cdi.transaction_type <> 'Payment'   -- alias tells me this table is not for payments
    AND ft_cdi.status = 'Approved'
    AND ft_pmt.transaction_type =  'Payment'   -- alias tells me this table is for payments
    AND ft_pmt.status = 'Approved'
    AND ft_cdi.last_user_date >   ft_last_user_date_begin
    AND ft_cdi.last_user_date <=  ft_last_user_date_end
;

Je pense que l'utilisation d'alias aide à la lisibilité d'une requête si les noms de table sont longs ou si similaires les uns aux autres que quelqu'un qui les lit rapidement peut les confondre. Pensez-vous que cela ...

SELECT Really_long_table_name.ID,
       Even_longer_table_name_than_before.Name,
       Even_longer_table_name_than_before.Description,
       Even_longer_table_name_than_before.State
FROM   Really_long_table_name
       INNER JOIN Even_longer_table_name_than_before
               ON Really_long_table_name.ID = Even_longer_table_name_than_before.ID
WHERE  Really_long_table_name.Department = 'Whatever' 

est plus lisible que cela?

SELECT a.ID,
       b.Name,
       b.Description,
       b.State
FROM   Really_long_table_name a
       INNER JOIN Even_longer_table_name_than_before b
               ON a.ID = b.ID
WHERE  a.Department = 'Whatever' 

Selon ce que vous utilisez comme alias de table, cela peut rendre la requête beaucoup plus simple à lire et à comprendre.

L'aliasing de table (pour des noms de table plus courts) n'est pas une mauvaise pratique.

Je l'utilise normalement lorsque les noms de table sont longs et n'utilise que l'alias qui a du sens:

SELECT tTable.stuff FROM track_table tTable;

Si vous souhaitez améliorer la lisibilité, vous pouvez utiliser le ASmot - clé:

SELECT tTable.stuff FROM track_table AS tTable;

Mais, comme vous vous habituez à la syntaxe, ce n'est pas nécessaire.

Vous pouvez l'utiliser pour augmenter considérablement la lisibilité de vos requêtes. Plutôt que d'utiliser un alias court, utilisez votre alias pour décrire les données auxquelles vous vous joignez, par exemple

SELECT
    transaction.unique_id,
    authorisingUser.name AS authorising_user_name,
    requestingUser.name AS requesting_user_name
FROM transactions AS transaction
JOIN users AS authorisingUser
    ON authorisingUser.user_id = txn.authorising_user_id
JOIN users AS requestingUser
    ON requestingUser.user_id = txn.request_user_id

Bien que l'utilisation d'alias extrêmement courts (comme aou t1) puisse rendre une requête difficile à lire car vous devez aller chercher l'alias pour rechercher ce que l'alias signifie, un alias bien nommé peut souvent rendre une requête plus lisible que d'utiliser simplement la table des noms.

Il s'agit d'une question de "mauvaise pratique". Les réponses semblent concerner la «sauvegarde des frappes».

Personnellement, ma vitesse de codage est limitée par ma vitesse de pensée, pas par ma vitesse de frappe. Je trouve que le code avec beaucoup d'alias de table est beaucoup plus difficile à lire que le code qui utilise les noms de table eux-mêmes. Les alias de table ajoutent un autre niveau d'indirection.

Cependant, la plupart des programmeurs utilisent des alias de table (mais pas moi). Certains "environnements de développement SQL" rendent cela très facile à faire, et certains enseignants enseignent automatiquement les alias de table, en particulier dans le cadre de l'apprentissage de la syntaxe "Join".

L'utilisation d'alias de table n'est pas une mauvaise pratique, mais parfois je dois parcourir le code et remplacer les alias par les noms de table d'origine afin de comprendre ce qui se passe.