This may be a dumb question and it is not necessarily about Lisp, but
being that this is generally the most intelligent community I know of, I
thought I'd ask here.
I'm considering writing a web application in Common Lisp. The basic
idea is to be a virtual distributor or broker. Have no physical
inventory, but process purchasing transactions on behalf of others.
Still investigating the business opportunity and it is far from clear
that this will be built.
Today, in the developer community at large, I'd expect a vast majority
of such web applications to be built using some web scripting language
(PHP, JSP, ASP, Perl, etc) talking to a relational database on the
backend (Oracle, MySQL). (More complex apps might also include some
J2EE stuff or whatever, but that isn't what I'm wondering about now.)
Since I'd already be in the minority by choosing to build this app in
Common Lisp, I started to wonder if I should also rethink the dependence
on using a relational database to persistently store the record of
transactions. Does anyone have successful experience or interesting
opinions that go against the common wisdom of using an RDBMS (and I'm
much more thinking Oracle than MySQL because I want all the ACID
properties)?
Thank you,
-Jason
·····@au-bon-pain.lcs.mit.edu (Jason S. Cornez) writes:
> Since I'd already be in the minority by choosing to build this app in
> Common Lisp,
You'd still have a decent community of others doing the same thing to
communicate with. Check out the lispweb list at
http://www.red-bean.com/lispweb
> I started to wonder if I should also rethink the dependence on using
> a relational database to persistently store the record of
> transactions.
For such an important record, I think that a database is definitely
the way to go. Whether being relational is good or bad depends on what
exactly the data is like.
> Does anyone have successful experience or interesting
> opinions that go against the common wisdom of using an RDBMS (and I'm
> much more thinking Oracle than MySQL because I want all the ACID
> properties)?
If the data is such that you don't have many object references within
objects and objects are fixed-sized structures of fixed-sized
structures, then an RDBMS is the way to go. Otherwise, you might want
to consider an OODBMS like Plob! or AllegroStore, etc.
I can't think of too much variability in the sizes of the data you'll
be dealing with for business transactions, so an RDBMS probably won't
be a bad choice.
--
-> -/- - Rahul Jain - -\- <-
-> -\- http://linux.rice.edu/~rahul -=- ············@techie.com -/- <-
-> -/- "I never could get the hang of Thursdays." - HHGTTG by DNA -\- <-
|--|--------|--------------|----|-------------|------|---------|-----|-|
Version 11.423.999.221020101.23.50110101.042
(c)1996-2002, All rights reserved. Disclaimer available upon request.
Rahul Jain <·····@sid-1129.sid.rice.edu> wrote:
> ·····@au-bon-pain.lcs.mit.edu (Jason S. Cornez) writes:
>> Does anyone have successful experience or interesting
>> opinions that go against the common wisdom of using an RDBMS (and I'm
>> much more thinking Oracle than MySQL because I want all the ACID
>> properties)?
>
> If the data is such that you don't have many object references within
> objects and objects are fixed-sized structures of fixed-sized
> structures, then an RDBMS is the way to go. Otherwise, you might want
> to consider an OODBMS like Plob! or AllegroStore, etc.
>
> I can't think of too much variability in the sizes of the data you'll
> be dealing with for business transactions, so an RDBMS probably won't
> be a bad choice.
Berkeley-DB offers the "crunchy goodness" of transactions, but allows
you to keep the participation of the database down to being
responsible for storing Plain Raw Payload.
There's a nice macro set for CMU/CL to access this.
Another thought, and it's "a thought" as opposed to "fully thought
out," would be that if the amount of data is small enough that it fits
in memory, what might be reasonable to do would be to load the whole
DB into memory, access it _from memory_, and basically have "triggers"
(before and after methods?) that write all updates out to logs on
disk.
There are commercial DBMSes doing that (Cach\'e, TimesTen, a "libre"
C++ one called FastDB), and they win something in performance,
assuming that's valuable...
--
(reverse (concatenate 'string ···········@" "enworbbc"))
http://www.ntlug.org/~cbbrowne/commonlisp.html
"Who is General Failure and why is he reading my hard disk?"
-- <·······@inf.fu-berlin.de>, Felix von Leitner
In article <···············@au-bon-pain.lcs.mit.edu>, Jason S. Cornez wrote:
> I'm considering writing a web application in Common Lisp.
<snip>
> Since I'd already be in the minority by choosing to build this app in Common
> Lisp, I started to wonder if I should also rethink the dependence on using a
> relational database to persistently store the record of transactions. Does
> anyone have successful experience or interesting opinions that go against
> the common wisdom of using an RDBMS (and I'm much more thinking Oracle than
> MySQL because I want all the ACID properties)?
Paul Graham's "Beating the Averages" & "Lisp for web-based applications" may
prove interesting, though not specifically about RDBMSs. (Actually, not even
generally about RDBMSs, but some interesting design ideas, esp. to someone
like me who's new to Lisp.) See http://www.paulgraham.com/articles.html.
-- Larry