On Sun, 15 Mar 2009 20:19:51 +0100 Claudio Nanni said:
> >
> >
> > This is from an application design perspective, not while you a creating a
> > table or constructing an insert statement.
>
>
> If you control your code, after retrieving the values from the database ,
> you should have somethi
>
>
> This is from an application design perspective, not while you a creating a
> table or constructing an insert statement.
I do not think it is possible to design an application not caring about the
data model it relies on.
And I am sorry if "people like me who write the code need to add 'IS
2009/3/14 :
[...]
> So instead of thinking that I am an idiot, try using your intelligence and
> try to understand what I am really talking about!
... instead, try to point us to a chapter of a book or take your time
and write a short paper, 'cause my (stupid) intelligence suggests
me that (maybe)
Arthur Fuller wrote:
Exactly the point. Michael, NULL *is* information. It means "unknown" and
that is in itself useful information. A common example:
A new employee is hired but which department she will work in is unknown. So
the data entry person enters all the known information and leaves t
It's a good thing, then, that we've got your experience to rely on.
Woe is us, for not having any, and not seeing how obviously right you
are.
You're entitled to your opionion on NULLs, but kindly stop spamming
*my* mailbox with it. I was aware of your dislike for them after the
first mail.
On S
Claudio Nanni wrote:
> Hi everybody I want to join as well.
>
>
> The question is: "Will I allow a record to contain a 'non-informative'
> field
> ?"
No! thats not the question!
> [a] Ok, go ahead.
> [b] No, set the field as NOT NULL
>
> If you choose [b] please assume your responsibilities.
> E
2009/3/13 :
>> I have a database logging weather data. When a station does not report a
>> temperature, it is set to NULL. It would be a very bad idea to set it to 0
>> as this would ruin the whole statistics.
>> NULL is a perfectly valid information in many cases.
> I'd use -9., I'd neve
I certainly appreciate this discussion and the clear opinions of Mike.
Somehow it turned my somewhat simple question into something much more
interesting.
I believe in referential integrity, I also believe that enforcing a
"fully saturated" data model like Mike proposes, is a constraint o
Hi everybody I want to join as well.
>
> But hypothetically speaking, what value would you use if you didn't have a
> "I don't what this is" value like null?
>
> I ask this because I started programming when NULL was really zero, and
> part of the ASCII collating sequence.
NULL was zero
>
>
>
>
> I agree with most everything you said, as far as the use of a RDBMS, and
> especially: quoting you,
>
> "theoretically you break up your data into tables so that there is never a
> non-applicable field for any given row."
>
> Here is where I disagree with you, and please DON'T take this as an
Think!
I'm not talking about how you application is designed. If your
applications allows an employee to be entered without a position in the
company, it is a bad design.
If a manager at my company hired someone, and did not know what work the
new-hire would be doing, well I'd really need to ask
On Fri, Mar 13, 2009 at 3:20 PM, Andy Wallace wrote:
> ggghh
>
>
> mich...@j3ksolutions.com wrote:
>
>> On Fri, 13 Mar 2009, mich...@j3ksolutions.com wrote:
>>>
>>> Explanation(5): The more you understand how the database is to be used,
and the
Exactly the point. Michael, NULL *is* information. It means "unknown" and
that is in itself useful information. A common example:
A new employee is hired but which department she will work in is unknown. So
the data entry person enters all the known information and leaves the rest
until it has be
mich...@j3ksolutions.com wrote:
>> On Fri, 13 Mar 2009, mich...@j3ksolutions.com wrote:
>>
>>
>>> Explanation(5): The more you understand how the database is to be used,
>>> and the more complexity and thought you put into your database design,
>>> the
>>> less complex it will be to retrieve r
ggghh
mich...@j3ksolutions.com wrote:
On Fri, 13 Mar 2009, mich...@j3ksolutions.com wrote:
Explanation(5): The more you understand how the database is to be used,
and the more complexity and thought you put into your database design,
the
less co
> On Fri, 13 Mar 2009, mich...@j3ksolutions.com wrote:
>
>> Explanation(5): The more you understand how the database is to be used,
>> and the more complexity and thought you put into your database design,
>> the
>> less complex it will be to retrieve reliable information out of it.
>> Furthermore,
On Fri, 13 Mar 2009, mich...@j3ksolutions.com wrote:
Explanation(5): The more you understand how the database is to be used,
and the more complexity and thought you put into your database design, the
less complex it will be to retrieve reliable information out of it.
Furthermore, (and this is pr
> On Friday 13 March 2009 09:48:36 Michael wrote:
>> I'm sorry for the rant, but nulls in databases make me see red! NULLS
>> ARE GARBAGE!
>>
>> You are using a 'NULL-safe equal to operator', meaning, WHERE NOT
>> group_id = 3, and oh, by the way, I DON'T WANT ANY NULLS TO QUALIFY AS
>> 3.
>>
>>
On Friday 13 March 2009 09:48:36 Michael wrote:
> I'm sorry for the rant, but nulls in databases make me see red! NULLS
> ARE GARBAGE!
>
> You are using a 'NULL-safe equal to operator', meaning, WHERE NOT
> group_id = 3, and oh, by the way, I DON'T WANT ANY NULLS TO QUALIFY AS 3.
>
> And yes this
19 matches
Mail list logo
