|
Return To Issues Page |
Mainstream methods for creating computer programs have exhibited a continuous evolution to higher levels of abstraction, from machine languages to assembly languages to high level languages (3GL's) to higher level languages (Object Oriented, 4GL's, Logic, Functional). Methods for controlling and accessing persistent data have undergone a similar evolution culminating in a revolutionary abstraction - Relational Databases. Relational methodology deals with substantive issues like distributed processing & storage, separation of logical and physical concerns, maintenance of business rules and data evolution.
In order for someone to fully utilize a database, there must be some limits on its overall complexity to make it comprehensible while still being comprehensive. What good is a database if its nature can't be understood? Much of the complexity in a relational database is user driven. User definitions can be extensive - base tables & columns, views, table linkages (foreign keys), column domains and business rules/constraints. Relational DBMS's provide simple yet powerful facilities to counter this inherent complexity. This by necessity requires some compromises.
Nulls in relational databases are an example of a simple yet powerful facility. It is a compromise as are other relational features such as single valued & single domain columns, foreign keys, flat tables (first normal form) and referential integrity. There has been considerable debate lately about the advisability of nulls in relational database. This article presents arguments in favor of retaining null processing.
|
|
Return To Issues Page |