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)
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
> 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
12 matches
Mail list logo
