Sim, It is not any of these things. I think that both an in-memory system and a db system are options and important to provision, and a lot of other alternatives as well. I do not know how you get to the touching Entry conjecture.
We were talking about increased performance and about quality control criteria implicitly. I decided to put my two cents in and share what I knew from working with systems with very high demands: that is all there is to it, essentially. My two cents involves my central expertise, architecting pieces of high performance, mission critical, systems. The whole system needs to be looked at from my perspective prior to deciding on implementation details, otherwise an accidental architecture is the result. We know how those work. I am just sharing what I think and what the criteria (performance) is I need for our clients. Lately I am just talking about what I talked about! ;-) I am not sure what you are thinking, Sim, but I hope I addressed what you are concerned about. MG On Dec 16, 2010, at 1:44 PM, Sim IJskes - QCG wrote: > On 12/16/2010 09:48 PM, MICHAEL MCGRADY wrote: >> mean we do not do databases. Of course we do. Doesn't everyone? >> However, the primary data model and structures have to be in-memory >> because we cannot tolerate the time database calls take (in-memory is >> approximately 10,000 times faster). I think that this is not only a > > Is it, that you assume, that we would convert a in-memory based system into a > db-only system? Would a persistence interface hook, add so much processing, > that you can say in advance that you will not use it? > > Is it, that you say, don't touch the implementation of Entry, or i will not > use it? > > Gr. Sim Michael McGrady Chief Architect Topia Technology, Inc. Cel 1.253.720.3365 Work 1.253.572.9712 extension 2037 mmcgr...@topiatechnology.com
