On Oct 8, 2004, at 11:11 PM, David Garamond wrote:
The relationists' SQL replacement had better have more convenient JOIN
syntax then. :-)
Personally I find the JOIN ... USING syntax quite convenient. More
robust domain support is another side to this issue.
Cheers,
Michael Glaesemann
grzm myrea
Michael Glaesemann wrote:
In any case, one would never use NULL. Either the domain includes a
value for all possible values (including N/A) or you set up the db
schema appropriately.
Hm, that can be painful. What if I have ten optional attributes;
separate them to ten different tables?
Strictly?
On Oct 8, 2004, at 10:19 PM, David Garamond wrote:
Michael Glaesemann wrote:
In any case, one would never use NULL. Either the domain includes a
value for all possible values (including N/A) or you set up the db
schema appropriately.
Hm, that can be painful. What if I have ten optional attributes
Michael Glaesemann wrote:
For employees you don't have birthdates for, you could use NULL in SQL.
However, as relationally one shouldn't use NULL, you would do the
following:
CREATE TABLE employees (
emp_id SERIAL NOT NULL UNIQUE
, emp_name TEXT NOT NULL
);
CREATE TABLE employees_birthda
Am Freitag, 8. Oktober 2004 12:20 schrieb Terry Lee Tucker:
> Why would you never define a column as NOT NULL, or am I misunderstanding
> what you are saying?
His question was, should one use null values or should one use artificially
reserved real data values to indicate missing values, as MySQL
On Oct 8, 2004, at 8:12 PM, David Garamond wrote:
Speaking of NULLs, what does the relational model ideal suggest for
missing information?
a) no NULL at all;
b) NULL and N/A;
I've read both of those as well. Date has a pretty good section
regarding NULLs in his Introduction to Database Systems.
Understood. We use NOT NULL as you have stated below. I just wanted to make
sure we weren't doing something stupid. Thanks for the reply...
On Friday 08 October 2004 07:09 am, David Garamond saith:
> Btw, MySQL manual used to recommend (or still does?) defining all
> columns as NOT NULL as much a
Peter Eisentraut wrote:
Am Freitag, 8. Oktober 2004 07:22 schrieb Miles Keaton:
What's the prevailing wisdom & best-practice advice about when to let
a varchar (or any) column be NULL, and when to make it NOT NULL
DEFAULT '' (or '-00-00' or whatever) - in PostgreSQL?
Briefly, you always do the
Btw, MySQL manual used to recommend (or still does?) defining all
columns as NOT NULL as much as possible, "because NULL is slow"... :-)
For me it's pretty obvious, if you are never going to allow the column
to have an "unknown value", then define it NOT NULL to let the database
guarantee that.
Why would you never define a column as NOT NULL, or am I misunderstanding what
you are saying?
On Friday 08 October 2004 06:07 am, Peter Eisentraut saith:
>
> Briefly, you always do the first and never do the second.
>
> --
> Peter Eisentraut
> http://developer.postgresql.org/~petere/
>
> ---
Am Freitag, 8. Oktober 2004 07:22 schrieb Miles Keaton:
> What's the prevailing wisdom & best-practice advice about when to let
> a varchar (or any) column be NULL, and when to make it NOT NULL
> DEFAULT '' (or '-00-00' or whatever) - in PostgreSQL?
Briefly, you always do the first and never d
PG peeps:
What's the prevailing wisdom & best-practice advice about when to let
a varchar (or any) column be NULL, and when to make it NOT NULL
DEFAULT '' (or '-00-00' or whatever) - in PostgreSQL?
{Moving to PG from MySQL where we were always advised to use NOT NULL
to save a byte or so
12 matches
Mail list logo
