2 ms·

Thanks for your response! I think it addressed my comments well. It does make me think about the fact that almost every major DB today runs out of process and

Thanks for your response! I think it addressed my comments well. It does make me think about the fact that almost every major DB today runs out of process and that the market seems to have selected this pretty definitively. It seems like only recently some products are running in-process for performance reasons. But if I understand the trade offs here, only a single application can run in-process with the db. Also the db is not protected from crashing when the app crashes. But this is the 1990's explanation... any thoughts on how that applies to your situation?

pron 14y ago
> almost every major DB today runs out of process and that the market seems to have selected this pretty definitively. True. That's why I've tried to show the performance to be gained by letting the DB become integrated with the app. This is a result of the DB having just the right kind of knowledge about the relationships among domain objects to allow it to parallelize business logic. > But if I understand the trade offs here, only a single application can run in-process with the db. Also the db is not protected from crashing when the app crashes. Well, if the application and DB are one, so what? Note that we're only talking about OLTP DBs here. I don't see much of a reason for analytics DBs to be unified with the app. How often do you need more than one app working with the same OLTP data? However, if you absolutely must, there is no reason why the in-process DB shouldn't store its data in shared memory, thus allowing other DB instances to access the information. There are ways to ensure that if one app crashes the memory is left in a consistent state.
- threepipeproblm 14y ago
  >> How often do you need more than one app working with the same OLTP data? If you are running a modern web startup, it's probably not an issue. But in a typical business... often IMO. And it was one of the original use cases that drove the adoption of databases in the first place. Would be interested in seeing you blog about the last sentence of your last reply. Thanks for engaging my comments.

pron 14y ago

> almost every major DB today runs out of process and that the market seems to have selected this pretty definitively. True. That's why I've tried to show the performance to be gained by letting the DB become integrated with the app. This is a result of the DB having just the right kind of knowledge about the relationships among domain objects to allow it to parallelize business logic. > But if I understand the trade offs here, only a single application can run in-process with the db. Also the db is not protected from crashing when the app crashes. Well, if the application and DB are one, so what? Note that we're only talking about OLTP DBs here. I don't see much of a reason for analytics DBs to be unified with the app. How often do you need more than one app working with the same OLTP data? However, if you absolutely must, there is no reason why the in-process DB shouldn't store its data in shared memory, thus allowing other DB instances to access the information. There are ways to ensure that if one app crashes the memory is left in a consistent state.

threepipeproblm 14y ago
>> How often do you need more than one app working with the same OLTP data? If you are running a modern web startup, it's probably not an issue. But in a typical business... often IMO. And it was one of the original use cases that drove the adoption of databases in the first place. Would be interested in seeing you blog about the last sentence of your last reply. Thanks for engaging my comments.