The Separation Model – Part 13 – Data Storage vs. Data Display

by Matt Petrowsky

Article options

• Watch Preview Video
• Watch Full Version
• Download Technique File
• Download Movie File

It's SO, and I mean SOOOOOO, easy to cheat on the Data Separation model. You just add a little calculated field here and another over there - it's no big deal right? Actually, (my personal opinion) it's not that big of a deal. I mean "Really" you do have access to the UI file AND the Data file - "You're the developer!".

However, the situation may come up where these "extra" fields just clutter up things when some DBA wants to access the data via ODBC. So why not just keep it clean. The trick with this little problem is, what you show in the UI - for the user - is not what you're going to store in the database. This will happen quite a bit, and requires a different way of thinking than "I'll just add another calculated field."

The answer to this little problem is UI Utility tables. Sometimes, it's as simple as a tiny little table storing the names of days. Other times, it may be a complete mirror table which contains automatically populated data just for the purpose of showing calculated values.

To what extent you carry out the Data Separation model, is entirely dependent upon your willingness to keep things separate. It's my job to show you how you can do this - and that's exactly what this video is all about. The separation of Data Storage versus Data Display.