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

Answer 1

From experience, designing the database first (based on requirements), can lead to things going very smoothly.

This is especially true if your data does not just relate to data entered in the UI, but may include pre-existing data related to or imported for the project.

On a mid-size project I may go through 100+ iterations of the DB using an ERD diagramming tool like Erwin or Power SQL. Then, click the forward-engineer button to get the DDL.

The domain objects will typically look a lot like your main tables, however they will often have collections where the DB has look-up tables, etc. Also your domain objects may have other objects in them for organizational purposes, etc.

Then wire up a DAL either hand-rolled or ORM of your choice.

Thing is, none of the tools designed to automate this process seem to do it 100%. In a code utopia, I guess you could just create the DB model and have the perfect domain model created or vice versa, and than get a perfect ORM with a few clicks. In reality, this is a lot harder than it sounds, and subtle issues can arise like performance and flexibility.

Answer 2

According to Martin Fowler which most skilled developers recognize as one of the "authorities" in these questions you design your OO hierarchy first and then "map" the objects into your database using e.g. the ActiveRecord design pattern...

Answer 3

It's one that works either way, but personally I'm leaning toward designing from the UI back more and more.

The main reason comes down to being able to create supporting automated tests.

One of the strengths of automated testing is the flexibility to refactor and change your code as you go. However the UI is typically the hardest to change, and the one that often requires the most work to get right.

So for that reason, I advocate designing the UI, get it as close as possible to the finished version, then move backwards creating your middle and back end to support the operations carried out in that GUI.

With a relatively stable (and difficult to test) UI in place, you're free to mold the other layers with a lot more flexibility once you've got good test coverage for them.

If you design from the database up, you'll end up with a stable, easy to test database, and a LOT of messing around getting the GUI just right to match what you've done with the DB - which ends up taking a lot longer as you're making the most changes to the level of the system that is the hardest to test and has the lowest test coverage.

Plus the fact that DB driven designed apps end up having no personality and are difficult to use. They look like the same MS Access form for each screen, except with different fields.

Answer 4

Most web applications don't do much more than just processing and presenting different kinds of data.

I would start with exactly that: What data do I want to process?

After that, you can start modelling how this data will fit into a database best.

Then you should also think about how you access this data-does it give you any hints for optimization in the storage?

I would design the application itself either at the end or even parallel to it. The application design should be independent from the database model. It's only the code itself which will in the end access the database.

But, web applications also tend to grow. So an evolutionary model, where you add new fields or tables to the database and build new code around it, is very common.