<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: When (n) counts?</title>
	<atom:link href="http://ronaldbradford.com/blog/when-n-counts-2008-07-19/feed/" rel="self" type="application/rss+xml" />
	<link>http://ronaldbradford.com/blog/when-n-counts-2008-07-19/</link>
	<description>Expert times and information on MySQL</description>
	<lastBuildDate>Tue, 07 Sep 2010 18:07:30 -0400</lastBuildDate>
	<generator>http://wordpress.org/?v=2.8.4</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: Rob Wultsch</title>
		<link>http://ronaldbradford.com/blog/when-n-counts-2008-07-19/comment-page-1/#comment-394</link>
		<dc:creator>Rob Wultsch</dc:creator>
		<pubDate>Sat, 19 Jul 2008 03:20:06 +0000</pubDate>
		<guid isPermaLink="false">http://ronaldbradford.com/blog/?p=1131#comment-394</guid>
		<description>I think that the how n affects zerofill is probably worth note, even though it is display only:

mysql&gt; create table t1(c int(8) zerofill);
Query OK, 0 rows affected (0.20 sec)

mysql&gt; insert into t1 values(3);
Query OK, 1 row affected (0.19 sec)

mysql&gt; select * from t1;
+----------+
&#124; c        &#124;
+----------+
&#124; 00000003 &#124;
+----------+
1 row in set (0.00 sec)

mysql&gt; alter table t1 modify c int(3) zerofill;
Query OK, 1 row affected (0.48 sec)
Records: 1  Duplicates: 0  Warnings: 0

mysql&gt; select * from t1;
+------+
&#124; c    &#124;
+------+
&#124;  003 &#124;
+------+
1 row in set (0.00 sec)</description>
		<content:encoded><![CDATA[<p>I think that the how n affects zerofill is probably worth note, even though it is display only:</p>
<p>mysql&gt; create table t1(c int(8) zerofill);<br />
Query OK, 0 rows affected (0.20 sec)</p>
<p>mysql&gt; insert into t1 values(3);<br />
Query OK, 1 row affected (0.19 sec)</p>
<p>mysql&gt; select * from t1;<br />
+&#8212;&#8212;&#8212;-+<br />
| c        |<br />
+&#8212;&#8212;&#8212;-+<br />
| 00000003 |<br />
+&#8212;&#8212;&#8212;-+<br />
1 row in set (0.00 sec)</p>
<p>mysql&gt; alter table t1 modify c int(3) zerofill;<br />
Query OK, 1 row affected (0.48 sec)<br />
Records: 1  Duplicates: 0  Warnings: 0</p>
<p>mysql&gt; select * from t1;<br />
+&#8212;&#8212;+<br />
| c    |<br />
+&#8212;&#8212;+<br />
|  003 |<br />
+&#8212;&#8212;+<br />
1 row in set (0.00 sec)</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Roland Bouman</title>
		<link>http://ronaldbradford.com/blog/when-n-counts-2008-07-19/comment-page-1/#comment-393</link>
		<dc:creator>Roland Bouman</dc:creator>
		<pubDate>Fri, 18 Jul 2008 21:19:39 +0000</pubDate>
		<guid isPermaLink="false">http://ronaldbradford.com/blog/?p=1131#comment-393</guid>
		<description>Hi Ronald!

For the integer types it has always been my opinion that it is completely retarded for a RDBMS to bother with something so application-oriented as the &quot;display width&quot;. It&#039;s probably some arcane remnant that nobody dears to change. But really, it would be so much better of things like SHOW CREATE TABLE would not bother with this sillyness, and simply not output the non-sensical &#039;display width&#039; for integer types.

Anyway, I&#039;m commenting because of this remark:

&quot;When it comes to floating point precision of FLOAT and DOUBLE, the syntax of (m,n) has a different inteperation. The manual states A precision from 0 to 23 results in a four-byte single-precision FLOAT column. A precision from 24 to 53 results in an eight-byte double-precision DOUBLE column.&quot;

AFAIK, the remark from the manual about 0-23 and 24-53 pertains to the -standard- FLOAT syntax:

FLOAT(B)

Where B is the *binary precision*. That is, B is the number of *bits* that will be used to store the value. In MySQL, this specification is not taken literally: it will either decide to use 4 or 8 bytes, that is, FLOAT(B) will, dependent upon how large B is result in a plain FLOAT or a plain DOUBLE.

(note that there is no such syntax for DOUBLE - In MySQL DOUBLE(B) is a syntax error)

The confusing thing is of course that

FLOAT(P,S)
and
DOUBLE(P,S)

specify precision and scale as *decimal digits* - something else entirely. The confusion is complete when you consider DECIMAL:

DECIMAL(P, S), FLOAT(P, S) and DOUBLE(P, S) means:  P digits, of which S are fractional digits
DECIMAL(P) means P digits,
but
FLOAT(B) means the least of 4 or 8 bytes that can still hold a floating point number of B bits

(and DOUBLE(B) is not valid)

Roland Bouman</description>
		<content:encoded><![CDATA[<p>Hi Ronald!</p>
<p>For the integer types it has always been my opinion that it is completely retarded for a RDBMS to bother with something so application-oriented as the &#8220;display width&#8221;. It&#8217;s probably some arcane remnant that nobody dears to change. But really, it would be so much better of things like SHOW CREATE TABLE would not bother with this sillyness, and simply not output the non-sensical &#8216;display width&#8217; for integer types.</p>
<p>Anyway, I&#8217;m commenting because of this remark:</p>
<p>&#8220;When it comes to floating point precision of FLOAT and DOUBLE, the syntax of (m,n) has a different inteperation. The manual states A precision from 0 to 23 results in a four-byte single-precision FLOAT column. A precision from 24 to 53 results in an eight-byte double-precision DOUBLE column.&#8221;</p>
<p>AFAIK, the remark from the manual about 0-23 and 24-53 pertains to the -standard- FLOAT syntax:</p>
<p>FLOAT(B)</p>
<p>Where B is the *binary precision*. That is, B is the number of *bits* that will be used to store the value. In MySQL, this specification is not taken literally: it will either decide to use 4 or 8 bytes, that is, FLOAT(B) will, dependent upon how large B is result in a plain FLOAT or a plain DOUBLE.</p>
<p>(note that there is no such syntax for DOUBLE &#8211; In MySQL DOUBLE(B) is a syntax error)</p>
<p>The confusing thing is of course that</p>
<p>FLOAT(P,S)<br />
and<br />
DOUBLE(P,S)</p>
<p>specify precision and scale as *decimal digits* &#8211; something else entirely. The confusion is complete when you consider DECIMAL:</p>
<p>DECIMAL(P, S), FLOAT(P, S) and DOUBLE(P, S) means:  P digits, of which S are fractional digits<br />
DECIMAL(P) means P digits,<br />
but<br />
FLOAT(B) means the least of 4 or 8 bytes that can still hold a floating point number of B bits</p>
<p>(and DOUBLE(B) is not valid)</p>
<p>Roland Bouman</p>
]]></content:encoded>
	</item>
</channel>
</rss>
