I remember when I had OJTs last year.  I was happy to have them, seeing them as the new, fresh faces of tomorrow's computing world.  I had two coming from UP LB (Bless and Eleni) and three from UST (Chloe, Sam and Shiela).  Each of them had their own strengths and weaknesses.  Others were born to become leaders, others, merely followers.  Some are innovative, while some rely on your direct input for them to work on.

They had different assignments per week per department.  But all of them awaited to be assigned in my department–IT, since it was going to be the heart of their internship.  When they had their turn in my department, I had them assessed based on their best skill.  I motivated them to work on the technical aspect that they loved the most, but not withstanding the fact that they must learn all aspects.

For throughout their stay in our company, they were to accomplish one project as a team.  Here, I wanted to see if they can perform as a group and take on roles by themselves.  We had meetings to ensure that they were following the Software Development Cycle.  At first was planning, of course, followed by analysis.  As I was discussing the flaws and correctness of their proposed database design, I was subjected to the question:

"How did you know that that design is going to be the best?  And, how come you do not have to enumerate everything on paper/board just to see their relationships?  Is there a specific step by step process for this?"

Of course, I am no genius, otherwise, I could have overturned Google's and Yahoo's profits already.  :D The answer, is of course, by experience, and by good education.

I only follow few rules on creating a good database:

  • Identify only the key objects of your application.  These are your tables.  If the other elements are trivial, then they fall as columns.  Get as many information as you need for the flexibility of the database.  Don't rely on the current specs of the application.  Consider also some more changes in the future.
  • Once all elements are laid down, identify their relationships.  Remember that, you must be able to reach to an item (through relationships) using only one path; otherwise, the database is already ambiguous.
  • If you find your tables having multiple primary keys, then something might be wrong.. refactor.
  • Never ever forget the power of the UNIQUE constraint.  And, never ever forget to use indices (INDEX).
  • Subject your ddl to a walkthrough.  Imagine your application using your database.  Is it good for display too?  Sometimes, the more robust the database is, the more its difficult to render data in display.  :)

Keep subjecting your design to many questions.  Keep trying your own design as if it's not yours to begin with.  In the end, you'll find that you'll continue to refactor until you get to a good, clean, robust database design.

PS:  Your revisions must not exceed one week, otherwise, it wasn't carefully planned at all! :)