4 ms·

The solution to this is a multi-tier architecture. Only one application that implements the domain model talks to the DB and all other apps talk to that applica

The solution to this is a multi-tier architecture. Only one application that implements the domain model talks to the DB and all other apps talk to that application. This doesn't give you the raw performance of a model living purely in the DB but may be a viable design decision. You trade flexibility for performance.

tricky 18y ago
depending on the size of your model, right? If your dataset is huge, your domain model app can shard the data and provide a nice entry point to tune performance without touching any of the n apps who are dependent on the data. I'm not sure i've ever seen a database that lets you plug in memcached to speed up certain queries.
- voidpointer 18y ago
  The model may still become a bottleneck if objects are tightly coupled and you can't scale out the model in a horizontal way. The low level nature and conceptual simplicity of the relational model allows database vendors to pull some pretty amazing tricks with scalability and clustering. People aren't building big database centric applications because they don't know any better (so I would hope). It all depends on the context. It shouldn't be the default because it can be inflexible.
- gaius 18y ago
  I'm not sure i've ever seen a database that lets you plug in memcached to speed up certain queries Oracle/Coherence/TimesTen.
gaius 18y ago
Umm, yeah, then you buy a third-party application that talks to your database just fine but doesn't know a thing about your "one application". Oh noes!
- voidpointer 18y ago
  Is it realistic to assume that a 3rd party application that can be customized to work with my database model can't be customized to work with a model exposed in some other way (web service, J2E, .Net or whatever)?
  - narag 18y ago
    No, it isn't. Database interfaces are very simple, text and table based, have been used for many years, are well tested, work reasonably well and fast, there are tools, bindings for every language in existence, and thousands of trained programmers. To change them for web services (I don't know how .NET or J2EE are equivalent) is not realistic at all.

tricky 18y ago

depending on the size of your model, right? If your dataset is huge, your domain model app can shard the data and provide a nice entry point to tune performance without touching any of the n apps who are dependent on the data. I'm not sure i've ever seen a database that lets you plug in memcached to speed up certain queries.

voidpointer 18y ago
The model may still become a bottleneck if objects are tightly coupled and you can't scale out the model in a horizontal way. The low level nature and conceptual simplicity of the relational model allows database vendors to pull some pretty amazing tricks with scalability and clustering. People aren't building big database centric applications because they don't know any better (so I would hope). It all depends on the context. It shouldn't be the default because it can be inflexible.
gaius 18y ago
I'm not sure i've ever seen a database that lets you plug in memcached to speed up certain queries Oracle/Coherence/TimesTen.

gaius 18y ago

Umm, yeah, then you buy a third-party application that talks to your database just fine but doesn't know a thing about your "one application". Oh noes!

voidpointer 18y ago
Is it realistic to assume that a 3rd party application that can be customized to work with my database model can't be customized to work with a model exposed in some other way (web service, J2E, .Net or whatever)?
- narag 18y ago
  No, it isn't. Database interfaces are very simple, text and table based, have been used for many years, are well tested, work reasonably well and fast, there are tools, bindings for every language in existence, and thousands of trained programmers. To change them for web services (I don't know how .NET or J2EE are equivalent) is not realistic at all.