Thank you for your tips. I think I will change the tables and use some
minimal date instead of a null value to represent a constraint that is
valid all the time. An additional advantage of this approach is that I
can then make sure that the time intervals (I not only have a start
date, but also an
On Saturday 10 March 2007, Christian Schröder wrote:
Let's assume that the values in this table are some limits that are
given for different data (identified by the id). Some of the limits are
only valid after a given date, whereas other limits are valid all the
time. How would you put this
Berend Tober wrote:
Christian Schröder wrote:
Peter Eisentraut wrote:
A first step in that direction would be to rethink the apparently
troublesome use of null values.
Some of the limits are
only valid after a given date, whereas other limits are valid all the
time. How would
On Sun, Mar 11, 2007 at 11:09:56AM +0100, Christian Schröder wrote:
Of course, if a NULL always means unknown, then this approach doesn't
make sense. Where can I find an authorative definition of what NULL
means? As I have quoted before, according to the Wikipedia (far from
being authorative!)
Christian Schröder wrote:
Berend Tober wrote:
Christian Schröder wrote:
Peter Eisentraut wrote:
A first step in that direction would be to rethink the apparently
troublesome use of null values.
Some of the limits are
only valid after a given date, whereas
Martijn van Oosterhout kleptog@svana.org writes:
On Sun, Mar 11, 2007 at 11:09:56AM +0100, Christian Schr=F6der wrote:
Of course, if a NULL always means unknown, then this approach doesn't
make sense. Where can I find an authorative definition of what NULL
means?
Nowhere.
Well, in this
Hi list!
Consider the following table definition:
Column | Type | Modifiers
+--+---
id | integer | not null
date | date |
value | double precision |
The id and date field together are some sort of
Christian Schröder wrote:
How can I enforce these constraints?
I submit that you should rethink your database schema and properly
normalize it. You are attempting to retool the algebra that underlies
the SQL functionalities into doing something they are not designed to
do, and you will, even
Peter Eisentraut wrote:
I submit that you should rethink your database schema and properly
normalize it. You are attempting to retool the algebra that underlies
I don't quite understand why this is a question of normalization. As far
as I can see, my table seems to be normalized as far as
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 03/10/07 18:22, Christian Schröder wrote:
Peter Eisentraut wrote:
[snip]
I know that it's always dangerous to quote the Wikipedia. Let me do it
anyway: Attributes in tables in SQL database management systems can
optionally be designated as
Christian Schröder wrote:
Peter Eisentraut wrote:
A first step in that direction would be to rethink the apparently
troublesome use of null values.
Some of the limits are
only valid after a given date, whereas other limits are valid all the
time. How would you put this
11 matches
Mail list logo
