dwayne@rover.bsd.uchicago.edu (02/22/89)
I am working on a medical study which essentially makes no sense to break up into smaller tables. It is basically a questionairre 80% of which are y/n/u questions. Intermixed, of course, is floating point and character data types. Well, I hit that legendary boundary of 127 columns in a table early on, so we whittled the data set down to that size. Now I set up an ABF call to QBF which calls up my ViFRED form no problem. But if I try to either retrieve or modify then QBF tells me that there are too many fields, it then returns to the QBF main menu. Like I said before, breaking my questionnaire up into several tables isn't what I want to do. Selects will get hairy, and frankly I would prefer that our physicians just use the default query mechanisms of Ingres. So, with that in mind, does anybody have any ideas that might help me get around this (I think undocumented) limitation??? Thanks in advance... Dwayne P.S. I'm running Ingres vers.5 under VMS vers.4.7.
pavlov@hscfvax.harvard.edu (G.Pavlov) (02/22/89)
In article <1949@tank.uchicago.edu>, dwayne@rover.bsd.uchicago.edu writes: > I am working on a medical study which essentially makes no sense to > break up into smaller tables.... > Well, I hit that legendary boundary of 127 columns in a table early > on, so we whittled the data set down to that size. Now I set up an > ABF call to QBF which calls up my ViFRED form no problem. But if I > try to either retrieve or modify then QBF tells me that there are too > many fields, it then returns to the QBF main menu. > > ...... So, with > that in mind, does anybody have any ideas that might help me get around > this (I think undocumented) limitation??? > This limitation drives us nuts (we work with medical data also). With all the real improvements, many quite complex, that RTI has been/is implementing, it does not seem that changing this would require quite that much effort. You're stuck. Simplistically speaking, almost anything you do will result in the "creation" of a table (logical, real, or otherwise...), and the limit applies to any manifestation of such. greg pavlov, fstrf, amherst, ny
jkrueger@daitc.daitc.mil (Jonathan Krueger) (02/23/89)
In article <1949@tank.uchicago.edu>, dwayne@rover writes: >[he has] a questionairre 80% of which are y/n/u questions >[the rest] is floating point and character data types. > >Well, I hit that legendary boundary of 127 columns in a table >does anybody have any ideas that might help me get around >this (I think undocumented) limitation [without breaking into tables]??? It's documented in 4 places I know of: QUEL and SQL ref manual, UNIX and VMS Database Administrator's Guide. Forms limits are documented in Addendum C to Release 5.0: 127 cols per table field 4000 chars form width 150 chars trim length 50 field title length Number of components on a form (trim plus simple fields plus table fields) is unlimited. Workaround: change design from person(id, age, weight, socksize, symp1, symp2, symp3 . . .) to person(id, age, weight, socksize) symptom(id, symptom) Modify data entry to choose symptoms from a tablefield. Place most common symptoms at top of tablefield. Good pts: makes it easy to query through forms who has anxiety OR sweating OR nightmares. Bad pts: loses distinction between no and unknown. If distinction makes no difference in the real world, this is fine. Otherwise must change design, say to person(id, age, weight, socksize) present(id, symptom) absent(id, symptom) -- Jon --
dwayne@rover.bsd.uchicago.edu (02/24/89)
I wrote >>Well, I hit that legendary boundary of 127 columns in a table >>does anybody have any ideas that might help me get around >>this (I think undocumented) limitation [without breaking into tables]??? I guess I didn't make myself very clear in my original posting. The problem is that there appears to be a ** 126 ** column limit, count it, not 127 on retrieves and modifies in QBF. According to RTI this is indeed correct and there not much someone can do about it. However, word has it that 6.0 will have higher limits all around. My answer is to delete yet another field off of my form (I started with 200+ fields). Again, my reason for leaving the data in one table (as you medical guys surely know) is because in clinical environments nobody knows what will potentially be interesting. They want to have the ability to do quick and dirty queries on whatever seems publishable that day. Our physicians would have neither the time nor the inclination to learn/use SQL/QUEL. Certainly a questionnaire type study is not the best use for a relational database. But for creating a form with which they can logically query the data with out much instruction, it is a nice, quick solution. Dwayne Spradlin dwayne@rover.bsd.uchicago.edu
pscaaf@vms.macc.wisc.edu (Ron Peterson) (02/24/89)
In article <349@daitc.daitc.mil>, jkrueger@daitc.daitc.mil (Jonathan Krueger) writes... >In article <1949@tank.uchicago.edu>, dwayne@rover writes: >>[he has] a questionairre 80% of which are y/n/u questions >>[the rest] is floating point and character data types. >> >>Well, I hit that legendary boundary of 127 columns in a table >>does anybody have any ideas that might help me get around >>this (I think undocumented) limitation [without breaking into tables]??? If you will represent the response of several questions as one column using character strings you will reduce the number of columns that you will need. "ynuyn" would correspond to 5 questions y n u y n
jkrueger@daitc.daitc.mil (Jonathan Krueger) (02/26/89)
In article <1229@dogie.edu>, pscaaf@vms (Ron Peterson) writes: >If you will represent the response of several questions as one column using >character strings you will reduce the number of columns that you will need. >"ynuyn" would correspond to 5 questions y n u y n How do you remove a question? Yes, it can be done. But workarounds that preserve at least 1NF are highly desirable. -- Jon --
jkrueger@daitc.daitc.mil (Jonathan Krueger) (02/26/89)
In article <1979@tank.uchicago.edu>, dwayne@rover writes: >The problem is that there appears to be a ** 126 ** column limit, count >it, not 127 on retrieves and modifies in QBF. That's interesting. QBF retrieves the tuple id (tid) too. Sounds like that's the missing column. "Set printqry" tells this kind of stuff. >Certainly a questionnaire type study is not the best use for a relational >database. But for creating a form with which they can logically query >the data with out much instruction, it is a nice, quick solution. I disagree. I think the relational model well suited. And I've seen some uses which validate this notion. Ease of ad hoc queries wasn't high on users' lists though. They needed secure and reliable operation, ease of data entry, and well-defined external interfaces to programs for random assignment and packages for statistical analysis. After that came programmer productivity, software re-use issues. After that, ad hoc queries. However, they shared the general goal of ease of use. They found the relational model a good framework around which to build user-friendly front ends. -- Jon --
pscaaf@vms.macc.wisc.edu (Ron Peterson) (02/28/89)
In article <354@daitc.daitc.mil>, jkrueger@daitc.daitc.mil (Jonathan Krueger) writes... >In article <1229@dogie.edu>, pscaaf@vms (Ron Peterson) writes: >>If you will represent the response of several questions as one column using >>character strings you will reduce the number of columns that you will need. >>"ynuyn" would correspond to 5 questions y n u y n > >How do you remove a question? > >Yes, it can be done. But workarounds that preserve at least 1NF are >highly desirable. > I was not being very clear. Assuming that the same questionaire is given to everyone, my example would pertain to questions 1 thru 5. A question could not be removed. However, it is usually unsafe to remove columns in a table. 1NF would not be violated because there are a fixed number of replies. If the relational database can handle more columns or if the users have a reasonable amount of database training, I would not use this technique. It depends on the the database having good string manipulation functions, which are sometimes absent.
markd@rtech.UUCP (Mark P. Diamond,4th Floor NW. Cor.,3324,4156548275,universe(ucb)) (03/11/89)
From article <610@manta.NOSC.MIL>, by vollmer@manta.NOSC.MIL (Tom Vollmer): > > I think the reason the RT position is so hard to accept is to those of > us who work with BSD so sucessfully everyday, its hard to understand > why a BSD market would not be attractive. INGRES Version 6 is an entirely re-architected product. As Dave Brower mentioned earlier, shared memory is a cornerstone of the new architecture. If there were an easy way to work around this, as Dave mentioned RTI would be happy to do it. This is not so much a marketing decision as an engineering decision on future technology. I would hazzard a guess that a "fix" so that Version 6 could run on systems without shared memory would be deadfully slow at best, unaccomplishable at worst. Mark <> Mark P. Diamond {amdahl,mtxinu,sun,hoptoad}!rtech!markd markd@rtech.com *The Chairman of Rolls-Royce [which makes aircraft engines] was asked why * *he always flew the Atlantic in four-engined aircraft. His reply: "Because* *there are no five-engined aircraft." *
pavlov@hscfvax.harvard.edu (G.Pavlov) (03/11/89)
In article <610@manta.NOSC.MIL>, vollmer@manta.NOSC.MIL (Tom Vollmer) writes: > > Summarizing the proposed reasons we have seen so far for RT Ingres not > porting their 6.x release to 4.3BSD: > > 1. There is not enough UNIX 4.3BSD market for Ingres licenses > currently or in the future as RT sees it. > 2. There are the technical problems of shared memory with 4.3BSD. > 3. Current and future business opportunties with DEC mandate > weak support for future BSD releases. > 4. BSD Unix is not "vendor" supported and thus a problem. Let me add a few more: 5. RTI doesn't do ports when the moon is full, and the schedule called for the BSD port to start during a full moon; 6. RTI hates the Naval Observatory; 7. RTI has the sadistic bent of liking to see its customer base twisting in the wind. - e.g., just `cause you saw it in "print" here don't mean that it is true. My own experience is that RTI is more forthright than most companies regar- ding decisions that are driven by marketing. You should take a close look at recent user group meeting transcripts. greg pavlov, fstrf, amherst, ny