Re: [tlug] Simple database application recommendation?

["Guillaume Proux" <gproux@example.com>]

Hello Shannon,

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