[prev in list] [next in list] [prev in thread] [next in thread] 

List:       sqlite-users
Subject:    Re: [sqlite] SQLite vs. Oracle (parallelized)
From:       "Jay A. Kreibich" <jay () kreibi ! ch>
Date:       2009-02-26 15:53:18
Message-ID: 20090226155318.GA17702 () uiuc ! edu
[Download RAW message or body]

On Wed, Feb 25, 2009 at 10:29:59AM -0800, Chris Wedgwood scratched on the wall:
> On Mon, Feb 23, 2009 at 04:28:00PM -0500, D. Richard Hipp wrote:
> 
> > Remember: SQLite is not trying to replace Oracle.  SQLite is trying
> > to replace fopen().
> 
> Exactly.  SQLite is *wonderful* for this, and I would hate to see it
> compromised by adding features that really aren't necessary.

> I'm very happy with how small, compact, and blisteringly fast, SQLite
> is for a whole range of uses, I don't want it bloated down to make it
> something it's not.

  I agree.  The only major addition I'd like to see is full support for
  referential integrity.  I know you can fake it, to a degree, with
  triggers, but I'd still like to see it baked into the database engine
  itself.

> Oh, except right joins.  If you add those I won't mind :-)

  I've always wondered about this... someone please correct me if I'm
  wrong, but my understanding is that there wasn't any difference
  between a left and right join except for the argument order.  It
  seems like implementing right joins should be pretty easy by just
  having the parser reverse the arguments when it builds the parse
  tree.  I realize that might screw with the optimizer a bit, but is
  there anything obvious I'm missing?

   -j

-- 
Jay A. Kreibich < J A Y  @  K R E I B I.C H >

"Our opponent is an alien starship packed with atomic bombs.  We have
 a protractor."   "I'll go home and see if I can scrounge up a ruler
 and a piece of string."  --from Anathem by Neal Stephenson
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
[prev in list] [next in list] [prev in thread] [next in thread]