table text size theory

[robmkimmons]

In a table of a few thousand entries, which is more efficient?

-One text field with a field size of 50
OR
-Two text fields with their sizes at 25

Or are both so close that it's not much of an issue?

~Rob

If we expect the unexpected, does that make the unexpected... well, expected?

 

[psemianonymous]

Efficiency is more a case of order of magnitude, or the O(N). Both methods are O(N), so they'll be roughly the same.

So what I'm saying is that even if one was 20% faster than the other, you're still only getting a 20% gain (minutes -> less minutes), whereas if you index the field if it's necessary, you'll get a gain something like an order of magnitude (minutes -> seconds; O(N) -> O(log N) ). So I'm saying either way will work.


Though, for data validity, if you're storing two different values, by all means store them in different fields. But that's not a speed issue, it's a usability issue.

Keep them split.

 

[WildHare]

Although I agree with Foolio conceptually, if you think about it, in a database with only a few thousand records, you have already used more time up composing and posting a message here, than you would ever save by adopting one view or another in an effort to save time.



I'm not trying to be a smart-aleck here either - it's just that a modern (say, PIII or above) PC with a reasonably swift Hard drive and anything more than 64MB of memory is going to be able to chew through a 75K record table in a blink of an eye, more or less. It's going to be spending 99.9% of the time waiting for keyboard input.

Plus, since Access stores variable record lengths, if you have 22 total characters, it's gonna take up 22 bytes, and if you have 47 characters, it's gonna take up 47 bytes. So I'd split if the analysis determines that you need it, or leave it be if it really is one field that could contain up to 50 characters. Then I'd probably set the data length to 100 and forget the whole thing..

Efficiency tune ups, if we face reality, are really only cost effective if THEY SAVE MORE TIME THAN THEY TAKE TO DEVELOP. It's frequently not worth two days of programmer time to save 1/10th of a second of transaction time, unless you do a poop-load of transactions per day, and expect to keep doing them for a long time.

This is not to say that attempting to design and implement a system with efficiency considerations is a bad thing - just that you have to balance esthetics against reality sometimes. This was a hard lesson for me to learn, as I used to spend hours adjusting the BUFFERS= line in my config.sys to get a more or less imperceptible increase in operating efficiency.



JMH

Don't be sexist - Broads hate that.
Another free Access forum:

http://www.forumco.com/jmhare

More Access help stuff at

http://www.jmhare.com/wildhare.htm