Handling Null Attributes in a class 
Author Message
 Handling Null Attributes in a class

I am building some classes that contain attributes that can be Null (i.e. No
Value is set.)
Our Database (SQL S 7) happily handles the Null values, however I am stumped
on how my public interface to the class should be built.
I could use a variant type and whatever uses the class can do the checking,
or use specific types like date and string, and set a standard where if the
date is 0, there is no date, and if the string is empty, there is no string.
But what happens if I need to store an empty string ?

Any ideas, and methodology examples people could help me with ?

Cheers,
Greg.



Wed, 13 Mar 2002 03:00:00 GMT  
 Handling Null Attributes in a class
IMHO, I struggle hard not to have any columns that allow NULL values into my
database.  If I do allow a null value into the database it has to be for a
very good reason.  Through data normalizations you should be able to design
a database that does not allow NULL values and if there is a chance, then
you may want to place default values on the column.

There are a few reasons for this.  One is just being anal.  The other is
from what I think is a misunderstanding among the database community with
regards to three-valued (T, F, Null) logic.

With that said, if you still want to do it, the two ways that you have
outlined are the only ones I can think of.

--
Matthew Arnheiter
Flash Creative Management
http://www.flashcreative.com


Quote:
> I am building some classes that contain attributes that can be Null (i.e.
No
> Value is set.)
> Our Database (SQL S 7) happily handles the Null values, however I am
stumped
> on how my public interface to the class should be built.
> I could use a variant type and whatever uses the class can do the
checking,
> or use specific types like date and string, and set a standard where if
the
> date is 0, there is no date, and if the string is empty, there is no
string.
> But what happens if I need to store an empty string ?

> Any ideas, and methodology examples people could help me with ?

> Cheers,
> Greg.



Wed, 13 Mar 2002 03:00:00 GMT  
 Handling Null Attributes in a class


Quote:
> IMHO, I struggle hard not to have any columns that allow NULL values
into my
> database.  If I do allow a null value into the database it has to be
for a
> very good reason.  Through data normalizations you should be able to
design
> a database that does not allow NULL values and if there is a chance,
then
> you may want to place default values on the column.

> There are a few reasons for this.  One is just being anal.  The other
is
> from what I think is a misunderstanding among the database community
with
> regards to three-valued (T, F, Null) logic.

> With that said, if you still want to do it, the two ways that you have
> outlined are the only ones I can think of.

> --
> Matthew Arnheiter
> Flash Creative Management
> http://www.*-*-*.com/



> > I am building some classes that contain attributes that can be Null
(i.e.
> No
> > Value is set.)
> > Our Database (SQL S 7) happily handles the Null values, however I am
> stumped
> > on how my public interface to the class should be built.
> > I could use a variant type and whatever uses the class can do the
> checking,
> > or use specific types like date and string, and set a standard where
if
> the
> > date is 0, there is no date, and if the string is empty, there is no
> string.
> > But what happens if I need to store an empty string ?

> > Any ideas, and methodology examples people could help me with ?

> > Cheers,
> > Greg.

I think {*filter*}is an understatement. There's no reason why a database
should not contain null values. For eample, not everyone has a
middle initial. Defaults are good, if it's applicable to the column. As
far as empty strings go, it's probably better to use Nulls in your
database, that way you can enforce some kind of conversion scheme as you
mentioned.

Your class will probably be most useful and will perform best if you do
the conversions within. Otherwise you would have to write the same code
many times over, in multiple clients, and possibly over multiple
versions of the class. And if your data types are all variant, it would
introduce a lot of unnecessary error handling in the clients.

How you convert things all depends on how the class is going to be used,
but wherever you're doing the data access, IMHO, is the best place to
put the conversion code.

Chris

--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
'Do, or do not... There is no try.'--Yoda

Sent via Deja.com http://www.*-*-*.com/
Before you buy.



Fri, 15 Mar 2002 03:00:00 GMT  
 Handling Null Attributes in a class
i don't believe normalization has the slightest bearing on nulls. i don't
think a db is "well designed" because it has no nulls.

i think nulls are grossly misunderstood (myself included) by the developer
community. people fear them. people see something that blows up and discover
it was caused by a null value in the database. they then reason that
replacing that null with an empty string fixes it, and thus begins a
lifelong campaign against nulls.

an empty string is different than a null. an empty string means it was
specifically set to be "nothing", while a null means it has yet to be
specified. there is a difference, but the application has to be programmed
to know and care about the difference.


Quote:
> IMHO, I struggle hard not to have any columns that allow NULL values into
my
> database.  If I do allow a null value into the database it has to be for a
> very good reason.  Through data normalizations you should be able to
design
> a database that does not allow NULL values and if there is a chance, then
> you may want to place default values on the column.

> There are a few reasons for this.  One is just being anal.  The other is
> from what I think is a misunderstanding among the database community with
> regards to three-valued (T, F, Null) logic.

> With that said, if you still want to do it, the two ways that you have
> outlined are the only ones I can think of.

> --
> Matthew Arnheiter
> Flash Creative Management
> http://www.flashcreative.com



> > I am building some classes that contain attributes that can be Null
(i.e.
> No
> > Value is set.)
> > Our Database (SQL S 7) happily handles the Null values, however I am
> stumped
> > on how my public interface to the class should be built.
> > I could use a variant type and whatever uses the class can do the
> checking,
> > or use specific types like date and string, and set a standard where if
> the
> > date is 0, there is no date, and if the string is empty, there is no
> string.
> > But what happens if I need to store an empty string ?

> > Any ideas, and methodology examples people could help me with ?

> > Cheers,
> > Greg.



Sun, 17 Mar 2002 03:00:00 GMT  
 Handling Null Attributes in a class
I strongly disagree with your statement "i don't believe normalization has
the slightest bearing on nulls."  I have see too many database schemas
designed with relations where one attribute is not related to the primary
key of the relation.  Null markers are therefore allowed in these attributes
to not only signify unknown values as you state, but also not applicable.
In a properly normalized database these attributes would be removed from the
relation.

I should state at the front, that I am a follower of Date on this issue and
not of Codd who believes null markers are an integral part of the relational
model.  Even worse is that Codd has suggested that the relational model
should contain a fourth value called value not applicable, for which my
opinion has already been stated above.

I personally don't "fear" them, but I have not seen any formal system that
deals with the missing information problem in a convincing way.  I have seen
applications fail because of a null marker, but I see that more as a lack of
understanding on the part of the developer in how nulls are implemented in
the specific database system.

Here are a few of the consequences that arise when you introduce null
markers as a third logic value into the relational model:

1. x = x is not necessarily true as it is in two-valued logic
2. x or not x is not necessarliy true as it is in two-valued logic
3. R join R does not always yield R as it would in two-valued logic
4. a = b AND b = c does not necessarily yield a = c

My belief is that a formal system needs to be agreed upon that deals with
three-valued logic before it is implemented in the relational model.  The
beauty of the relational model is its formal foundation.

--
Matthew Arnheiter
Flash Creative Management
http://www.flashcreative.com


Quote:
> i don't believe normalization has the slightest bearing on nulls. i don't
> think a db is "well designed" because it has no nulls.

> i think nulls are grossly misunderstood (myself included) by the developer
> community. people fear them. people see something that blows up and
discover
> it was caused by a null value in the database. they then reason that
> replacing that null with an empty string fixes it, and thus begins a
> lifelong campaign against nulls.

> an empty string is different than a null. an empty string means it was
> specifically set to be "nothing", while a null means it has yet to be
> specified. there is a difference, but the application has to be programmed
> to know and care about the difference.



Sun, 17 Mar 2002 03:00:00 GMT  
 
 [ 5 post ] 

 Relevant Pages 

1. Null value to a user object attribute?

2. LowPart method error handling Integer8 attributes of AD

3. Attributes of Class Moduels

4. Changing UML Class Diagram/Properties/Attributes Interface

5. Writing a Custom Attribute - Getting the attached class.

6. xml attribute question for custom class

7. attribute preset and class question

8. Dynamically Changing Class attributes

9. Requiring attributes in a class

10. Class descriptions and Procedure attributes in VB.NET

11. classes and attributes

12. Static class attributes, how to create them.

 

 
Powered by phpBB® Forum Software