Statalist The Stata Listserver


[Date Prev][Date Next][Thread Prev][Thread Next][Date index][Thread index]

Re: st: The number of variables is limited by Stata: tradeoff between larger database and smaller one?


From   Jia Xiangping <jiajoseph@googlemail.com>
To   statalist@hsphsun2.harvard.edu
Subject   Re: st: The number of variables is limited by Stata: tradeoff between larger database and smaller one?
Date   Thu, 26 Jan 2006 04:55:05 +0800

Dear colleagues,

Thanks to Kolenikov. What I'm doing now is having the questionnaire
number as KEY INDEX, so that I can merge different models at my will.
Yes, the -keep()-option is very helpful. What I'm wondering now is
what's the professional approach to deal with this situation, large
"mother-database" or individual database with different topics?





On 1/25/06, Stas Kolenikov <skolenik@gmail.com> wrote:
> If you have the funds, SE is certainly worth upgrading. Otherwise,
> keeping the roster as the master set, and merging the topics is
> probably the best option. -merge- is a somewhat more fool-proof and
> advanced operation than -append-, and you can tune it up to your needs
> with options like -keep()-, -unique-, etc. (or whatever the analogues
> of those were with Stata 8, or use Wessie's -mmerge- instead).
>
> On 1/25/06, Jia Xiangping <jiajoseph@googlemail.com> wrote:
> > Dear colleagues,
> >
> > The database I'm doing is based on the questionnaires which have more
> > than 10,000 variables. Because the version I'm using is Intercooled
> > Stata 8, so I have to divide it into several sub-database in terms of
> > topics concerned. At the beginning, I really enjoyed this style
> > because it's convenient for me to process data with similar topic.
> > However, problems come out when I further the data analysis. I have to
> > merge the variables from one database to others, and sometime it's
> > dirty and insecure.
> >
> > Hereinafter there are two options I can envision (may be there are
> > some other alternatives which I don't know):
> >
> > 1. Establish a mother-database with all variables in it, and then
> > -keep- the sections concerned.
> >
> > 2. Still having the sub-database and merge those you are interested in.
> >
> > If the advantages to apply the first approach obviously outweigh the
> > second, I've got to purchase the SE version which can cope with 32,767
> > variables.I have no experience in coping with such a tricky database.
> > Are there anybody who can give me some suggestions on it? Thanks.
> >
> >
> >
> > --
> > Xiangping JIA
> >
> > *
> > *   For searches and help try:
> > *   http://www.stata.com/support/faqs/res/findit.html
> > *   http://www.stata.com/support/statalist/faq
> > *   http://www.ats.ucla.edu/stat/stata/
> >
>
>
> --
> Stas Kolenikov
> http://stas.kolenikov.name
>
> *
> *   For searches and help try:
> *   http://www.stata.com/support/faqs/res/findit.html
> *   http://www.stata.com/support/statalist/faq
> *   http://www.ats.ucla.edu/stat/stata/
>


--
Xiangping JIA

*
*   For searches and help try:
*   http://www.stata.com/support/faqs/res/findit.html
*   http://www.stata.com/support/statalist/faq
*   http://www.ats.ucla.edu/stat/stata/



© Copyright 1996–2021 StataCorp LLC   |   Terms of use   |   Privacy   |   Contact us   |   What's new   |   Site index