Slides from my OpenDBCamp keynote (Froscon track)

I just uploaded my slides from my Open DB Camp / Froscon talk to Slideshare:

As it's not obvious in the slides, the conclusion on the last slide is: "So I guess from now on I have to make a choice based on technical merits instead."

We had a good and philosophical discussion among many DB veterans so I was quite happy with how it worked out and ended up spending the full 60 minute slot instead of the planned 30 minutes. I'd like to thank Felix for inviting me - I really enjoy giving these more high level and philosophical talks every now and then.

Update: I realized I forgot to add Creative Commons deed and also credit the pictures I used from others. This is now done in the attached open office presentation.

Lars Johansson (not verified)

Mon, 2011-08-22 11:28

I have worked with databases on and off from mid70ties (mySQL since 2001). Now I'm struggling to learn NOSql databases. The weakest link i found so far is the absence of a unifying access language. We also use Lotus Notes which have a NOSql database (so I'm told). The biggest criticism against Lotus Notes at my company is 'we do not have any control over the data in there'. IT-managers before and after me have tried to document the data but failed. Now while learning about NOSql I suspect the 'schema-free' is if not the root cause one 'feature' that makes it hard to control the data in LN databases. Right now I have problems to see the benefits of NOSql. MApReduce is great but it is not unique to NOSql. I run MapReduce procedures against network databases in the early 80ties. I also implemented a mapReduce scheme against MySQL (e.g. reconstructing BOM trees from a SAP system). And if you think SQL is complicated, you should probably do something else than creating NOSql mapReduce procedures in Erlang.
But I admit the replicating features of couchDB is very interesting.

The thing that's different now compared to previous attempts at "database without SQL interface" is that we have a standard serialization format across programming languages: JSON. I think it's a contributing reason to why they are succeeding - you get the benefits of being schemaless but you can actually understand what's in there and it's accessible with any language, many clients.

Add new comment

The content of this field is kept private and will not be shown publicly. Cookie & Privacy Policy
  • No HTML tags allowed.
  • External and mailto links in content links have an icon.
  • Lines and paragraphs break automatically.
  • Web page addresses and email addresses turn into links automatically.
  • Use [fn]...[/fn] (or <fn>...</fn>) to insert automatically numbered footnotes.
  • Each email address will be obfuscated in a human readable fashion or, if JavaScript is enabled, replaced with a spam resistent clickable link. Email addresses will get the default web form unless specified. If replacement text (a persons name) is required a webform is also required. Separate each part with the "|" pipe symbol. Replace spaces in names with "_".
About the bookAbout this siteAcademicAmazonBeginnersBooksBuildBotBusiness modelsbzrCassandraCloudcloud computingclsCommunitycommunityleadershipsummitConsistencycoodiaryCopyrightCreative CommonscssDatabasesdataminingDatastaxDevOpsDrizzleDrupalEconomyelectronEthicsEurovisionFacebookFrosconFunnyGaleraGISgithubGnomeGovernanceHandlerSocketHigh AvailabilityimpressionistimpressjsInkscapeInternetJavaScriptjsonKDEKubuntuLicensingLinuxMaidanMaker cultureMariaDBmarkdownMEAN stackMepSQLMicrosoftMobileMongoDBMontyProgramMusicMySQLMySQL ClusterNerdsNodeNoSQLodbaOpen ContentOpen SourceOpenSQLCampOracleOSConPAMPPatentsPerconaperformancePersonalPhilosophyPHPPiratesPlanetDrupalPoliticsPostgreSQLPresalespresentationsPress releasesProgrammingRed HatReplicationSeveralninesSillySkySQLSolonStartupsSunSybaseSymbiansysbenchtalksTechnicalTechnologyThe making ofTungstenTwitterUbuntuvolcanoWeb2.0WikipediaWork from HomexmlYouTube