On Wed, Jan 18, 2006 at 04:33:23PM -0800, Stephan Szabo wrote: > On Wed, 18 Jan 2006, Jim C. Nasby wrote: > > > Yeah, this isn't about production code, it's about making life > > easier on developers. Humans naturally want to group data into > > natural sets, so for example all the fields dealing with a > > person's address would appear together. But if you ever have to > > use ALTER TABLE to add a field you're stuck with that field being > > at the end of the table. > > > > Another consideration is that the best order for people isn't the > > best order for the database. For example, grouping fields of the > > same alignment together will save space (and depending on the > > table that savings can really start to add up). > > > > It would definately be nice if the end-user concept of column > > order wasn't tied to the physical order in the database. > > I agree with that. However, I'm not sure that an ALTER TABLE that > reorders a logical column set is necessarily the right way to handle > the issue. I think that the same path leads to realizations that a > single logical ordering may not be sufficient for development. > > For example, I could see cases where say person A wants all the > address columns together but person B only cares about country and > wants the columns he deals with together in some other fashion. Although it might be nice to have different column orderings, say per-role, the SQL:2003 standard requires a single canonical ordering in the information schema. How would we handle both? Cheers, D -- David Fetter david@xxxxxxxxxx http://fetter.org/ phone: +1 415 235 3778 Remember to vote!
