 | |
#331
 
| |||
| |||
|
Re: NULLs -
01-08-2008
, 02:20 PM
|
But of course, all these real world applications and all these text books still have to find some way to deal with missing information, so they often introduce magic values (like -1 in a numeric domain that should only allow positive numbers, 1900-01-01 or 9999-12-31 in a date domain, 'N/A' in a string domain, etc). This then turns out to be a far worse kludge than just using NULL for what it is intended to be used for! |
often abused. There are many applications like open date ranges which
invite the database designer to utilize an existing data type -- in this
case a date -- which doesn't quite fit the job. After that you'd often
want to extend the datatype to include special values like "valid until
further notice". In typical DBMSes adding to the basic datatypes like
that is not easy, so the one special value that can be added easily,
null, gets overloaded. That is obviously bad, because unlike values
proper, null invokes 3VL semantics which now have to be circumvented
over and over in code, in order to mimic simple 2VL ones.
I think one means of relegating nulls to their proper place is to make
it easier to avoid them where missing information is actually not the
problem. That's then one reason why I think databases ought to have
stronger support for custom, abstract datatypes/domains, in an easy to
use form.
--
Sampo Syreeni, aka decoy - mailto:decoy (AT) iki (DOT) fi, tel:+358-50-5756111
student/math+cs/helsinki university, http://www.iki.fi/~decoy/front
openpgp: 050985C2/025E D175 ABE5 027C 9494 EEB0 E090 8BA9 0509 85C2
#332
| |||
| |||
|
|
But of course, all these real world applications and all these text books still have to find some way to deal with missing information, so they often introduce magic values (like -1 in a numeric domain that should only allow positive numbers, 1900-01-01 or 9999-12-31 in a date domain, 'N/A' in a string domain, etc). This then turns out to be a far worse kludge than just using NULL for what it is intended to be used for! |
often abused. There are many applications like open date ranges which
invite the database designer to utilize an existing data type -- in this
case a date -- which doesn't quite fit the job. After that you'd often
want to extend the datatype to include special values like "valid until
further notice". In typical DBMSes adding to the basic datatypes like
that is not easy, so the one special value that can be added easily,
null, gets overloaded. That is obviously bad, because unlike values
proper, null invokes 3VL semantics which now have to be circumvented
over and over in code, in order to mimic simple 2VL ones.
I think one means of relegating nulls to their proper place is to make
it easier to avoid them where missing information is actually not the
problem. That's then one reason why I think databases ought to have
stronger support for custom, abstract datatypes/domains, in an easy to
use form.
--
Sampo Syreeni, aka decoy - mailto:decoy (AT) iki (DOT) fi, tel:+358-50-5756111
student/math+cs/helsinki university, http://www.iki.fi/~decoy/front
openpgp: 050985C2/025E D175 ABE5 027C 9494 EEB0 E090 8BA9 0509 85C2
#333
| |||
| |||
|
|
But of course, all these real world applications and all these text books still have to find some way to deal with missing information, so they often introduce magic values (like -1 in a numeric domain that should only allow positive numbers, 1900-01-01 or 9999-12-31 in a date domain, 'N/A' in a string domain, etc). This then turns out to be a far worse kludge than just using NULL for what it is intended to be used for! |
often abused. There are many applications like open date ranges which
invite the database designer to utilize an existing data type -- in this
case a date -- which doesn't quite fit the job. After that you'd often
want to extend the datatype to include special values like "valid until
further notice". In typical DBMSes adding to the basic datatypes like
that is not easy, so the one special value that can be added easily,
null, gets overloaded. That is obviously bad, because unlike values
proper, null invokes 3VL semantics which now have to be circumvented
over and over in code, in order to mimic simple 2VL ones.
I think one means of relegating nulls to their proper place is to make
it easier to avoid them where missing information is actually not the
problem. That's then one reason why I think databases ought to have
stronger support for custom, abstract datatypes/domains, in an easy to
use form.
--
Sampo Syreeni, aka decoy - mailto:decoy (AT) iki (DOT) fi, tel:+358-50-5756111
student/math+cs/helsinki university, http://www.iki.fi/~decoy/front
openpgp: 050985C2/025E D175 ABE5 027C 9494 EEB0 E090 8BA9 0509 85C2
 |
« Previous Thread
|
Next Thread »
| Thread Tools | |
| Display Modes | |
Linear Mode
| |
Powered by vBulletin Version 3.5.3
Copyright ©2000 - 2012, Jelsoft Enterprises Ltd.
Copyright ©2000 - 2012, Jelsoft Enterprises Ltd.