On Thu, Sep 18, 2003 at 12:44:10PM +0100, Haydies wrote:
> I have only one thing to say really on this. Data never has any meaning at
> all. It is simply data, and not information. Information is extracted from
> data and is then given meaning by the viewer of the data.
True. We were arguing about
MAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, September 17, 2003 8:57 PM
Subject: Re: Does Null == ""?
: Bruce Feist has initiated a discussion with me off the list, and
: has forced me to refine the way I express my position somewhat.
: The combination of on-li
On Wed, Sep 17, 2003 at 09:58:16PM -0400, Bruce Feist wrote:
> Bob Hall wrote:
>
> >Bruce Feist has initiated a discussion with me off the list,
>
> Off the list by accident, by the way. I sometimes forget that in this
> list I need to do a REPLY ALL. I generally don't go private unless I
> w
Bob Hall wrote:
Bruce Feist has initiated a discussion with me off the list,
Off the list by accident, by the way. I sometimes forget that in this
list I need to do a REPLY ALL. I generally don't go private unless I
want to avoid embarassing someone or need to discuss something genuinely
of n
Bruce Feist has initiated a discussion with me off the list, and
has forced me to refine the way I express my position somewhat.
The combination of on-list and off-list discussion has been interesting,
but it's getting overwhelming, and reminds me that I have a tendency to
overindulge in contro
On Tue, Sep 16, 2003 at 05:39:35PM -0400, Bruce Feist wrote:
> 1) It is the responsibility of the DBD to document the meaning of NULL if
> NULLs are allowed.
No, it's not. The meaning of NULL is documented in the SQL specification.
It's the responsibility of people working with databases to kno
> I didn't know that. What *does* it do if you specify a
> string literal that's smaller than the CHAR(20) field, then?
> Pad it with binary zeros?
MySQL returns a properly trimmed string, although it will allocate a
fixed amount of space for the storage. Other databases pad with blank
spaces
Jon Frisby wrote:
Even if I grant you that, the DB designer should have produced the
documentation. I'm willing to place the blame on both people; either
one could have avoided the problem. But, the DBD (data
administrator,
if you prefer) is more likely to have been *aware* of the
problem i
> -Original Message-
> From: Randy Chrismon [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, September 16, 2003 6:59 AM
> To: [EMAIL PROTECTED]
> Subject: Re Does NULL == ""?
>
>
> All this discussion about the definition of NULL and its use in
> database q
> Even if I grant you that, the DB designer should have produced the
> documentation. I'm willing to place the blame on both people; either
> one could have avoided the problem. But, the DBD (data
> administrator,
> if you prefer) is more likely to have been *aware* of the
> problem in the
On Tue, Sep 16, 2003 at 09:58:32AM -0400, Randy Chrismon wrote:
> All this discussion about the definition of NULL and its use in
> database querying has been most interesting and enlightening. I
> hadn't realized I was asking such a deep question. Unfortunately, I'm
> still at the stage of design
All this discussion about the definition of NULL and its use in
database querying has been most interesting and enlightening. I
hadn't realized I was asking such a deep question. Unfortunately, I'm
still at the stage of designing tables where I KNOW I will be loading
thousands of records that, mor
On Mon, Sep 15, 2003 at 07:29:38PM -0700, Jon Frisby wrote:
> That's an ugly way to make the distinction between A-mark and I-mark.
> In most situations, I'd move the relevant column(s) to a separate table,
> with a NULL-allowed column in that table and a FK reference back to the
> original table.
On Mon, Sep 15, 2003 at 10:33:27PM -0400, Bruce Feist wrote:
> if you stick to the natural meaning, that doesn't happen; integer and
> other values have precise and obvious natural meanings. NULL does not.
Integers and NULL are exactly alike it this regard. Neither has
a natural meaning; their
On Mon, Sep 15, 2003 at 09:24:50PM -0500, Dan Nelson wrote:
> In the last episode (Sep 15), Bruce Feist said:
> Your example has nothing to do with the vagueness of NULL though.
> Replace NULL with "0" and you get the same result.
Bad move. "0" has a universally known meaning, and it isn't
"not
On Mon, Sep 15, 2003 at 09:53:11PM -0400, Bruce Feist wrote:
> Bob Hall wrote:
>
> >The meaning of NULL is defined in the SQL specification; it means
> >"not known" or "not applicable".
> >
> Which is just about as useful as not defining it, actually. The
That's not true. Having a univerally
Jon Frisby wrote:
The application is payroll/personnel. A programmer is tasked with
creating forms for data entry on new employees, including
supervisor.
If the user doesn't enter a new employee's supervisor, the
application
accepts it, figuring that it is not yet known, and stores
NULL fo
Dan Nelson wrote:
In the last episode (Sep 15), Bruce Feist said:
The application is payroll/personnel. A programmer is tasked with
creating forms for data entry on new employees, including supervisor.
If the user doesn't enter a new employee's supervisor, the
application accepts it, figuring
> The application is payroll/personnel. A programmer is tasked with
> creating forms for data entry on new employees, including
> supervisor.
> If the user doesn't enter a new employee's supervisor, the
> application
> accepts it, figuring that it is not yet known, and stores
> NULL for the
In the last episode (Sep 15), Bruce Feist said:
> Bob Hall wrote:
> >The meaning of NULL is defined in the SQL specification; it means
> >"not known" or "not applicable".
>
> Which is just about as useful as not defining it, actually. The
> vagueness is the cause of a great many program bugs when
Bob Hall wrote:
The meaning of NULL is defined in the SQL specification; it means
"not known" or "not applicable".
Which is just about as useful as not defining it, actually. The
vagueness is the cause of a great many program bugs when database
designers don't specify what NULL means for a g
On Mon, Sep 15, 2003 at 12:46:50PM -0400, Randy Chrismon wrote:
> an exort from a Lotus Notes database. At some point, the MySQL
> documentation says that a table with no nullable columns is
> better/faster than one with. The Lotus Notes database I'm migrating,
> however, has many fields with no va
: Randy Chrismon [mailto:[EMAIL PROTECTED]
Sent: Monday, September 15, 2003 12:47
To: [EMAIL PROTECTED]
Subject: Re: Does Null == ""?
> Null is a special value and cannot be tested in the same manner as a
> > string
> or other value. Yes, there is a difference. If
> Null is a special value and cannot be tested in the same manner as a
> > string
> or other value. Yes, there is a difference. If the column is Null, a
> comparison operation such as a.field == "" or a.field ==
"something" > will
> both return Null.
> Maybe this document will help:
> A.5.3 Pr
On 15 Sep 2003 at 11:47, Brent Baisley wrote:
> It's almost useless to specify a property as NOT NULL and also set a
> default value. The only way it would ever be NULL is if you
> specifically set it to NULL.
I think you meant "NULL" rather than "NOT NULL" there.
--
Keith C. Ivey <[EMAIL PROTE
At 11:00 AM -0400 9/15/03, Randy Chrismon wrote:
The MySQL documentation confuses me a bit. If I create a table with
property NOT NULL and default "", does that mean that a record with a
column so defined will have a zero-length string in that column if I
don't provide a value? I guess what I'm ask
This is sometime a tough concept to get through. For example, there is
more than two answers to a yes and no question. There is yes, no, "I
don't know" (the empty set) and the "No answer at all" (null).
It's almost useless to specify a property as NOT NULL and also set a
default value. The only
: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: Re: Does NULL == ""?
No, NULL is not the same as the empty string. NULL, for any class of field,
means that no data has ever been written there. Tests involving NULL other
than IS NULL and IS NOT NULL will return NULL. Thus "&q
e is inserted.
-Original Message-
From: Randy Chrismon [mailto:[EMAIL PROTECTED]
Sent: Monday, September 15, 2003 11:00
To: [EMAIL PROTECTED]
Subject: Does NULL == ""?
The MySQL documentation confuses me a bit. If I create a table with
property NOT NULL and default "
Randy Chrismon wrote:
what I'm asking is whether there's a
difference between a field with NULL in it and a field with a
zero-length ("") string in it.
Yes, there is. NULL is the absence of a value; an empty string is a
valid value. NULL by definition isn't equal to anything, even to
itself
|
| Subject: Does NULL == ""?
|
>
The MySQL documentation confuses me a bit. If I create a table with
property NOT NULL and default "", does that mean that a record with a
column so defined will have a zero-length string in that column if I
don't provide a value? I guess what I'm asking is whether there's a
difference between a fi
32 matches
Mail list logo
