Here is a snippet I wrote on the oracle-l list today before I remembered that I’m a blogger now. To see the whole thread in context (potentially including someone telling me I’ve got it all wrong later today or in the future) the subject was OT: sheltered little world i live in -> NODB?
Someone opined about where a DBA would start designing. That person might be right about some DBAs. Here is approximately what I wrote (only fixing some typos and grammar, I think.):
gee whiz. I think people think of me as a DBA. re: “That’s true that DBA would start designing application from database.” (sic.)
Larry Constantine has written some excellent books about information systems design. Many of my ideas are well explained in those books.
First, you figure out what the application needs to do. Folks have made the phrase “use cases” popular in recent years. I always check whether someone is wearing clothes when I hear that phrase. For some it is an extremely useful focusing phrase and for some it is an excuse to not know what you’re doing. So check. By the way, figuring out what the application needs to do, right away, includes getting a ballpark idea of how much total data is going to be handled and where that fits in the context of the current capabilities of hardware. “Is it bigger than a breadbox?”
Second, you need to figure out what the inputs to the systems are, what the outputs of the system are, where the transform centers from one to the other are, what instrumentation is appropriate to determine whether the inputs are correctly becoming outputs (where appropriate includes performance), and what the required information life cycle is for all the data and metadata about the system. Lingo: Inputs are called afferent legs, outputs are called efferent legs. A point many folks (not including Tim Gorman, who nailed this in one as well as making several other key points with many fewer words than I need) miss is that efferent legs include reporting requirements. That’s analytics, mining, performance metadata so you know whether your system is heading for the crater: ALL THAT.
Third, you need to figure out the data model requirements for the system.
(That could indeed be a flat file [and please note that a single flat file can be a representation of a relation] – and awk might be just the right tool [or even just grep], but you don’t know that before steps 1 and 2.)
Fourth, you need to figure out how much of the system you can build in the first chunk without making it impossible or difficult to build the other parts of the system.
Fifth, you need to assess a useful point on the scale between complete waterfall design and the lightest weight agility that makes sense for the project.
Sixth, you need to choose tools and technologies and start construction if the expected value of the application exceeds the expected cost and is within budget.
Seventh, you need to get a pizza and a beer. And I hope it is a really good beer. I think the article author made a lot of good points about beer. Now for some really trivial applications, you might go through the first six steps and build the thing in under an hour. If that’s the case, you better do a few of them before you proceed to a bundled step seven. But do not forget to budget for the pizza and the beer.
PS: Step seven is also the seventh step of debugging, but that is a different story