David Ziffer (10/7/2010)

---

Ahmed Saad (10/7/2010)

---

I am also developing an application with similar goal as that of RAP but with a different approach. It is UI driven, which means all the back-end stuff will be generated by the screens designed by a domain expert. Zoho.com has a similar application called Creator but it is much difficult to use as compared to the design I am working on.

Ahmed: I am not one to generally discourage people from trying exciting new stuff, but you might want to reconsider the top-down approach before you invest a whole lot more time in it. I have had several people in the past point out the fact that there are already UI-based code generators that generate the database, but I have never taken the bait.

As a consultant I have seen many schemas in many places. If I had to identify the one most crippling problem I see in all of database-land, it is the tendency of schema designers to create schemas where the tables look just like screens of the UI. Such schemas tend to be highly denormalized and further they don't generally model the real-world structure of the problem (since the UI doesn't generally do that), making their databases highly resistant to modification, including modifications needed to make them support new user interfaces.

This is especially important in the current environment where applications increasingly must support multiple UIs, including (possibly) native client, web, mobile, and web service. A mobile UI will generally be much more fragmented than a native client or web interface. Would a top-down solution that supports all of these interfaces actually generate the same database from all of them? I personally cannot imagine how a translator could create a good schema, which requires deep real-world understanding of the problem and profoundly good modeling skillls, from something as superficial as the current UI spec. Then of course there's the problem of supporting a version of your product that generates code from every UI that a programmer possibly could possibly need to support. Even if you could afford to do this, how would you reconcile them?

Here's an example of the problem with UI-driven design. In the consulting business UIs tend to be client-driven because the UI is generally the only thing the client understands. Suppose you are designing a CRM system for a client who tells you that he wants a UI in which the screen (or page or whatever) displays one phone number for each person. Now you know perfectly well that next year this client is going to realize his mistake and come back and require you to allow for multiple phone numbers, but for the moment there is no dissuading him. With a bottom-up generator like RAP you'd just design the database properly anyway (without the client even knowing) and give him the UI he wants. Next year the only thing you'll have to change is the UI. But with a top-down generator you'll be stuck with a schema that supports only one phone number per person.

This is why I chose the bottom-up approach. RAP will not and cannot make the schema designer's job go away, because of all the components of app design the schema requires the deepest insight into the true nature of the problem. A serious app designer models the real world, not the current UI's vision of it, and RAP lets him do that.

In my opinion there is no escape from good schema design. RAP obsolves the schema designer from making the generally arbitrary decisions regarding keys, status fields, and auditing that I see being made poorly every day. It's very much analogous to compilers (replacing assembly language) absolving programmers from the need to design a parameter-passing convention for every function they write. But at the end of the day, if your schema isn't properly normalized and well structured, you're doomed no matter what tools you're using.