Oui et non :-)
SQL lui-même ne se soucie pas quel ordre les colonnes sortent dans mais, si vous deviez utiliser:
select age, name, sex from ...
vous trouveriez qu'ils ont probablement est sorti dans cet ordre (même si je ne suis pas sûr que les normes SQL le mandatent).
Maintenant, vous ne peut pas veulent faire cela, mais parfois la vie est injuste :-)
Vous avez également l'autre possibilité d'utiliser les tables de définition de données SGBD pour construire dynamiquement une requête. Ce n'est pas portable, mais la plupart des SGBD fournissent ces tables (telles que SYSIBM.SYSCOLUMNS
de DB/2) et vous pouvez sélectionner les noms de colonnes de manière ordonnée. Quelque chose comme:
select column_name from sysibm.syscolumns
where owner = 'pax' and table_name = 'movies'
order by column_name;
Ensuite, vous utilisez les résultats de qui requête pour construire la vraie requête:
query1 = "select column_name from sysibm.syscolumns" +
" where owner = 'pax' and table_name = 'movies'" +
" order by column_name"
rs = exec(query1)
query2 = "select"
sep = " "
foreach colm in rs:
query2 += sep + colm["column_name"]
sep = ", "
query2 += " from movies order by rating"
rs = exec(query2)
// Now you have the rs recordset with sorted columns.
Cependant, vous devriez vraiment examiner de manière critique toutes les requêtes qui sélectionnent *
- dans la grande majorité des cas, c'est inutile et inefficace. Et la présentation des données est quelque chose qui devrait probablement être fait par la couche de présentation, pas le SGBD lui-même - le SGBD devrait être laissé pour retourner les données de la manière la plus efficace possible.
hmm, je suppose que je dois recourir à la bonne vieille méthode de tri des chaînes moi-même :) –
Je suis d'accord avec cela, ne jamais utiliser * dans le code de production. Vous ne savez jamais quand quelqu'un ajoute plus tard une colonne qui ne devrait pas être listée, pour des raisons de sécurité par exemple. Toujours construire la requête pour récupérer uniquement les colonnes dont vous avez besoin. Et si vous voulez le faire dynamiquement, faites-le, mais assurez-vous de le noter très visiblement pour que les autres développeurs puissent le voir. –
Encore une fois, si vous utilisez des vues SQL * a plus d'effets secondaires si les tables sous-jacentes sont changées (colonne nouvelle ou supprimée) la vue ne se met pas à jour et peut ne pas afficher de nouvelles colonnes colonne par l'indice qu'ils avaient sur la création de vue. –