I think you might be overlooking how revolutionary SQL/Relational storage is compared to what came before it.
I mean, if I want sum all the fee's received between two dates on the mainframe, I'm cracking open COBOL editor and doing a lot of boiler plate to read records, compare the dates, store the result so far. One line of SQL does the same thing, and a hell of a lot faster too. But yeah, its like XML, the industry seizes on an idea, and then all of a sudden, its the solution to all man's (and woman's) ills. Thus all the enthusiasm for BigTable etc should be tempered with the fact it still only an appropriate choice for a given set of circumstances. Of course, I'm not sure what they are yet, I don't know enough :) On Jul 16, 8:59 pm, Christian Catchpole <christ...@catchpole.net> wrote: > I'm not disagreeing with what you are saying. If I was start a new > project odds are I would choose an SQL database because of the > ecosystem around it. I am more so questioning how the SQL ecosystem > has evolved as the only serious choice for persistence. As I think > mentioned in a recent podcast, choosing anything else and everyone > will think you are mad. But you only have to google for multiple > projects and products which try to offer alternatives to relational > SQL. But I guess none of these ever gain any real traction because it > all seems so risky to trust any of them with your most valuable > asset.. your data. Especially if they don't support Crystal Reports. > > On Jul 16, 8:43 pm, Steven Herod <steven.he...@gmail.com> wrote: > > > > > 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 -~----------~----~----~----~------~----~------~--~---
