Date: Mon, 18 Jan 1999 22:59:04 +0000
Reply-To: John Whittington <medisci@POWERNET.COM>
Sender: "SAS(r) Discussion" <SAS-L@UGA.CC.UGA.EDU>
From: John Whittington <medisci@POWERNET.COM>
Content-Type: text/plain; charset="us-ascii"
Peter Crawford <Peter@CRAWFORDSOFTWARE.DEMON.CO.UK> wrote (in a message
whose header got a bit messed up):
>I'm assuming the variable order is the physically stored order.
>Please let me know if I'm wrong.
Peter, I have tried to make it clear that (although that may generally be
the case at present) I do NOT think that it's the 'physically stored order'
which matters - what concerns us is the 'functional order' (i.e. as will be
reflected by a PUT _ALL_ or PROC PRINT) - and that could, in theory, be
achieved by manipulating a dataset header without altering the 'physically
stored order' of the data - and, more significantly, without having to read
or re-write any of that data.
>Reading through all this, I'm picking up the principle that
>rearranging the columns physically, should be avoided for data sets
>of significant size (or was all that stuff only about small sets?):
I'm not sure who you think said that - it certainly wasn't me. As above, my
ideal would be not to do any 'physical rearranging of columns' at all!
>So this idea of a proc datasets update to the data set header would
>have its limits.
Eh? - surely the whole point of that approach would be that it changed the
header information without any physical re-arrangement of the 'columns' of data.
>Do we want to detach physical order from presentation order ?
>Already an sql or datastep view can achieve this.
As far as I am concerned, such detachment would, indeed, be the ideal.
Indeed, as jack has pointed out, and ORDER= option to the PUT statement (and
also probably PROC PRINT etc.) would be one solution. I agree that both SQL
and views already offer solutions, but that is not, in itself, a reason for
not pursuing the other approaches we've been discussing. A DATA step view,
in particular, could be a very inefficient method, because the whole
're-ordered' dataset (which might be enormous) would effectively ahve to be
re-created every time the view was invoked.
>Whether or not we want to detach this link between presentation and
>stored order, the problem of the order of the variables in the
>dataset, should be looked at from further back....
> ... like:
> why is the data in that order anyway ?
In my line of work, the answer is often that my client chose to put it in
> how to improve the generating the data to get best order
If one is creating the datasets oneself, there is generally no problem -
but, as above, the datasets may come from someone else. Anyway, even if one
has generated the (functional) order one wants for one purpose, another
purpose may require a change of that order.
> who justifies multiple var. orders (!? & without views ?)
I'm not sure I understand this point/question, but I may have partially
answered it above!
>A real application can usually be designed to set the order up right
>to start with.
Again, I often have to deal with datasets created by nameless others!
>Given the options (for ordering variables) currently available and
>despite the best endeavours of several postings to justify the idea,
>I still see no payback from the overhead needed to support flexible
>variable order within the data set header.
I see no reason why there has to be any 'overhead' to such an option. We
all agree that there are plenty of ways of re-ordering with SAS as it is,
just as there are several ways of determining a square root, but that is
not, to my mind, a good reason to write off the idea of an explicit facility
for determining (or changing) order. Methods which could operate purely at
the level of the header (if that is possible within the header structure)
would, of course, be far preferable to any of the methods currently
available - particularly for large datasets.
Dr John Whittington, Voice: +44 (0) 1296 730225
Mediscience Services Fax: +44 (0) 1296 738893
Twyford Manor, Twyford, E-mail: email@example.com
Buckingham MK18 4EL, UK firstname.lastname@example.org