Cela n'a vraiment pas d'importance où la colonne est physiquement depuis select vous permettra de spécifier l'ordre (logique) dans lequel ils sont récupérés.
Et, si vous utilisez select * qui ne vous permet pas de spécifier l'ordre, vous ne devriez probablement pas l'être. Il y a peu de situations où vous devriez faire cela (outils d'analyse de base de données, par exemple), la plupart du temps, il est préférable de sélectionner les colonnes individuelles que vous voulez, même si vous les voulez toutes. Cela vous permet d'intercepter rapidement les changements de schéma afin que vous puissiez y adapter vos programmes.
Dans tous les cas, SQL lui-même ne garantit pas l'ordre dans lequel les colonnes sont renvoyées, sauf si vous explicitement listez-les. select * peut vous les remettre par ordre ordinal aujourd'hui et par ordre alphabétique demain. Même si une implémentation particulière vous permet de le faire (en créant une nouvelle table avec la colonne au "bon" endroit et en copiant les données à travers, ou en fournissant une extension SQL comme alter table T insert column C1 before C2 ), je le déconseille. Il ne sera pas portable vers d'autres implémentations et je préfère que mon code soit aussi portable que possible.
De plus, au-delà de ce que vous pouvez spécifier en SQL, un SGBD devrait pouvoir contrôler totalement comment il stocke des données. Il se peut que votre clé primaire soit un composé de la septième et de la quarante-deuxième colonne et il peut être plus efficace de les avoir au début des enregistrements physiques.
