[conspire] A different reason to prefer SQL. .
Ruben Safir
ruben at mrbrklyn.com
Fri Nov 13 16:53:52 PST 2009
Deirdre Saoirse Moen wrote:
> 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
>
>
Ah - I can remember the early days of my programming career with Foxpro
and Paradox...after spending months learning Oracle's C API.
Ruben
> 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
>>
>>
>
> _______________________________________________
> conspire mailing list
> conspire at linuxmafia.com
> http://linuxmafia.com/mailman/listinfo/conspire
>
>
More information about the conspire
mailing list