[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: ADV: [Gnump3d-devel] Database backend
From: |
Steve Kemp |
Subject: |
Re: ADV: [Gnump3d-devel] Database backend |
Date: |
Sun, 5 Dec 2004 14:30:10 +0000 |
User-agent: |
Mutt/1.3.28i |
On Sun, Nov 28, 2004 at 10:14:16PM +0100, Martin Lohmeier wrote:
> I'm using gnump3d for years and my collection of music has grown up to ~550
> songs.
550 songs doesn't seem like too large a collection.
> Unfortunatelly I noticed that it takes a lot of time to open the
> webinterface [1]. So I think the parsing ot the cache file takes so long,
> does it? How complex would it be to use a Database (mysql?) to store the
> information in? And would it speed things up?
It's not the cache file parsing which is taking the time, it's the
creation of the cache file. This is treated as a pseudo database.
I've been in two minds about a real database, but mostly I'm against
it.
Pros
----
* The tag file lookup is fast.
* Searching, sorting, and randomisation are trivial.
Cons
----
* The database must be updated every time new media is added.
* Setup instructions are going to widely vary, depending on the
database used.
* Suddenly we lose the ability to run on lower-end machines and
likely Windows machines.
* We have to lookup songs twice[1]
* The dependencies required to run the software increase.
[1] The song lookup issue is probably the blocker for me. If we
assume that when the server is installed a find for media is made
which enteres all the song details into a database, then it seems
"nice" to just select all the songs from there instead of from the
filesystem. This is fast, reliable, and simple to do.
However it breaks down the moment the database copy of information
goes out of sync with the filesystem.
My solution would be to scan the filesystem for songs, then use
the database for just getting the tag information. This is essentially
what happens with the cache file at the moment.
If I were to write the code again I'd insist that the database
contents were current, and then use that exclusively. However I
suspect that the majority of users wouldn't like it.
Perl modules could do most of the hard work:
Class:DBI - Database lookups.
HTML::Template - For the output pages.
(NEVER Again would I attempt to create my own templating system.
Still a nice lesson learned :)
Steve
--
- Re: ADV: [Gnump3d-devel] Database backend,
Steve Kemp <=