Question

When developing an application which mostly interacts with a database, what is a good way to start? The application requires a lot of filtering based on user input, sorting and structuring.

Answer 1

The best way to start is by figuring out “user stories” (or “use cases” — but the “story” approach tends to really work great and start dragging shareholder into the shared storytelling…!-); on top of that, designing the database schema as the best-normalized idea you can find to satisfy all data layer needs of the user stories.

Thirdly, you may sketch layers such as views on top of the schema; fourthly, and optionally, triggers and stored procedures that might live in the DB to ensure consistency and ease of use for higher layers (but, no matter how strongly DBAs will push you towards those, don’t accept their assurances that they’re a MUST: they aren’t — if your storage layer is well designed in terms of normalization and maybe useful views on top, non-storage-layer functionality CAN always reside elsewhere, it’s an issue of convenience and performance, NOT logical consistency, completeness, correctness).

I think the business layer and user-experience layers should come after. I realize that’s a controversial position, but my point is that the user stories (and implied business-rules that come with them) have ALREADY told you a LOT about the business and user layers — so, “nailing down” (relatively speaking — agility and “embrace change!” should always rule;-) the data storage layer is the next order of business, and refining (“drilling down”) the higher layers can and should come after.