Failure To Do Data Analysis

October 27, 2010

Databases are all about, data.

So it’s totally bizarre how so many people working with databases never look at the data!

It’s really so fundamental, it’s hard to make a good analogy.  Imagine a tailor making your clothes, but never looked at the fabrics!  Can you think of a better analogy?

I’ve met programmers who have charged ahead and written one thousand lines of code, and have not even looked at either the data in the tables, the input, or the output!

Read the rest of this entry »


The Meaningless Data Model

October 6, 2010

More Database Design Mistakes To Avoid
Architecture Mistakes to Avoid

The saying goes, a picture is worth a thousand words.

If an organization has a good database model, with meaningful table and field names, a look at the model should give you a pretty good idea what the system does.

Like a picture, when you look at a model, it’s supposed to communicate.  Consider a model car, or airplane, or a scale model of building.

Without a model or picture, can you communicate how to build the special research car, XOF1?  How it runs?  Or what it looks like?

Similarly, can you look at an ERD (Entity Relationship Diagram) diagram your of database, and have a pretty good idea of the system does?  Or not?

At so many places, I’ve have to look in many places to understand the system.
– Many queries to the Oracle Data dictionary
– Values in database fields.
– Rows in database tables.
– Extensive data analysis.
– Requirements documents, that don’t give any specifications, most always outdated. Read the rest of this entry »


Cars, License Plates, And Using The Wrong Identifier

September 29, 2010

More Database Design Mistakes To Avoid
Architecture Mistakes To Avoid

I’ve now moved to a few different states, and registered my car in the new state.

Even though I was only a customer, and never saw the back end database, I could quickly tell which identifier the states were using for the car.   Each identifier had huge implications on the whole process, the consumer, the insurance companies, and the DMV.

In Connecticut, the process (in 1999) I followed was as follows.
Read the rest of this entry »


Creating Cobol Systems Inside the Database

September 29, 2010

More Database Design Mistakes To Avoid
Architecture Mistakes To Avoid

I haven’t worked a whole lot with Cobol, but I did do enough.

Coming from a background where the first thing I really learned well on the job was how to do good database design, there were some odd things that I noticed about Cobol.
Read the rest of this entry »


Ways To Get Duplicate Data

September 23, 2010

More Database Design Mistakes To Avoid

Duplicate data.  Designed into the system.  How can I count the ways?
Read the rest of this entry »


Splitting a Table Vertically, AKA, Duplicate Tables!

September 23, 2010

More Database Design Mistakes to Avoid

There is more than one way to split a 1:1 relationship into multiple tables.  In the first example, the table was split horizontally, and different columns went into different tables.  But the number of rows stayed the same in all of them.

The stranger way is to split the table vertically.

In other words, to have duplicate tables!
Read the rest of this entry »


MUCK – Massively Unified Code-Key, Generic Three Table Data Model

September 21, 2010

Another Database Design Mistake To Avoid.   Actually, one of the worst DB design mistakes you can make.

One of the worst things you can do to a database system is to make a generic data model of three tables for the whole system. A variation is to use three tables to combine multiple lookup tables into one.

Instead of standard tables and columns, three tables are used for everything.

One table each for:
entity/table
attribute/column/field
values of the data
Read the rest of this entry »


%d bloggers like this: