[conspire] A different reason to prefer SQL. .
bruce coston
jane_ikari at yahoo.com
Thu Nov 12 12:37:10 PST 2009
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
--- On Thu, 11/12/09, conspire-request at linuxmafia.com <conspire-request at linuxmafia.com> wrote:
From: conspire-request at linuxmafia.com <conspire-request at linuxmafia.com>
Subject: conspire Digest, Vol 77, Issue 19
To: conspire at linuxmafia.com
Date: Thursday, November 12, 2009, 12:00 PM
Send conspire mailing list submissions to
conspire at linuxmafia.com
To subscribe or unsubscribe via the World Wide Web, visit
http://linuxmafia.com/mailman/listinfo/conspire
or, via email, send a message with subject or body 'help' to
conspire-request at linuxmafia.com
You can reach the person managing the list at
conspire-owner at linuxmafia.com
When replying, please edit your Subject line so it is more specific
than "Re: Contents of conspire digest..."
Today's Topics:
1. Re: Wednesday the 18th in Fremont at 7 pm. (Carl Myers)
----------------------------------------------------------------------
Message: 1
Date: Thu, 12 Nov 2009 11:22:32 -0800
From: Carl Myers <cmyers at cmyers.org>
Subject: Re: [conspire] Wednesday the 18th in Fremont at 7 pm.
To: bruce coston <jane_ikari at yahoo.com>
Cc: conspire at linuxmafia.com
Message-ID: <20091112192232.GP7018 at cmyers.org>
Content-Type: text/plain; charset="us-ascii"
This sounds really interesting and I would love to go, but I can't due to prior
arrangements.
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
take-homes.
Thanks!
-Carl
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
> http://linuxmafia.com/mailman/listinfo/conspire
--
Carl Myers
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...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
URL: <http://linuxmafia.com/pipermail/conspire/attachments/20091112/dee31760/attachment-0001.pgp>
------------------------------
_______________________________________________
conspire mailing list
conspire at linuxmafia.com
http://linuxmafia.com/mailman/listinfo/conspire
End of conspire Digest, Vol 77, Issue 19
****************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://linuxmafia.com/pipermail/conspire/attachments/20091112/d2f09a0d/attachment.html>
More information about the conspire
mailing list