[CALUG] Database question
Jason C. Miller
jason.c.miller at gmail.com
Mon Aug 21 09:45:03 CDT 2006
Unfortunately, given operational constraints, SQLite is the only option.
<:(
On 8/21/06, Hugh Brown <brownclan at gmail.com> wrote:
>
>
>
> On 8/21/06, Jason C. Miller <jason.c.miller at gmail.com> wrote:
> >
> > Does anybody know of any queries or tricks to update an entire table in
> > the
> > fewest operations possible? Before anyone freaks out and starts yelling
> > UPDATE() at me, let me explain the scenario and also mention that I'm
> > hardly
> > a DB/SQL guru. I've always known just enough to get by.
> >
> > Here's the scenario...
> >
> > Table A: (users)
> >
> > id | name | location | level
> > --------------------------------------
> > 0 | nobody | nowhere | 3
> > 1 | somebody | somewhere | 2
> > 2 | anybody | anywhere | 1
> > .
> > .
> > .
> >
> > When a person makes changes to these values from my interface, they are
> > actually doing it in some structures in memory that are initially an
> > exact
> > copy of the database table. Once they are happy with their changes,
> > they
> > will run a commit() which I will later implement to go through and make
> > all
> > of the changes to the table from the changes that were made to the copy
> > in
> > memory. Normally, I would do this incrementally by writing a loop that
> > would check for insert()s, delete()s, and update()s. However, if
> > there's
> > some SQL voodoo that I could use to do some kind of a sync() between the
> >
> > virtual table and the database table, I'd much prefer that. Does
> > something
> > like this exist? I did some searching on the web but, as usual, don't
> > know
> > the EXACT words to search for as not to get bombarded with
> > 90,000,000,000
> > irrelevant results.
> >
> > Ideas?
> >
> > -jason
> >
> > P.S. I'm using SQLite
>
>
>
>
> Up until the "using SQLite," I was thinking "postgres and BEGIN
> TRANSACTION;"
>
> With transaction support, you do your changes and if something is borked
> then postgres complains and the transaction fails. You then run
> "ROLLBACK;" and the changes are removed. If everything goes well, you run
> "COMMIT;" and the changes are made.
>
> With SQLite, I think you are talking about writing transaction support.
> I'm not a DBA guru either, but I think maybe it's time to move up to a
> heavier weight db engine.
>
> Hugh
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://calug.com/pipermail/lug/attachments/20060821/58740c9b/attachment.html
More information about the lug
mailing list