I have a big doubt concerning strings in perstistable objects and database tables.

Wheather is quite obvious that, for example, using an Integer instead of an int is reasonable because null, 0 and non-zero are three different states that could have a valid business meaning, I think that for String things are quite different.

The problem, to me, is: do I really need to distinguish between null, ""(empty String) and non-empty string?

I think that, for Strings, most of times, we have only two "significant" states: null/empty and non empty.
Usually, whe can get null, 0 or non-zero from an user interface in a numeric field, but for a string it's quite usual to have only empty or non-empty.

To complicate the scenario, we must remember that null strings and empty strings are managed differently in databases;
a trivial example, think you have this table:

id int (primary key)
val char(10)

with these records:

(0, NULL)
(1, "a")
(2, "a")
(3, "b")

if you have:

SELECT ... WHERE val!="a" only the record (3, "b") is returned;

but maybe, you would like to obtain (3, "b") and (0, NULL), from a business-logic point of view; and this would require:

SELECT ... WHERE val!="a" or val is null

and on "or" could have a negative impact on a query performance.


But also in Java code, writing:

if (a.equals(b)) ...

is shorter than:

if ((a!=null) && (a.equals(b)) ...


Another consideration: in this case a UserType could provide a good abstraction and allow to "change mind" later, but defining a UserType to wrap a String for this reason, to the minimum will complicate the code and will have a big impact on performance.

I know that ther's not a fixed approach to this; it depends on business logics, habits, and so on, but any suggestion, experience or any other consideration would be VERY appreciated.


Thanks

Null is an "unknown information" marker. It has nothing to do with zero, or for that matter, a String of length zero.