[conspire] Wednesday the 18th in Fremont at 7 pm.
cmyers at cmyers.org
Thu Nov 12 11:22:32 PST 2009
This sounds really interesting and I would love to go, but I can't due to prior
One thing the summary doesn't hit on that interests me is I think there are lots
of reasons to use a SQL database besides the often-cited "data set size",
"scalability", and "performance" reasons.
In my experience (and I have had a lot of experience with berkeleydb, some with
sleepycat, and a lot with hsql, an in-memory, but sql-based DB) one huge problem
is compatibility over time.
We had a system which used berkeleydb which was stuck on 6-year-old code because
the APIs and libraries changed, and we couldn't upgrade. SQL databases provide
a clean, abstracted API such that it is (relatively) easier to swap out the
underlying implementation than it is for many alternate solutions. One could
argue this is as much a symptom of poor system design as it is poor choice of
backend - and I agree - but in my experience, when you take the time to use a
SQL backend, you tend to use proven libraries like java's JDBC or Perl's DBI,
and it makes upgrades and backend changes a lot simpler. This makes products
based on these technologies more robust and easier to maintain. Maintenance is
more than just fiddling with database permissions, after all, it is also keeping
your software building against modern, bug-fixed, security-patched software.
Anyways, if someone does go I'd love to hear a summary of some of the
On Wed, Nov 11, 2009 at 01:14:13PM -0800, bruce coston wrote:
> Date: Wed, 11 Nov 2009 13:14:13 -0800 (PST)
> From: bruce coston <jane_ikari at yahoo.com>
> To: conspire at linuxmafia.com
> Subject: [conspire] Wednesday the 18th in Fremont at 7 pm.
> Normally I don't post around but this talk may have extra appeal so I'm
> re-posting it here . Permission granted to repost to appropriate places .
> - Bruce aka. Kilgore...
> SQL isn't everything
> by Jesus Monroy
> Today there is a push for SQL-based solutions, such as Oracle, DB2 or
> Mysql. While these solutions are excellent for certain classes of
> problems, they don't work well for many things. Many issues arise
> including: scaling, performance and development cost.
> For most applications today, people struggle with managing the database,
> security and performance. For many, their "data sets" are small enough, or
> infrequent enough, that a simple flat file will not only suffice, but
> excel. In addition, benchmarks of yesteryear (of 3-4 thousand records)
> being the crossover point for a full blown database are outdated.
> In this talk we will discuss other solutions, starting with the power of
> basic flat files and flat memory arrays. Then an extended discussion on
> Berkeley DB, sleepycat dbm, local and network-distributed hash tables and
> other systems that can scale in size and performance to Google levels.
> conspire mailing list
> conspire at linuxmafia.com
PGP Key ID 3537595B
PGP Key fingerprint 9365 0FAF 721B 992A 0A20 1E0D C795 2955 3537 595B
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 197 bytes
Desc: Digital signature
More information about the conspire