Arev 2.03 - Maximum number of fields in db (AREV Specific)
At 23 DEC 1998 01:21:01PM GLMarx wrote:
Hello,
I'm building a Job Tracking system. Originally I was expecting to use five different dbs and join/tie them together programaticly.
But the boss wants one continous db …
By my estimation I'm looking at roughly 1500 fields of data.
Can Arev 2.x handle this many fields comfortably?
I checked the docs for my Arev 3.x setup but didn't find anything specifically mentioned …
Thanks,
Gregory L. Marx
GraySoundComm@att.net
At 23 DEC 1998 02:07PM Serguei wrote:
GLMarx wrote:
]But the boss wants one continous db …
]By my estimation I'm looking at roughly 1500 fields of data.
I think your main problem will be not to exceed 64K limit.
(and your boss is definitely wrong
)
Serguei
At 23 DEC 1998 02:23PM Matt Sorrell wrote:
Gregory,
Instead of one table with 1500 fields of data, why don't you normalize your data to some extent, and make several different tables that you then link together. If you were going to make 5 different databases, you could logically make 5 separate tables along the same lines.
If separate tables is what you were referring to, my apologies. Then, I agree with Serguei, your boss is definitely wrong. Database normalization theory exists for a reason.
Matt Sorrell
At 23 DEC 1998 08:13PM K Gilfilen wrote:
Your boss may be thinking of problems of linking related data, and problematic indexing. Those are the only reasons I can think of for stuffing it all in one record. But huge record sizes may beome a problem too. I can't imagine a cost/benefit analysis that yields one table with 1,500 fields. Not in relational, heirarchical or AREV DBMSs.
Every control structure that is not broken down into different tables is threatened; the fields record, protect_spec, and what else am I forgetting?
But you can probably do it, if you are careful, and can guarantee that everyone in the future is equally careful. Oh yeah, it will be a maintenance headache, and will probably be a legacy application before it gets out of the chute. Any future growth will be limited…
At 25 DEC 1998 01:36PM Victor Engel wrote:
This is something I've had some experience with, having worked with HR-1, which crams as much as possible into the EMP file. We actually maxed out at one point, and remedial action was taken. Currently, there are just over 1400 records in the dictionary. The size of
%FIELDS% is about 50K. So far individual record size has not been a problem, the largest record being about 12K.
The place we ran into the max was %FIELDS% maxing out. Including all the symbolic fields, a summary could not be saved in this record. The temporary solution I elected to use was to trim out some stuff from the %FIELDS% record. Since then, we have gone through and eliminated most of the obsolete fields.
My strong recommendation would be to put related fields together on separate files. The main reason is for reporting. With 1500 fields, your record size will be quite large thus significantly slowing down reports. Using the exact same data, if I create a file using only the 10 or 15 fields I commonly use to select, etc., a report can run about 10 times faster.
At 30 DEC 1998 04:12PM Warren wrote:
Victor sums the problems of having a large number of fields up nicely. My experience with working on installations of HR1 with enormous EMP files bears out what Victor says.