The great thing about Active Server Pages is that they can utilize database connectivity. This lends an awesome amount of power to web driven applications. When one decides to design a database driven web application, they often rush into it far too quickly, throwing together a few tables and writing a couple of quick 'n' dirty ASP pages. Then, once a working prototype is complete, the developer will often go back and pretty up the ASP pages, making the application more user friendly and usable.
Well, I'm here to tell you that there's something fundamentally wrong with the mentioned approach. First, before you code a single line of ASP, you should have dedicated hours to your data design. Translating the business logic into tables, columns, and relations is called data modeling, and, unfortunately, data modeling seems to be a lost art. My work experiences in the real world (which has been limited, I am a college student after all!) has led me to believe that there are very few developers who truly understand why data modeling is vital, fewer who take the time and energy to employ it, and even fewer who can do a good job at it!
Over the next three articles (Data Modeling 101 (this article), Data Modeling 201), and Data Modeling 301) I will address those three issues. In this article, Data Modeling 101, I will discuss why data modeling is vital. In Data Modeling 201, I will show you how to employ the techniques of data modeling, and finally, in Data Modeling 301, I will share little tips & tricks I've picked up from those few extremely good data modelers I've worked with. (Please note that I am in no way claiming to be a skilled data modeler myself!)
So, the question for this article, is why bother investing the time and effort to design your database? You may not want to believe this fact, but your application and product will be used long after you leave the company! Not only that, but while you are still at the company (and afterwards), the application will need to be updated to include new features. As developers, we often expect the lifetime of our software to be shortlived. We figure the company may use it for a year at most, then either code a new version or simply stop using the product. If this were true, we wouldn't be stricken with the Y2K problems which face us and the world today!
Since you will have to be updating your project (as well as other developers),
you want it to be easy to maintain. With carefully designed databases, developers
who are new to your team can ascertain the purpose of various tables and columns
better if these tables were designed with maintainability in mind. Say you have
a table which keeps track of expenses, and let's say for the accounting department that you must record what
department the expense is being billed to. The accounting department may keep
track of which department by a field they call DepartmentCode, which is a seven
digit alphanumeric number. Now, you may be temped to create a column in your
expense tracking table called DepartmentNumber of type numeric(7,0). Resist this
temptation! Future developers looking through the data in the table will see
9381170, and have no idea what that means! Also, what happens
when departments are restructured, or new ones are added? A good data modeler would
create a code table which would have an English-like name for the department, and
the DepartmentNumber as a UNIQUE key.
Maintainability should be one of your driving motives in data design. Of course, as always, take extra care to name your tables and columns. Design detailed and descriptive Entity-Relation diagrams (ER diagrams), and keep those on file. Todays modern databases are all relational (Oracle, SQL, Informix, Access, etc.) Establish logical relations in your database. (I will discuss how to make logical relations in Data Modeling 201.) What is key, is as you are designing your database, think ahead; pretend you are a new developer to this project five years from now. Would you understand the table layout? Would the column names make sense to you?
Why spend sufficient time to ensure a good data model? To answer that question, find some developers at your company who are working on legacy code! :) I hope this article has convinced you for the need of data modeling. The next two articles will show you how to data model and how to do it well!