Skip site navigation (1) Skip section navigation (2)

Re: Null comparisons (was Re: checksum)

From: Greg Stark <gsstark(at)mit(dot)edu>
To: Marco Colombo <pgsql(at)esiway(dot)net>
Cc: Greg Stark <gsstark(at)mit(dot)edu>, pgsql-general(at)postgresql(dot)org
Subject: Re: Null comparisons (was Re: checksum)
Date: 2004-09-29 19:18:50
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-general
Marco Colombo <pgsql(at)esiway(dot)net> writes:

> I'm not against abusing of the db, nor playing dirty tricks, if that fits
> your needs. You're free to design your db the way you like and face
> the cost of a careful design or of later SQL gymnastics. I'm fine,
> as long as you don't ask for syntactic sugar to support those "features".

My point is that you're making judgements about his schema without actually
knowing what you're talking about. For all we know his schema is entirely
reasonable and it's the query that has unusual requirements. Spouting general
design principles that may or may not apply as being iron-clad rules and
saying it's just wrong to break them is wilful blindness. 

Database modelling is not something you can do by holding up some textbook and
screaming "third normal form" until the developers trying to get work done
cower in submission. There are lots of times when breaking or bending the
rules is entirely reasonable and blindly following them is simply a waste of

For example, I have a table that uses NULLs to represent absent data. In 90%
of the queries three value logic is just exactly what's needed. In any case
they each have foreign key dependencies and having special values to represent
the absent values would be a major pain. It would require satisfying the
foreign keys with bogus records.

However I have queries that have to match provided data with other records,
including having missing data in the same position. For such a query I need to
break the usual model of three value logic and write something similar to what
this user needs. In my case no index would really be reasonable since there
are half a dozen such fields, but in general there's no reason an index
shouldn't be available for such cases.


In response to

pgsql-general by date

Next:From: Thomas F.O'ConnellDate: 2004-09-29 19:35:31
Subject: Re: Postgres inherited table, some questions...
Previous:From: Gregory S. WilliamsonDate: 2004-09-29 17:59:56
Subject: Re: Setting search paths inside a function (plpgsql)

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group