Richard, > > I guess your "problem" comes from the fact that SQL has no concept of > > internal order. If you do not specify an ORDER BY clause, the order or > > records returned is undefined, i.e. random. > > That's what I was figuring. I asked because I wanted it confirmed. Thank > you. > > > Of course, MySQL has some kind of internal order depending on many > > factors, but you may not rely on it. And neither you may rely on the > > fact that a PRIMARY KEY influences the internal order. You have to use > > an ORDER BY clause if you want to get a sorted result (of course, you > > want a key to speed up the ORDER BY clause). > > Hmmm. Perhaps I'm misled by the default behaviour of other database engines, > but I was taught that the primary key was stored in the database to optimize > search/insert/delete - which meant *sorted*. That is why you don't want a > large (complex) primary key on tables that must run "fast" - the overhead of > sorting each insert/delete negatively affects performance. Or so I was taught, > anyway (back in the dark ages - primative data structures and all that <G>).
As others have said, this is not part of the relational model. However you are correct - back in the 'good old days' we could rely upon hierarchical databases to do this, and I'm fairly sure that the early 'SQL' DBMSes also used to do this because they physically separated the Primary Key and the 'dependent part' of the row, so that any 'straight' listing would come out in PK sequence. =dn --------------------------------------------------------------------- Before posting, please check: http://www.mysql.com/manual.php (the manual) http://lists.mysql.com/ (the list archive) To request this thread, e-mail <[EMAIL PROTECTED]> To unsubscribe, e-mail <[EMAIL PROTECTED]> Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
