--As of March 14, 2010 9:19:30 AM -0500, Didier Gasser-Morlay is alleged to
have said:
> I am starting to write a new application where I'll need a fairly light
> local database engine when the user is travelling but with the ability to
> connect to a central db server once back in the office. The central
> server will be PostgreSQL, but I have got questions about the local
> server. I would love it to be PostgreSQL, which would simplify a lot of
> things as although the volume of the local database will be fairly small:
> a few hundreds or records on a maximum of 20 tables, but the queries
> might be complex and the benefit of stored procedures if of great value
> to me.
>
>
> My constraints are:
> 1- I won't be with the users for the setup
> 2- Ideally I'd like a one-step setup (db and my app), or at least with
> no questions asked (fully automated setup)
> 3- the users will be running on Windows and possibly on Mac within 18
> months
--As for the rest, it is mine.
I'd say to take a look at SQLite for this, actually. PostgreSQL is
definitely better for the central server, but for very light-duty database
work and ease of install SQLite is probably a better choice.
It's fairly feature-complete, and SQL compliant. One thing it does _not_
have however is stored procedures.
You can use PostgreSQL for it, but it will take more work to get the setup
working seamlessly. SQLite will be easy to make seamless there, at the
cost of possibly a bit more work on the backend.
Daniel T. Staal
---------------------------------------------------------------
This email copyright the author. Unless otherwise noted, you
are expressly allowed to retransmit, quote, or otherwise use
the contents for non-commercial purposes. This copyright will
expire 5 years after the author's death, or in 30 years,
whichever is longer, unless such a period is in excess of
local copyright law.
---------------------------------------------------------------