data-design question

[Alex Tweedly]

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