Tim Tassonis wrote: > Chris wrote: >> Erick Papadakis wrote: >>> So how should I make a database rule in MySQL to not allow blank >>> strings. Basically to REQUIRE a value for that column, whether it is >>> NULL or NADA or VOID or whatever you wish to call it. I just want to >>> make sure that something, some value, is entered for a column. Would >>> appreciate any thoughts or pointers. >>> >>> Does PostgreSQL suffer from this oddity as well? This distinction >>> between an empty string and a NULL? Could you also please give me an >>> example of where this would be useful from a business logic >>> standpoint? Why should a NULL be different from an empty string, >>> what's the big mysterious difference? >> >> It's not an oddity. >> >> An empty string is a KNOWN value. You know exactly what that value is >> - it's an empty string. >> >> A NULL is UNKNOWN - it doesn't have a value at all. > > I do still think it is a bit of an oddity, the concept of the null > column. From my experience, it creates more problems than it actually > solves and generally forces you to code more rather than less in order > to achieve your goals. Well, your mileage must vary. The absence of nulls would make my life difficult. Just substitute "unknown" for "null" as mentioned above and the various operations with "null" make sense. For example, take some days and low-temperatures: Mon: 30 Tue: 10 Wed: 0 Thu: unknown Fri: 0 Sat: unknown Sun: -5 Was the low temperature the same on: Mon/Tue: no Wed/Fri: yes Thu/Fri: unknown Thu/Sat: unknown <- the always seemingly confusing null=null is null. So what do we do without a null? Does the "helpful" app convert the unknowns to zero? That's not right. Are we forced to specify a "special" value like 999 for the unknown data? Then we have to add extra code to create that value when the value is unknown and more code still to check for that value when, say, looking for the lowest or average temperatures. And we're set up for disaster when someone starts measuring furnace temps instead of outdoor temps. Look no further than Y2K to see what happened to those apps that gave special meaning to 12/31/99. Cheers, Steve
