An amusing hashtag went viral on Twitter last week. Tweeters shared their bad dating experiences with #fivewordstoruinadate. The idea was soon hijacked by those airing bad interview techniques with the hashtag #fivewordstoruinajobinterview. A #hashtags allows tweeters to explore all tweets containing the hashtag.
I decided to hijack the hashtag for us database folk. A bad database is just as deserving of some attention as a bad date or job interview. What five words would you use to describe how a database is ruined? Here are five of my favorite #fivewordstoruinadatabase.
- No one else uses this.
This oldie but goodie comes from the early days of data processing when applications were silos that owned their data. Technology advanced, and the ability to share data became increasing more available and reliable. An enterprise view of data became more common. This problem manifests itself today in a slightly different flavor. Speed to market and faster development cycles can lead a project down this path to ruin. Always assume that data will be reused.
- But this data is different.
This is a variant of “No one else uses this.” Data does not know departmental boundaries. The same data can be stored with different names. Different data can be stored with the same name. Multiple parties can claim ownership for what data is correct and correctly named. The wrong answer is to assume they are different. It is important to untangle this web in data design and governance efforts.
- Put it in one table.
This has been my all-time favorite for years. Relational design is about normalizing data for reuse. This often conflicts with developer views of how the database is structured. Too often the call is to flatten the table structures to ease the burden of the development and end user tools. IT folk need to rely on the toolsets they have to optimize database performance. A database view may solve this issue. Configuring data access in development and end user tools is often overlooked. Care must be taken to maintain the enterprise view of data in denormalization.
- No time to analyze this.
This project has a short development cycle and the database must be ready for development ASAP. There is no time to look beyond the scope of the project. These sentences are a clear signal that the project has potential to ruin the enterprise view of data. Some projects will be fast-tracked. Data folk need to own the enterprise value of data for all projects. This means that analysis is not compromised for even on the shortest of project timelines.
- Build it, they will come.
This is a very tempting in today’s world of big data. It’s easier to manage larger volumes of data. It seems harmless to toss in some related data while delivering the data the business needs. Space is cheap; processing time is cheap; and it might save some resources in the future. There is value in a data strategy that justifies the data in our enterprise data store. This extra data may seem pertinent today but may not be in the future. Data architects are not fortune tellers.