I think the case as, always, is to choose the right technology based on the right principles for the problem at hand.
I look at the non relational mainframe storage that sits behind the 'legacy' policy administration system at work and I can see what it has going for it, the COBOL requires no data type translation, and the ability to redefine the structure of a record based on its specific type (ie, 'car policy' vs 'farm policy') is a highly useful concept when dealing with so many variations of structure. XML would be the 'modern' equivalent. To do it in a relational database with Java would involve a lot more work and a lot less flexibility. Interestingly, from my weak understanding of Big Table, it seems to be very similar to the concepts in supra/cobol. But I'm not familiar enough with BigTable to be sure. Regarding the caching side of things, for the type of problems I've dealt with, performance issues with databases (Oracle) have been solved not with caching, but with tuning of Oracle config, indexing, queries tuning, network and then underlying hardware/storage array technology. I sometimes wonder, with some of the conversations I observe, if this kind of top to bottom tuning is overlooked in favor of Java/code based solutions in some situations? On Jul 16, 8:21 pm, Christian Catchpole <christ...@catchpole.net> 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 javaposse@googlegroups.com To unsubscribe from this group, send email to javaposse+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/javaposse?hl=en -~----------~----~----~----~------~----~------~--~---
