It really doesn't matter where the column is physically since select will allow you to specify the order (logically) in which they're retrieved.
And, if you're using select * which doesn't let you specify the order, you probably shouldn't be. There are precious few situations where you should be doing that (DB analysis tools, for example), most of the time it's better to select the individual columns you want, even if you want them all. This allows you to catch schema changes quickly so you can adapt your programs to them.
In any case, SQL itself makes no guarantees about the order in which columns are returned unless you explicitly list them. select * may give them to you in ordinal order today and alphabetic order tomorrow. Even if a particular implementation allows you to do it (by creating a new table with the column in the "right" place and copying the data across, or providing an SQL extension like alter table T insert column C1 before C2), I'd advise against it. It won't be portable to other implementations and I prefer to have my code as portable as practicable.
In addition, beyond what you can specify in SQL, a DBMS should be able to totally control how it stores data. It may be that your primary key is a composite of the seventh and forty-second column and it may be more efficient to have them at the front of the physical records.
