×
The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.
Editing sometimes has a way of causing problems with technical
writing, by nuances in /changed/ meaning from the original intent. As
with this case, sometimes the editing change is not so obvious. Subtle
enough that the original author actually notices the _error_ in review.
I asked the author, and paraphrased... The intent was to express that
somewhat /short/ VARCHAR [less than 40 bytes] in MySQL will best be
represented by the same length CHAR when defined in the DB2 for i5/OS;
i.e. in accordance with the expressed possible performance overhead when
using VARCHAR instead of CHAR, described in that section.
The decision is mostly a trade-off between storage and performance.
With the example of 75% at 15 of 35 character, consider that as VARCHAR
it is now 75% at 17 of 37; i.e. where 2*NbrRows of the storage is always
a minimum for the entire table. Consider for 1 in four rows [assuming
that percent is meant to imply all others are longer than 15] will cause
a second /read/ to the variable length segment to access the data which
is not stored with the row that is already read. See also:
http://publib.boulder.ibm.com/infocenter/iseries/v5r4/index.jsp?topic=/rzajq/vardatatypes.htm
Regards, Chuck
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact
[javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.
midrange.com
