Programming an application is a pretty daunting task. There are similarities between all applications but significant differences that require a programmers to work together. The more I work on “rescue” style projects or help out in the open source world, the more I think that programmers need to sit down and think through the database design.
When it comes to designing a good schema you need to know most of the requirements. I say most because trying to know all will lead you astray, this is software development after all. For my Trail Status project I kept the schema small, but when the project starts to grow it can easily adapt into a more well rounded schema design. Here are the project requirements for data to be stored:
- Trail state (open/closed)
- Coordinates to trail
- Translation (if translated from phone call)
- URL slug
If the table grew to more trails without adapting or refactoring the schema you would be setting yourself up for failure. What happens when there are more states like permanently closed, open soon, or under maintenance? If I let the data just grow without refactoring the schema I would be adding unnecessary code to try and manage my mistake.
Here is your challenge…
The next time you work on anything: pick a table and try to find a way that the schema design can be refactored. Kudos if your schema is up to snuff! I know most out there need a good cleansing.