<table cellspacing="0" cellpadding="0" border="0" ><tr><td valign="top" style="font: inherit;">A different reason to prefer SQL. . A decade ago c and c++ compiler vendors got a shock when they discovered that many customers rated ' specification compliance ' above things like ' bug free ' . They hadn't even included the former in their customer surveys . People strongly prefer that their code etc. will work with the environment of the future and the current pay rate of COBOL. - ers reflects this . I'd like to see similar respect for the users of a certain desktop environment . - Bruce<br><br>--- On <b>Thu, 11/12/09, conspire-request@linuxmafia.com <i><conspire-request@linuxmafia.com></i></b> wrote:<br><blockquote style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; padding-left: 5px;"><br>From: conspire-request@linuxmafia.com <conspire-request@linuxmafia.com><br>Subject: conspire Digest, Vol 77, Issue 19<br>To:
conspire@linuxmafia.com<br>Date: Thursday, November 12, 2009, 12:00 PM<br><br><div class="plainMail">Send conspire mailing list submissions to<br> <a ymailto="mailto:conspire@linuxmafia.com" href="/mc/compose?to=conspire@linuxmafia.com">conspire@linuxmafia.com</a><br><br>To subscribe or unsubscribe via the World Wide Web, visit<br> <a href="http://linuxmafia.com/mailman/listinfo/conspire" target="_blank">http://linuxmafia.com/mailman/listinfo/conspire</a><br>or, via email, send a message with subject or body 'help' to<br> <a ymailto="mailto:conspire-request@linuxmafia.com" href="/mc/compose?to=conspire-request@linuxmafia.com">conspire-request@linuxmafia.com</a><br><br>You can reach the person managing the list at<br> <a ymailto="mailto:conspire-owner@linuxmafia.com" href="/mc/compose?to=conspire-owner@linuxmafia.com">conspire-owner@linuxmafia.com</a><br><br>When replying, please
edit your Subject line so it is more specific<br>than "Re: Contents of conspire digest..."<br><br><br>Today's Topics:<br><br> 1. Re: Wednesday the 18th in Fremont at 7 pm. (Carl Myers)<br><br><br>----------------------------------------------------------------------<br><br>Message: 1<br>Date: Thu, 12 Nov 2009 11:22:32 -0800<br>From: Carl Myers <<a ymailto="mailto:cmyers@cmyers.org" href="/mc/compose?to=cmyers@cmyers.org">cmyers@cmyers.org</a>><br>Subject: Re: [conspire] Wednesday the 18th in Fremont at 7 pm.<br>To: bruce coston <<a ymailto="mailto:jane_ikari@yahoo.com" href="/mc/compose?to=jane_ikari@yahoo.com">jane_ikari@yahoo.com</a>><br>Cc: <a ymailto="mailto:conspire@linuxmafia.com" href="/mc/compose?to=conspire@linuxmafia.com">conspire@linuxmafia.com</a><br>Message-ID: <<a ymailto="mailto:20091112192232.GP7018@cmyers.org"
href="/mc/compose?to=20091112192232.GP7018@cmyers.org">20091112192232.GP7018@cmyers.org</a>><br>Content-Type: text/plain; charset="us-ascii"<br><br>This sounds really interesting and I would love to go, but I can't due to prior<br>arrangements.<br><br>One thing the summary doesn't hit on that interests me is I think there are lots<br>of reasons to use a SQL database besides the often-cited "data set size",<br>"scalability", and "performance" reasons.<br><br>In my experience (and I have had a lot of experience with berkeleydb, some with<br>sleepycat, and a lot with hsql, an in-memory, but sql-based DB) one huge problem<br>is compatibility over time.<br><br>We had a system which used berkeleydb which was stuck on 6-year-old code because<br>the APIs and libraries changed, and we couldn't upgrade. SQL databases provide<br>a clean, abstracted API such that it is (relatively) easier to swap out the<br>underlying implementation than it is for
many alternate solutions. One could<br>argue this is as much a symptom of poor system design as it is poor choice of<br>backend - and I agree - but in my experience, when you take the time to use a<br>SQL backend, you tend to use proven libraries like java's JDBC or Perl's DBI,<br>and it makes upgrades and backend changes a lot simpler. This makes products<br>based on these technologies more robust and easier to maintain. Maintenance is<br>more than just fiddling with database permissions, after all, it is also keeping<br>your software building against modern, bug-fixed, security-patched software.<br><br>Anyways, if someone does go I'd love to hear a summary of some of the<br>take-homes.<br><br>Thanks!<br>-Carl<br><br>On Wed, Nov 11, 2009 at 01:14:13PM -0800, bruce coston wrote:<br>> Date: Wed, 11 Nov 2009 13:14:13 -0800 (PST)<br>> From: bruce coston <<a ymailto="mailto:jane_ikari@yahoo.com"
href="/mc/compose?to=jane_ikari@yahoo.com">jane_ikari@yahoo.com</a>><br>> To: <a ymailto="mailto:conspire@linuxmafia.com" href="/mc/compose?to=conspire@linuxmafia.com">conspire@linuxmafia.com</a><br>> Subject: [conspire] Wednesday the 18th in Fremont at 7 pm.<br>> <br>> Normally I don't post around but this talk may have extra appeal so I'm <br>> re-posting it here . Permission granted to repost to appropriate places . <br>> - Bruce aka. Kilgore... <br>>
<br>> SQL isn't everything <br>> by Jesus Monroy <br>> <br>> Today there is a push for SQL-based solutions, such as Oracle, DB2 or <br>> Mysql.
While these solutions are excellent for certain classes of <br>> problems, they don't work well for many things. Many issues arise <br>> including: scaling, performance and development cost. <br>> <br>> For most applications today, people struggle with managing the database, <br>> security and performance. For many, their "data sets" are small enough, or <br>> infrequent enough, that a simple flat file will not only suffice,
but <br>> excel. In addition, benchmarks of yesteryear (of 3-4 thousand records) <br>> being the crossover point for a full blown database are outdated. <br>> <br>> In this talk we will discuss other solutions, starting with the power of <br>> basic flat files and flat memory arrays. Then an extended discussion on <br>> Berkeley DB, sleepycat dbm, local and network-distributed hash tables and <br>> other systems that can scale in size and performance to Google
levels. <br><br>> _______________________________________________<br>> conspire mailing list<br>> <a ymailto="mailto:conspire@linuxmafia.com" href="/mc/compose?to=conspire@linuxmafia.com">conspire@linuxmafia.com</a><br>> <a href="http://linuxmafia.com/mailman/listinfo/conspire" target="_blank">http://linuxmafia.com/mailman/listinfo/conspire</a><br><br><br>-- <br>Carl Myers <br>PGP Key ID 3537595B<br>PGP Key fingerprint 9365 0FAF 721B 992A 0A20 1E0D C795 2955 3537 595B<br><br>-------------- next part --------------<br>A non-text attachment was scrubbed...<br>Name: not available<br>Type: application/pgp-signature<br>Size: 197 bytes<br>Desc: Digital signature<br>URL: <<a href="http://linuxmafia.com/pipermail/conspire/attachments/20091112/dee31760/attachment-0001.pgp"
target="_blank">http://linuxmafia.com/pipermail/conspire/attachments/20091112/dee31760/attachment-0001.pgp</a>><br><br>------------------------------<br><br>_______________________________________________<br>conspire mailing list<br><a ymailto="mailto:conspire@linuxmafia.com" href="/mc/compose?to=conspire@linuxmafia.com">conspire@linuxmafia.com</a><br><a href="http://linuxmafia.com/mailman/listinfo/conspire" target="_blank">http://linuxmafia.com/mailman/listinfo/conspire</a><br><br><br>End of conspire Digest, Vol 77, Issue 19<br>****************************************<br></div></blockquote></td></tr></table><br>