At 12:27 AM 8/15/2006 -0400, MB Software Solutions wrote:
Heh, I didn't say I designed it. I cannot take any credit for anything =
you are seeing with varchar involved. <g>
but varchar is a *good* thing, isn't it? Oh wait...are you saying it's
better optimized as fixed length chars? Do elaborate.
From a very general Computer Science perspective, data storage of
'variable' length fields and records requires more "work" from the DB
engine. E.g. indexing, searching, retrieval, etc has to be concerned with
End of Field and End of Record 'marks', etc. A fixed length field/record
means data locations in files are a very simple calculation with no parsing
of actual data. I presume this is why a lot of my VFP apps out-performed
the SQL (Informix, SQL Server, Oracle) counterparts in the past.
Of course, the DB Vendors are constantly trying to improve their
performance. So they've come up with smart 'caching' and other
optimizations to help speed up the DB functions on variable length
fields/records. And, because of the additional layers being heaped on DB
access (OLE DB, etc), and the general 'set' (and client/server) theory of
SQL, it's sometimes hard to tell where the performance bottlenecks really
are (that is, from an end-application standpoint).
-Charlie
_______________________________________________
Post Messages to: ProFox@leafe.com
Subscription Maintenance: http://leafe.com/mailman/listinfo/profox
OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech
** All postings, unless explicitly stated otherwise, are the opinions of the
author, and do not constitute legal or medical advice. This statement is added
to the messages for those lawyers who are too stupid to see the obvious.
