[conspire] A different reason to prefer SQL. .
Deirdre Saoirse Moen
deirdre at deirdre.net
Fri Nov 13 16:41:42 PST 2009
I remember the days of every database vendor having their own DB
language, and my love for SQL is thus unbounded.
I remember once asking a vendor why I couldn't join a table to itself.
Developer said, "But why would you ever want to do that?"
Failure of the imagination, that.
Deirdre
On 11/13/2009, "Carl Myers" <cmyers at cmyers.org> wrote:
>Unfortunately, I don't think that is a very strong reason to prefer SQL, at
>least not all SQL. There is certainly a subset of SQL which is widely supported
>by almost all databases, but to enforce database constraints, or to get any sort
>of scalable performance (Giving oracle suggestions for how to best execute a
>query or selecting the table backend in mysql) requires using SQL which is not
>likely to work in other platforms.
>
>Still, it is better than the alternatives I know of. It is far easier to
>rewrite the parts of your SQL which are platform specific than have to rewrite
>*everything*. Anyways, interesting stuff.
>
>-Carl
>
>On Thu, Nov 12, 2009 at 12:37:10PM -0800, bruce coston wrote:
>> Date: Thu, 12 Nov 2009 12:37:10 -0800 (PST)
>> From: bruce coston <jane_ikari at yahoo.com>
>> To: conspire at linuxmafia.com
>> Subject: [conspire] A different reason to prefer SQL. .
>>
>> 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
>> ****************************************
>
>> _______________________________________________
>> 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
>
More information about the conspire
mailing list