Do you think of the database or objects first when building applications?

Question

When you think about building an application, say for the web, and it uses a relational database, do you think about the database first and then putting you app as a front end or do you think of your program and objects and how a database can store those. I'm trying to change the way I think but it hasn't clicked (I'm not sure I'm even right in my assessment.)

I have asked other Hibernate and nHibernate questions but I am trying to nail it down. I tend to think about applications with databases from the database side first and then think about the application. After reading much on Hibernate it seems that those using Hibernate think differently. They seem to think about objects and classes. They do the exact opposite of me.

And in the context of Hibernate. If I tend to think of the database side first, is that a "bad" or "wrong" mindset to have when starting out? I have only been able to find a few consistent reasons to use Hibernate or other ORM - performance, database agnosticity, and it varies from there. I want to use Hibernate but I want to approach it correctly. It seems to be a different way of thinking entirely instead of just performance and choosing databases.

Related:

Which is more important? DB design or coding?.

Answer 1

I prefer to think objects first.

Objects are the core part of the behavior of your application, and will effect how your end users work with your site/app, how the logic will work, etc. Getting the object model correct is key to making your project work correctly.

To me, the database implementation is just that - an implementation detail. I prefer to think of it as an internal representation of my data - I should be able to change it at will - refactor it in a sense, without changing my project as a whole.

I've found that focusing on the database first, not the project space, tends to lead developers down a dangerous road at times - you end up locked into thinking about a project, not from the user's point of view, but from the data structure point of view. That can lead to less usable software.

Answer 2

I try to avoid relational databases. Gemstone, Prevayler, Magma allow me to do OO without. Domain Driven Design also focusses on objects, not persistence.

In most domains, it makes sense to think about behaviour and interaction first, not about fields.

One of the problem with starting db-centric is that it is difficult to create the right abstractions. Models tend to stay too flat.

Answer 3

You'll obviously get a lot of different answers to this question, but I tend to think about the database first, and then build objects based on that. I think it's just easier for my brain to work that way, as I can visualize the database schema (and also, it is very easy to show relations in a database schema). @Tdpi hits it right here: you should design based on the problem domain - for me that translates to thinking in database, but it's different for different people.

Relations between objects are not always as obvious, and so it's harder to draw a diagram that shows their relations. Having objects inheriting from each other (but possibly using the same tables on the db side) can make things even more confusing. That said, in some complex applications, I've done both at the same time - eg, creating the table, and at the same time, creating the object structure where multiple objects inherit from the same base, and all use the same table.

Another argument for DB-first is most ORM layers tend to generate the objects based on the database schema, so if you design the objects, then try to reverse engineer the database, then let the ORM generate objects, you're kind of doing things backwards and are almost certainly not going to end up with exactly what you designed on paper first.

If you're using an ORM that generates the database for you based on the objects, then it probably makes sense to do this the other way around, and design your objects first. As long as you are modeling the problem domain properly, it is less important if you are building the database or the objects first.

---

All that said, the corollary to this is when I'm designing the front-end side of the application, I design it with a pencil and paper, and don't even think about how the data is stored in the backend (objects, database, or whatever). I just design the interface how I want it to look and operate.

The next job is then wiring up that UI to the backend schema, which is sometimes very simple, and is sometimes not so simple - but I've found this is how the best UIs are built. Often I don't expose all the functionality, or only allow simple settings to be configured (eg, only allowing permissions to be applied, even though the backend allows permissions to be denied from inheriting as well). This means your UI is not overly complex, or at least it's easier to build the first version, but you're also not stuck with making a limited backend or having to change it drastically in the future.

When you build the UI based on how the data is stored, or the objects that you've created, it tends to look like exactly that -- a UI that a programmer designed.

Answer 4

This is probably not the most common view, but honestly I just don't think it matters which way you go. If you think better on the database side, do it there. If you think better in OO code, do it there. There's not a right way to do it. They're both just ways of modeling the real-world entities your application represents, which is what you really need to think about.

Answer 5

Neither.

You think of the entities in the Problem Domain that you need to model. Whether you're modeling them as OO Objects or database entities is an implementation detail. (Though I find it easier to think of nouns/entities as database, and verbs/operations as OO code.)

In the context of Hibernate or other ORMs, my experience is that the database is better at explicating relationships between entities, and that designing a schema forces out questions about what those relationships are in the real world/should be in the model. It's not that it's a better model, per se, it's that it's a better process for forcing out those questions.

Answer 6

For me this is equivalent to asking if I think about users or programmers first. If I'm thinking about the quickest way to get this over with, I start from the database. I try pretty hard, though, to start with the objects (that come out of the use cases); then write the database schema that serves the objects. (Quite often they are different). If the database already exists, it's even more important so you force yourself to design a good abstraction layer.

Answer 7

Neither. Generally, I tend to think about it in terms of "verbs"; that is, what the users will be doing with the system. That is, I work through a set of use-cases where I look at what the users will be doing with the system. Once those are nailed down, they can guide the creation of the Business Objects AND the Database at the same time.

The problem with starting from the database is that if you do, you can end up with a very nice database that doesn't support doing what you want to do; if you think of objects first, you are thinking of structures. The user doesn't care about your persistence or your representation of the data; they just care that stuff gets done.

Answer 8

I find it hard to separate the two. My object model and my data model (in general terms) tend to end up fairly similar. Of course there are cases when this doesn't happen - so I'm generalizing.

In my mind, the following rules apply:

• The data model should be designed to accommodate optimal performance and optimal report design/development.

• The object model should be designed to transport the data to the application with optimal performance, scalability and GUI integration. You shouldn't have to jump through a ton of hoops to get data from the GUI to the database or back again. Frequently the core of the object model will be very similar to the core of the data model.

• The GUI should be designed to make the user's life as simple and as flexible as possible. The user shouldn't have to know/understand/care about/be exposed to the underlying object model.

Obviously there's going to be specialized cases where these guidelines don't follow, but for the most part, simplicity is the key.

Answer 9

For me it's a mix. Since starting with Entity Framework 1,5 years ago I tend to think in terms of navigational properties. I sketch things out on paper the way I want it then think of how Entity Framework will navigate between entities etc. From this I design the database, dump the database to an entity framework model and create my unit tests. Then I make necessary changes if it doesn't navigate fluently. Have not had any problems with speed really.

Answer 10

Both.

Note that the requirements and the idea should be done considering neither - dont worry about technical implementations at all during this time.

But when it comes to building an application - think in terms of both. In my opinion every programmer should have a fair idea of database and vice versa. Thinking in terms of both objects and tables helps you distribute things to the one who is best at it. (simple example: complex searches can be done in a multi-join or text-index sql than entirely in java or c#).

Answer 11

I was involved in 3 projects where people tried to stick object oriented design and way of thinking into a relational database which "thinks" differently. All of them involved hibernate. All of them were failures for similar reasons.. Coincidences? May be. Odd coincidences though... My humble opinion - use two heads separately. One for modeling the problem and another one for storing the data. For modeling, the object oriented way is best. For storing data - it's a pain. I personally prefer solutions when there is a middle man - someone between relational database and the rest of us :)

Answer 12

I always think of user interface first, after all, that is what the customer is going to see, and they aren't going to care if you database is normalized or your objects are well designed...(at least not the end users). After making sure the interface is what I want, I think of database second and the objects last - I think you could make a valid case either way on the last two, but I have a better DB background, and tend to like to work with big databases, so I consider a good DB design key. Once the UI is defined, and the DB is defined, the objects are the glue that makes it all work...at least in my way of thinking.