Re: [tlug] Simple database application recommendation?

["Shannon Jacobs" <shannon.jacobs@example.com>]

> Date: Sat, 27 Jan 2007 12:35:38 +0900
> From: "Guillaume Proux" <gproux@example.com>

Thanks for the broad reply.

I actually did quite a number of conversions when taking it to the Palm. (On 
the Perl side, my backend basically slurps it up without any problem.) Most 
of the targets were in the native Palm DB format, though I also experimented 
with at least one of the more proprietary DBs. I remember that sometimes I 
piped it through Excel, which actually has a rather nice import utility. 
Perlers, please cover your eyes for the next sentence or two. Sometimes I 
used regular expressions to do conversions, but I find it easiest to do them 
in JavaScript (especially for exclusions). Heaven forbid, but at one point 
(at least) I was using Microsoft's regular expressions, both in Word and 
Excel. What they call regexps in Word is not even close, but the extended 
implementation within Excel wasn't totally awful. Just rather. (Of course 
Microsoft has to do everything their own friggin' way.) I feel I'm not too 
bad at massaging data into new forms. I hope I'm not overconfident, but I 
feel like I can handle the import side of the problem. However the real 
problem was that I didn't have any clear target for the new application...

As far as a "database schema" goes, I'd tend to describe it in RDB terms, 
because that's my own background. (However, I am not averse to learning new 
approaches, depending on the benefit and simplicity.) Basically two tables 
(a limit of dBase II) that should be expanded to at least three. There are 
two 1-3 mappings involved, but the ugly way, with repeated fields that are 
cross-referenced and verified in input validation routines. The output and 
report functions are both native and programmed. The new Perl/CGI query 
backend is completely programmed and targets HTML output only, but also 
includes some query extensions beyond the dBase version. I'd prefer to use a 
more dynamic input validation system, though the current programs basically 
try to enforce author uniqueness where possible.

I'll have to investigate DABA and BOND to see how they work... Can you 
benchmark them to dBase II? Not likely unless you're an old-timer, but dBase 
II had a number of really convenient features... I didn't do that much work 
with dBase III or later versions, since I was mostly shifted into other DBs 
or DB-related tools in those later days, and usually working on 
minicomputers or mainframes. I guess it's just that none of the more 
'advanced' tools really gripped me the way dBase II did, and there were also 
portability concerns, so I just left this particular application in dBase. 
Now it's getting increasingly orphaned as it becomes harder and harder to 
run DOS apps. (No, I wasn't able to get it to run under Linux...)

I'm less optimistic about your the pyboiographer. I've investigated a lot of 
such systems over the years, and it seems like everyone approaches the 
problem somewhat differently, and all of them hard-code certain aspects of 
the problem. Me, too, but of course my solutions are the best possible.  ;-) 
Seriously, I'd like to find a superset application that would let me have my 
cake (of functions) and eat it (as new functions), too, but I'm not 
optimistic.

> On 1/27/07, Shannon Jacobs <shannon.jacobs@example.com> wrote:
> > way it links to the second table (of authors) is especially
> > humiliating, but the original address list was in a single table.
> >
> > (I actually converted it to a Palm DB some years ago, but that
> > experiment was quite painful and tedious and the resulting
> > performance was unacceptable, so that's a good example of the kind
> > of approach I want to avoid.)
>
> You don't say much on how you "converted" your data around but maybe
> you could make a big step forward by doing a analysis of your data
> before thinking of any tool.
>
> You probably should put your database schema on paper and take a
> couple of example in your database and see how they would fit a
> "better" schema.
>
> When you have done that, write a little script in your language of
> choice that given the output of your old database can create the new
> output for a new database. depending on its size, you could do SQLite,
> MySQL, Postgres or simply in-memory structures for Python (you can
> pickle) etc.
>
> Then the third step, it to decide what kind of front-end you want.
> Nowadays, you got to do a web front-end. Rails or Turbogears or Django
> are some possible answers.
>
> If you want a  desktop application, the application Glom is very nice.
>
> There are also a couple of desktop oriented solutions for database
> apps:
> - DABO: http://dabodev.com/screenshots
> - BOND: http://www.treshna.com/bond/screen_shots/
> etc...
>
> You can also find a number of applications that might do ALREADY what
> you want such as:
> - PyBliographer
> http://pybliographer.org/Documentation/Screenshots
>
> The challenge is then to export your data to the format expected by
> these tools.
>
> Regards,
>
> Guillaume Proux
> Scala