Should I design the application or model (database) first? [closed]

Answer 1

You know, I think I have to disagree with those that blindly put the design of the GUI ahead of the underlying data model. In a real business environment, running the business is not just about workflow - a huge component of business that revolves around data analysis and reporting. After all, how can you make decisions based on data you can't get to or understand? On top of this, when you sit down with a client, 90% of the time, they don't understand what their application needs to do, how it needs to be laid out and half the time, they don't even understand what functionality it requires.

How do you analyse your data if your whole data model is just a persistence of on-screen data? How do you report on that? If you sit down with a database guru and tell them you want a report built from a data model that basically represents your ViewState they would quit and tell you to do it yourself - at least, if someone told me that I had to build a report based on that type of model, I'd quit and tell them to get someone else to do it.

The GUI that sits on top of the data model is incidental and allows employees to interact with the data in the simplest most efficient manner. Bear in mind that software users aren't programmers, they don't think the way programmers or database architects do, and they don't do they work the way we work; nor do they want to. They want to be able to enter data easily and in the most logical manner according to their daily workflow. They want to be able to think, how much can I get done today so that when I go home, I don't have to take work with me, they want to go on vacation without worrying if the new guy will be able to keep up with the flow or if they'll be able to understand the software.

Business owners want to be able to get the data out in the simplest most efficient manner, they want reports written at a moment's notice, and they want that data represented logically, efficiently and representatively of whatever model they choose for the current report. They care little about workflow, they don't need to know how many departments this piece of data flowed through, where it came from, how it got to where it is now. They want to know what the piece of data is, what it represents and what does it mean to the business as a whole.

To a business owner, the data is far more important than the piece of software. To the end user who has pressure to do ten times more in ten times less time, the software needs to provide them with a means of getting as much data into the database as possible in the shortest amount of time.

So how do you decide which to design first, the GUI or the data model? How much money is going to be saved in the longer term? Does the company have 500 users entering data into this piece of software and are they doing it in the most efficient manner? Does the company have 500 report writers and can they get at the data quickly and efficiently? How long is a piece of string?

Design your data model for the data analysts - make it as clean, efficient as simple as possible to get the data out in a comprehensive format.

Design your GUI for the end users and make it as clean, simple and efficient as it can be for those users to get as much data into your database as quickly and as simply as possible without having to be a rocket scientist. Frequently end users are barely computer literate in comparison to those writing the software and extracting the data.

From the outset, always keep in mind how you're going to wire the two together because if you don't, you'll end up with two ends and no way to provide a middle and your project will fall to pieces...

More money is wasted putting data into a system and getting the data out than writing the software that does the wiring between the two ends. A team of developers doesn't cost nearly what it costs a company whose users are inputting inaccurate data inefficiently and poor quality reports because the data analysts can't get at that inaccurate data efficiently and spend a week writing a report that realistically shouldn't be taking more than an hour or two and when it is written is no help anyway.

Answer 2

How about both?

Another approach is "feature-based" development - build a vertical slice through the application, just enough at the model, persistence and interface levels to get a feature working completely. This might be something as simple as logging in, or editing a single object.

This approach means that:

• you get to build a small chunk of both model and application together up front;
• you quickly discover any danger areas in the stack of technologies and designs you've chosen;
• you rapidly have something you can show to people for comments;
• you avoid the fallacy that anything gets designed right first time...

Answer 3

Well, to an extent the requirements must come first. The database is the servant of your requirements after all, not the other way around.

It seems to me that what you're really asking is: should you design the application completely before you start on the database (and then write code after that)?

My answer is no. It's better to jump in and get moving quickly.

I would probably design the app in broad strokes and then use an iterative approach. Which is an idea from Agile. There is a lot out there on this subject.

Now if this was a two year project with 20 developers, stakeholders, and a budget, things would be somewhat different... But perhaps not as different as you think! The more complexity you're dealing with, the harder it becomes create a perfect, monolithic plan up front.

Some people say there is a point where it actually becomes impossible.

Answer 4

Personally, after I know the requirements (formal or not), I design the data model to handle the requirements. Then build out from there, with the business layer, persistence, unit testing, and then finally the GUI.

If your DB is designed properly the first time, everything should just flow.

EDIT-Please be aware, that I'm not implying that your business layer or GUI should be a direct reflection of your DB model. Sometimes it will be similar, sometimes it won't. But your DB model should be able to accomodate all requirements.

Answer 5

My tactic is roughly this:

Read the requirements, and write down all nouns or "players" in the document. These are usually 80% of the things you need to store or interact with.

With these things on a sheet of paper, read the requirements again and see if you can find that the things you have on paper can actually be used to do the job.

The, find their attributes and make a data model. Try to fit that into the database. Build up from there.

For web applications, this usually works for me (even for consierable size applications). As you've noticed, I didn't use terms like UML or ERD. These are just tools for communicating the model in your head with others. Powerpoint can do that, too. It's the quality of end product that counts.

Answer 6

This is the age old question. The answer, like every CS answer is that it depends. 90% of the applications that you write are just forms over data. In many of these applications, you will have legacy applications with data that you have to port over an go from there. Therefore, whether you like it or not, the Data/Database is a constricting factor and it drives whatever you do. It’s not just a place to store your domain objects, it is your domain, even though that’s not the “right” way to do things.

In most cases, I’ve designed my data model first in a way that takes the existing data and organizes it into the relational model. I then do basic screen design. Then I build my anemic Active Record type business objects to wire them up. This is by no means the best way to design software, but in most cases, it’s the way that things will be done or have been done. In these cases, your business objects really are just containers for data with business logic around them to wire them up to the screens and insure data integrity and screen security. This sucks, but it is what it is.

If screen interactions are the most important thing, then maybe designing the screen first and then have you other objects depend on that will be your best bet.

If you are lucky enough to have a Greenfield project where the domain is integral in the application and the database is merely a persistence mechanism for your domain objects, then I would develop the domain objects first using Domain Driven Design in a TDD manor and develop the screens and the database around the domain objects. I would love to code like this more often, but you don’t always get the opportunity in most places.

Note: Stack Overflow is designed in a Database as the Model way, so it can't be that evil.