Seven things I really hate in database design

1. Common prexif in all table names
1. es: TXXX, TYYY, TZZZ, VAAA, VBBB - T stays for Table, V stays for View
2. es: APPXXX, APPYYY, APPZZZ - APP is an application name
2.  Common prefix in all field names in every table
        es: APPXXX.XXX_FIELD_A, APPXXX.XXX_FIELD_B, APPXXX.XXX_FIELD_C
3. Fields with the same meaning and different names (in different tables)
        es: TABLE_A.BANK_ID, TABLE_B.BK_CODE
4. Fields with the same logical type and different physical types
         es: TABLE_A.MONEY_AMOUNT NUMBER(20,2)
         TABLE_B.MONEY_AMOUNT NUMBER(20,0) -- value * 100
         TABLE_B.MONEY_AMOUNT VARCHAR(20) --value * 100 as char
5. No foreign-keys nor integrity constraints at all - by design
6. Date (or generally structured data type) representation with generic and not specific types
1. es: TABLE_A.START_DATE NUMBER(8,0) -- yyyyddmm as int
2. es: TABLE_B.START_DATE VARCHAR(8) -- yyyyddmm as char
7.  (possible only in presenceof 6.) Special values for semantic corner-cases which are syntactically invalid
         es: EXPIRY_DATE = 99999999 -- represents "never expires case",
      but... IT'S NOT A VALID DATE!!! - why not 99991231??

Improper inheritance and light-hearted downcast

And here is maybe the worst design I've ever seen - directly from production-released code, of course...


Inheritance is a key feature in object-oriented programming languages, providing support for both specialization and flexible extensibility. But... using inheritance just to use it can drive to horrible design cases, where distinction between superclass/interfaces and different subclasses is improper and extensibility is actually impossible. This is the case of a real-life production code I was lucky enough to see:

public interface InterfaceX {
   public abstract void aMethodX();
}

public interface InterfaceY {
   public abstract String aMethodY(final String s);
}

Class FatImplementation implements both InterfaceX and InterfaceY:

public class FatImplementation implements InterfaceX, InterfaceY {
   public void aMethodX() {
      ...
   } 

   public String aMethodY(final String s) {
      ...
      return ...;
   }
}

And... Ladies and Gentlemen... the crazy client class, whose method is casting to InterfaceX an InterfaceY reference, relying on the fact that FatImplementation implements both interfaces:

public class CrazyClass {
 public void theCrazyCastingMethod(final InterfaceY y) {
  ...
  ((InterfaceX)y).aMethodX();
 }
}

This is an improper use of abstraction - inheritance programming model, since the cast succeeds only with a specific implementation (FatImplementation) of given interface and polymorphism is actually not possible.

... ... ... poorly and foolishly designed, isn't it? And... what if I said that InterfaceX and InterfaceY, in the original code, where StatefulXXX and StatelessXXX? So... FatImplementation was stateful and stateless at the same time! AAAAAAHHHH!

Configuration architectural antipatterns

I've got the flu, these days: and in fever's drowsiness has surfaced the memory of an application I've worked on six years ago.

It was an aged application, developed by a former employee using Visual Basic 6 - uh! oh!

I was doing only fixes and small enhancements on that application, but I'll remember it forever due to its bright and genial configuration-relating design.

That application's configuration, as was the case also for other applications by the same author, was "designed" around the Multiple Configuration Points conceptual antipattern: it wasn't stored in a single, well defined, simple accessible place, but in multiple, differently implemented respositories:

• part of the configuration was read from an "ini" file: the file was processed without using some kind of library, but reading the raw input and counting rows: at row #X, parameter Y - oh, yeah!
• the remainder part of configuration cames from a MS Access File (may god forgive him! - if a god exists) and was accessed using OLE DB support and SQL queries (this part of the configuration was modifiable through the application itself)

So, in one application, and only with regard to configuration management, you can list several architectural antipatterns:

1. Multiple Configuration Points: configuration spawned in multiple, heterogeneous repositories
2. Reinventing The Wheel: "ini" file read through home-made procedure
3. Brittle configuration: formatting-depandant "ini" file semantics
4. Tightly coupling to external libraries versions: MDB configuration file could be read without errors  only when the MS Access' version on the host machine was the version for which the application was compiled - otherwise, the application wasn't ever able to start. And if the MDB file was modified using a most recent version, it became unreadable for the application...

And - final masterpiece: that application, which used relational DB for (partial) configuration management, did not use any type of database for business data storage and inter-application communication purposes: data storage was performed writing sequental text files with fixed-length records, and applications interested in data interchange read the same files (code reading and writing records was naturally duplicated between applications, not extracted in a common library).

I've got the flu, these days... but even conceive of such an architecture must have required a great fever... isn't it?