On 2015/12/03 8:49 PM, Scott Hess wrote: > On Thu, Dec 3, 2015 at 4:49 AM, R Smith <rsmith at rsweb.co.za> wrote: > >> On 2015/12/03 3:04 AM, Scott Hess wrote: >> >> I posit that a column declared as: col VARCHAR(32) NOT NULL says a >> whole lot more about what is actually happening than: col TEXT NOT NULL > I'm saying that: > col TEXT NOT NULL > fairly describes what is actually happening, but: > col VARCHAR(32) NOT NULL > implies that things are happening which are not happening. CHAR is kind of > happening, in that it is character data, VAR is not happening in that it > can store more data than a 1-byte prefix can describe, and 32 is definitely > not happening.
Ok, I see now more clear what you meant, but I don't agree. I write SQL to follow in form and function what *I MYSELF* intend for it to do - I do not adjust it to better describe what the specific SQL flavour engine actually ends up doing with the code. If I write: col VARCHAR(32) PRIMARY KEY It is only because it is my specific intent for that column to contain no more than 32 characters and have no multiple null values. Some engines may understand what I mean, some may not, but my code must always reflect what I intended. That is to me the very best future-proofing and future-understanding concept. Tomorrow, SQLite might improve on its interpretation... or add a PRAGMA strict_sql=ON mode as most of us wish for, and then how sad will you be that your entire code base contains "TEXT" everywhere where you could really have specified actual lengths the way you first intended? Not to mention... as a bonus my schema will compute correctly when moved to PostGres/MSSQL/MySQL/etc. To recode my SQL so it only says what the specific /SQL engine du jour/ can interpret because I /might/ make a spelling error and then cause myself later headaches... I don't know, that seems like a double cop-out. Besides, my OCD will never allow things like VRCHAR(6) when I intended VARCHAR(60). (And no, I'm not special, I assume that is true for 90% of the people here). Shape the code to what you INTEND. Don't make mistakes. Double check your code. I see your point, but I'm definitely sticking to my way this time. :) Cheers, Ryan
