Charles Hartman wrote
People here have convinced me not to write a whole relational
database manager from scratch (that didn't take much). As far as I
can tell, if I want to do this open-source (except for Dreamcard),
that makes my choices either
MySQL with Dreamcard
or
SQLite with Python
because those seem to be the available combinations. Am I wrong? I'd
rather know what the choices are before I make one and start thinking
about plunging in and learning a new system.
I'd say you have too many choices (don't worry about the numbering
scheme :-) :
-1. (Dick's suggestion) Dreamcard
Do everything in Dreamcard until the first prototype is done.
0. Dreamcard plus any SQL (i.e. any of the following suggestions - it
doesn't matter).
Once you have a working prototype in any of the SQL variants, it will be
relatively easy to switch to any other one.
1. DC + MySQL on your ISP.
Many web hosting ISPs throw in a MySQL database or two included in the
price - so if you are on broadband and connected to the Internet 96% or
more of the time, this is a very attractive choice. The ISP does any set
up and looking after MySQL for you: two things to be careful of are
whether, when etc. backups are done, and the possibility that in the
future you'll want to use it in other circumstances (e.g. while
travelling) when the Internet access becomes an issue.
2. DC + some SQL on your own machine.
(either MySQL or PostgreSQL - PostgreSQL is (reportedly) easier to
configure - but I've done both on Windows and they were both easy - and
I've done them precisely once each - and written one simple test program
for each - I am *not* an SQL expert).
Once the installation is done, there should be little or no further work
to do to maintain it. Everything is in one place for easy backups, etc.,
can work anywhere your machine is, etc.
3. DC + altSqlite
Except for the price. Maybe the altuit folks would consider hobbyist
pricing ? Doesn't hurt to ask them.
[e.g. special price for a single user, single person, no distribution
rights (i.e. cannot distribute, far less sell, apps which use it -
except as a stack which allows other altSQLite licensees to use it), .... ]
[NB - I'd use Trevor's libDatabase along with either 1, 2 or 3 - looks
really nice, esp. for someone who isn't an SQL expert. And it does work
with PostgreSQL, even thought there are a few places where it only
mentions MySQL.]
4. DC + TCP + Python + sqlite
Certainly doable, but probably not the best choice unless you see an
advantage in making a web service out of it. TCP (or maybe HTTP) doing
basically a "remote SQL" for you,
4a. DC + HTTP + Python + sqlite
Same as above, but with a different design and idea for the protocol
interface. The HTTP interface would be similar to a standard CGI
interface rather than a "SQL interface".
5. Python + sqlite
I'd consider doing a very simple UI version which uses the same
Python+SQLite code as 4 to ease the development and testing of that
part. Then decide whether to live with a weaker UI, or go on to develop
the web service interface and the DC UI that you originally wanted.
Too many choices .....
I've been meaning to write a real SQL app some day, so you've triggered
me into trying it. I'm trying a combination of 2 and 5, partly to get a
better idea of how "portable" SQL should be between PostgreSQL and SQLite.
--
Alex Tweedly http://www.tweedly.net
--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.344 / Virus Database: 267.11.6/111 - Release Date: 23/09/2005
_______________________________________________
use-revolution mailing list
[email protected]
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
