Re: PostgreSQL Certification
От | Jon Ericson |
---|---|
Тема | Re: PostgreSQL Certification |
Дата | |
Msg-id | rcgllr22p7b.fsf@jpl.nasa.gov обсуждение исходный текст |
Ответ на | Re: PostgreSQL Certification (Bruce Momjian <pgman@candle.pha.pa.us>) |
Список | pgsql-advocacy |
Christopher Browne <cbbrowne@acm.org> writes: > At one extreme, Chris Date holds to the position that NULLs ought to > be forbidden outright. He does make a fairly credible case for it, > albeit with the problem that when you forbid NULLs, you have to > replace them by making the data model a little more complex. (He > recently released a paper on how to do this; there's not much > surprise to it; whenever a column "could be NULL," you have to split > it off to a separate table so that its omission amounts to not > bothering to populate the new table...) > > The other "major" position is that there should be multiple sorts of > 'NULL' values to indicate different forms of missing information. > (One problem with NULL is that you can't easily distinguish between > "I left that NULL because I didn't know the value" and "That's NULL > because that's how we say it's 'empty.'") > > I fall more into the pragmatic position that "NULL columns have the > potential to cause a lot of confusion; use NOT NULL when you can, > and be wary when you can't." Interesting. The bullet caught my eye because I am currently working with a table that has, in my opinion, poorly thought out NOT NULL constraints. When I do the initial insert I have to use 0 to mean both "I don't know the value yet" and "this is how we say empty"! It occurs to me that adding a cross-reference table would not only let me avoid NULL, but also solve a couple of other problems as well. Thanks, Jon -- But if serving the LORD seems undesirable to you, then choose for yourselves this day whom you will serve . . . But as for me and my household, we will serve the LORD. -- Joshua 24:15 (NIV)
В списке pgsql-advocacy по дате отправления: