Date: Thu, 21 Feb 2008 11:34:41 -0500
Reply-To: Jim Agnew <agnew@VCU.EDU>
Sender: "SAS(r) Discussion" <SAS-L@LISTSERV.UGA.EDU>
From: Jim Agnew <agnew@VCU.EDU>
Subject: Re: Error with Proc IMPORT
In-Reply-To: <7367b4e20802210739v3ed6dd5fy2d9cf60783d275a0@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Hmm.. Fair enuf!!! ;-) One question, do we top-post in here, or
bottom post??? Anyhow...
Mary has pointed out about the thousands of base pairs she has to work
with...
I can normalize my ICU data, but it's rather pointless to have a
timestamp, pt id, and data type, and data value, when the same timestamp
can "hold" 10 different items... the disk space for all those millions
of timestamps is quite significant!
Also, in SAS when we analyzing that data, the procs seem to do better
with flat tables rather than normalized data..
also with medical forms, sometimes there is a LOT of data on one form..
also, there can be cases (hint) where someone who was passing themself
off as a db person designs something, leaves, and then when we try to
mod the system, find all of the tables are filthily right up to Access'
limit... we went into deep doo-da.. that's another reason to want
longer table widths, to accommodate some really bad design that was
politically needed. go figure..
data _null_, wrote:
> Can you give an example?
>
> I believe that it is easier, using SAS, to create meta data from data
> than the other way round. Said another way it is easier to create
> wide from tall, but not as easy to get tall from wide. I would
> suggest there are no situations where normal is bad, but many
> situations where wide is "bad" or at least cumbersome.
>
>> Data_Null_ is right in most cases, tho.
> I'm still learning.
>
--
"Games? Solitaire? I have a 2-node VAXcluster, 2 Windows 2000 servers, 1
Windows 2003 server, 1 MySQL server, 1 Linux server, several Ubuntus and
a direct satellite feed to my windows desktop background, who needs
toys???" - Jim
| 
