Which comes first, the database or the application UI? (by yag)

Interesting blog post and comments at Kent Tegels site. It discusses whether you should focus on the database design or the application UI first. I’ll post some comments about this later – probably after I return at the end of next week.

Comments (10)

  1. denny says:

    "It Depends…"

  2. Brian Bolton says:

    If you’re a DBA—> the Database

    If you’re a Programmer—-> the Application UI

    I think it’s that simple the two are not realated neccesarily related except in CSI classes. If you’re both god bless ya!!

    Its the programmers job to make it look pretty and fit on the screen and present it logically to the user. The DbAs job is to design a system for *efficient storage.. quick queries..


  3. David Stevenson says:

    But Brian, what if you are both the DBA and the programmer (often the case in smaller development teams or projects)? Not everyone is an enterprise developer.

    Bottom line is that neither the database nor application UI comes first — it’s the requirements document, reflecting a thorough analysis of the problems to be addressed.

    With that in hand, I would most likely move toward somehow documenting the various major entities that would point to the database design, with any specifically unusual UI requirements kept in mind during the database design.

    But, then again, I’m a database guy at heart (although most often I’m doing both the database and UI design).

  4. Kevin Marois says:

    The Database does. Create a database that isn’t right, and your UI is all for nothing

  5. Lance Delano says:

    Actually, I think that those who are saying that the database comes first are usually really saying that the data model comes first. That is, a focus on the data structures is the fastest way to cut through a lot of the mistakes that are often made with a UI first approach. I agree that such a focus is highly efficient. However, I also like to – – in parallel – do the UI prototypes as well. It helps as a cross check for what is in the data model and it’s easier for customers to grok what’s going on. So, guess what? I’m a model first guy.

  6. Kevin Marois says:

    Actually, I do believe in prototyping the UI before the users early on. That way you don’t spend months of coding UI components only to have the users tell you they don’t like it. To a user, the first impression is what they see when the double click the icon.

    Having said that, I still believe that designing the database model up front saves much time later on. Design the data, create the database, and some test data, the design the queries, and then reports to test the data.

    Then you can use the queries and reports to test your data entry modules.

  7. Lisa Nicholls says:

    Interesting and valid responses all (both here and on Kent’s site) but…

    … It’s a really silly question <g>.

    The database and the user interface are the father and mother of the application. The application requires *two* sets of genes, from the two-cell stage up.

    They need to be developed concurrently, and it doesn’t matter whether they are both being developed by one person or by two completely separate teams. In the latter case, the teams have to communicate clearly and constantly.

    Invest resources and time in database design first without reference to "what users are going to do" in the UI, and you will find yourself shoehorning the UI to fit your earlier investment later.

    Do it the other way around and you will find you have made UI promises you can’t keep.


  8. kim says:

    What about the designer? I’ve seen some pretty cold UIs done by developers.

  9. Pavan Sabharwal says:

    if you are a SOA person then the message comes first :->