I'm not particularly up on MVC as an architecture but isn't the Model just a duplication (except slower and buggier) of the database?

Given modern databases support stored queries, user definable functions etc. why treat them as an implementation detail?

Is it because programmers generally don't want to learn SQL/ Relational design? Or because there's a fundamental mismatch between relation and object models?

Broadly the database can present an API, why do it twice & more slowly.

Any McConnell like numbers to back up viewpoints would be greatly appreciated

3 Answers 3


The model is just that: an object-based model of the business domain. The database is also a model of the business domain, but in a different form, i.e. tables and relations. They complement each other; what one lacks, the other provides. It's not an inner platform; an inner platform would subvert the technology it is imitating. The Model does not do that; it depends on the features of a database; it doesn't replace those features.

Object-relational mapping is an imperfect solution to the impedance mismatch problem. But relational databases and their SQL language are a mature, well-established technology with many intrinsic benefits. Using an ORM allows you to have the best of both worlds; you can store objects in a mature, well-established technology, but still use SQL to solve set theory problems.

Further Reading
The "Vision" project, a cautionary tale about inner platform effect
(This is what an Inner Platform really looks like. You can skip the preamble and start reading at the subheading "Introducing Vision")

  • I was reading about the Vision project yesterday, coincidentally. Mar 13, 2015 at 16:08
  • Same point - an RDBMS can present an API, not just tables/relations & views, hat exactly is the model adding? Mar 13, 2015 at 16:59
  • A layer of abstraction. Mar 13, 2015 at 17:04
  • Yes, but what does it do that the dbs couldn't? Mar 13, 2015 at 17:16
  • It gives the database the ability to store and retrieve objects. Databases store data, so to get them to store objects, you have to convert the objects to data. And vice-versa. There are object-relational databases, but I've never worked with one, and I think you'll find that's true of most of your colleagues. One of the advantages of relational databases is that they are widely used and well-understood. Mar 13, 2015 at 17:19

You've got things the wrong way around.

The model is not a poor replica of the data base. No programmer cares about the data base. The data base exists only so that in a future invocation, we can easily reconstruct the same state of our business objects as before. Data bases are strictly a means to an end. They allow some processing and offer some tricks to speed up the inefficiency caused by mass storage access, but then they are also the sole cause of these inefficiency problems. If we could get by entirely without data bases and instead persist our business objects magically in the memory of tamed unicorns instead, we'd do it in a heartbeat.

The model isn't like that. The model supports all operations that we can do in our preferred programming language, which is why we chose it. The model is what we'd like to program. It is so central to the system that it is very important not to pollute it with concerns of other levels. This is why indices, table scans etc. should be kept out of the model, but also why combo boxes, HTTPRequests etc. should be kept out.

Not having a model would mean that the same code that deals with reading and writing widgets also deals with SQL INSERTs and connection parameters. That would be very bad, because thinking about two entirely different things all the time halves your efficiency as a developer. This s why it makes sense to separate those concerns and have layers dealing with the UI, with business logic, and with data storage. It leads to an increased amount of code, but since each of the resulting classes has a clearer focus of what it's supposed to do, general efficiency increases.

This result has been hard-won over several generations of programmers, and since it's non-obvious, every new generation has to be convinced anew that they will be better off not trying to do everything at once. But the majority of professionals will confirm that in this respect, having more and simpler classes is better, even if you end up with more code lines in total.

  • 1
    If we could get by entirely without [table-based, relational] data bases and instead persist our business objects magically in the memory of tamed unicorns instead, we'd do it in a heartbeat -- You can; it's called an "object database." There are good reasons why they are not widely used. Mar 13, 2015 at 13:51
  • Thanks for your reply, you've asserted the standard viewpoint, but not defended it (in my view). "No programmer cares about databases", seems quite extreme. Any numbers for the greater efficiency claims? the SQL should all sit on the database is my main point - so the application code won't have any SQL in it. You can abstract away the connection details quite easily. Mar 13, 2015 at 13:54
  • Reasons for OO database failure in a nutshell are? Mar 13, 2015 at 13:58
  • @AlistairMackenzie: Sorry, thought you were the answerer. The reason OO databases never caught on is that table-based analysis of data is very useful in a business context, and it's hard to do that well in an object database. NoSQL suffers, to a certain degree, from the same problem. Mar 13, 2015 at 13:58
  • @AlistairMackenzie: It sounds like you're an "all stored procedures, all the time" advocate. One of the benefits of SQL is that you can use it remotely across the network, not just on the database server itself. Mar 13, 2015 at 14:02

Only in the least complicated of applications might the model be a duplicate of the database and not necessarily even then.

Fundamentally that assumes a 1 to 1 mapping between the data presented to the consumer and the table structure of the database (be that relational or otherwise) and in reality that its seldom the case.

If we look at MVC the Model is the model for the view - even if this does just represent a single row from a single table the odds are that there are going to be lookups, fields that as presented to the consumer have a value but as stored in the database have an ID, your model may well then contain the display values as well as the actual data that is persisted.

Then we get into all kinds of interesting questions about validation - what and how and where.

Now take another step - note that I said "consumer" - what if that consumer is not an end user looking at a screen, what it its an Single Page App consuming an API. At this point from the point of view of the client facing app there is no database - but there is a model...

What this is giving us is a logic separation where we look at models that are appropriate to the context they're used in - one for the UI maybe a different one for use in business logic and then a the storage model which may well be relational and involve several tables. By treating them separately and ensuring we are comfortable mapping between them we end up with a great deal of flexibility in our overal structure (where the "system" may then fairly trivially span multiple applications).

Of course if all your doing is straight CRUD over tables of data then the relation between data model and view model may be quite close but if using a relational database there will still always be some mapping.

  • My point being that the database can effectively wrap the tables up in an API, an RDBMS is not just a collection of tables or even views. Mar 13, 2015 at 16:28

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.