Skip to content

Coming from Delphi to C# I was not happy with the need for string.IsNullOrEmpty(myString) upon every check for an empty string. While I do understand that technical implementation may actually make this distinction, I really cannot se why we would be bothered having to distinguish. This topic has been discussed over and over, and it seems most developers support the idea that an empty string is actually not the same as a NULL value.

I beg to differ, for more reasons:

  • A string is the only data type that actually has a natural NULL value - an empty string. When you may specify a middle name, leaving it empty means "no value".
  • A major database vendor - Oracle - handles empty string as NULL without this being problematic to the world of RDBMS modellers, and Delphi Pascal (Version 2 ->) programming language implements an empty string as a null pointer behind the scene with very few developers ever noticing. I never heard anyone complaining about this.
  • For other data types, a user control easily shows NULL value: A checkbox being grayed out, a radio group with no selection, a blank numeric input field. How would you represent a null value in a text box ? Showing a grayed <null> or <empty> when actually NULL, and just blank if non-NULL ? Good luck with explaining users the difference....

The only case where you would actually need to differ would be when using string values in a database column with UNIQUE constraint; But actually treating an empty string as NULL solves this problem.

This behind-the-scene handler prevalent in both Oracle and Delphi does of course add a few operations every here and there (=more clock ticks), but I believe in most cases it would be desirable.

When talking of strange topics in IT world - did you know that in Firebird database, 0 <> -0 ?

Have a nice day !

Way back, before web applications, the idea of 3-tier applications emerged. The idea was quite simple, and predicted a shift of paradigms in applications structure. This was in the era of Client/Server (2-tier) applications, mind you, systems typically built as ...continue reading "3-Tier Architecture – What’s wrong with it ?"

The structure of a Relational Database (RDBMS) is, amongst more, that data is not duplicated. If a database contains person info, these reside in their own table and you don't need to change name in all occurrences in the database if a "member" is subject to a name change. Herein lies the beauty of the RDBMS: Change the name in one row, and all data extracts uses this name hereafter. ...continue reading "Time axis in relational databases"

The role of the 'architect' is hard to describe as there are many varieties out there - the common denominator being that it may include all stages in the creation process part from doing the actual implementation. In small projects or organisations, the architect will do everything from clearifying functionality with system owner to describing models for software implementation and technical ...continue reading "Why ‘Architect’ is a misleading term in system development"