Database Design Directions

February 23, 2012

We came across a quite useful checklist every database architect should keep on hand. Java Code Geeks give us “20 Database Design Best Practices.” The list covers everything from the commonsense:

“Use well defined and consistent names for tables and columns (e.g. School, StudentCourse, CourseID …).”

To the more advanced:

“Normalization must be used as required, to optimize the performance. Under-normalization will cause excessive repetition of data, over-normalization will cause excessive joins across too many tables. Both of them will get worse performance.”

With a little strong opinion mixed in:

“Lack of database documentation is evil.”

If you design (or oversee those who design) databases, do yourself a favor and check it out.

Most people think of search as providing access to unstructured information. Examples of unstructured information include email, Word documents, and Excel. Our extensive work in enterprise search has spanned structured data; that is, information in a database.

Search Technologies can handle difficult content acquisition tasks when needed information is held within Microsoft SQL Server, IBM DB2, Oracle, or a similar data management system. In addition, Search Technologies can set up automated processes to handle extraction, transformation, and loading of data or subsets of data.

For more information about our capabilities to make structured and unstructured data more findable, navigate to

Iain Fletcher, February 23, 2012

Sponsored by


One Response to “Database Design Directions”

  1. More on Database Normalization « My Journey Into Microsoft Access and WordPress on March 5th, 2012 12:48 am

    […] Database Design Directions ( […]

  • Archives

  • Recent Posts

  • Meta