I think its worth pointing out 2 major changes in how we work with relational databases that have a negative impact on performance (but many other advantages):
1. We started developing in OO languages and thus introduced an impedance-mismatch leading to inefficiency in processing. 2. We choose to run our business logic in a separate (physically and logically) tier from the data. Network round trips introduce an order of magnitude slower performance. I think its telling that in environments where performance matters more than anything (eg banks), they choose to use languages like C (Pro C) and stored procedures. Relational databases are still with us because they are reliable and fast. Unfortunately we choose to access this data in inefficient ways. R On Thu, Jul 16, 2009 at 11:21 AM, Christian Catchpole<[email protected]> wrote: > > I think this recent wave or 'rethinking' peristance, and google apps > big-table style storage, is long overdue. I'm not saying it's not > going to be a difficult progression, but it's long overdue. I > remember when I first started working with SQL storage.. around 1999. > I couldn't believe how it worked. It all just seemed so backwards > compared to how i understood software to work. The data types didn't > match the ones I was used to.. and SQL seemed so unprogramatic and > clunky. And how could getting your data over a socket ever be > efficient. > > Now it seems the only way a high volume web site can interact with > it's database is by using a huge cache infront of it. Now this > suggests to me that the technology (or the access to it) is falling > behind the way we need to use it. And even if it works, the problem > with a cache is that me be out of sync with the database. And even if > you use multi-cast updating caches, well, then your providing sync > functions that I would expect the database to be handling. In effect > we are creating in-memory databases which are kept in sync with the > storage. > > I'm not saying I have any magic answers, only that SQL databases, > while highly efficient for many purposes, with an industry based > around them, are obviously not cutting it for many projects. > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/javaposse?hl=en -~----------~----~----~----~------~----~------~--~---
