You're getting a little confused there. XML is a document format, and databases are things that can be used to store documents (which may or may not be XML). You could keep your meta-information in the database or in the document or both.
XML is a good format for writing documents in, but you will still need some way to index and retrieve your documents. Howver since Nirvana didn't do too many songs and probably won't be doing many more, you could get away with storing all the documents in a directory (maybe each document in XML format) and then searching through them all for the one you want.
If you really want a bit of database practise (and why not), try DBI and choose a simple backing database for your index, like one of the flat text ones or Berkeley database format or similar. ____________________
Jeremy
I didn't believe in evil until I dated it. | [reply] |
IMHO an xml document is not a database. XML is used for exchanging data. You probably want to look at mySQL or PostgreSQL for
database functionality.
Having a real database will allow you to categorize all the sheets of music by genre, author, etc and allow your site's users to search or filter based on the parameters you decide to support.
You may decide to use XML for encoding the actual sheet of music while storing into the database. ie. one xml document per guitar tab. I do not know
if someone already has a standard DTD for your use, or you might have to roll your own.
You will need DBI and DBD to access the database, XML::Writer to write the XML document and XML::Parser to read it back in.
You could probably eliminate the xml piece altogether and just store the guitar tab in whatever format you use now.
| [reply] |
One thing that was not mentioned in the answers you've already had, is that once you've implemented the DBI/DBD interface, it is normally very easy to change what underlying database engine your application will use.
If you're able to avoid any database calls that are specific to a certain database and only use the 'smallest common denominator' you may be able to change the underlying database by changing one single line in your Perl code.
You will, of couse, OTOH have to install the new database engine, but that's out of scope for your Perl application. And this is exactly my point. Using DBI/DBD, and taking care not to call any 'obscure' database functionality, you may make your application almost 100% unaware of what database you're using.
Which is a Good Thing (TM used with permission).
f--k the world!!!!
/dev/world has reached maximal mount count, check forced.
| [reply] |
Good point biker.
You can actually start out using DBD::CSV which
actually uses text files and then move onto a real
database file. That would allow you to focus on
learning just the DBI/DBD part of the piece and then when
you are comfortable with it, move on to putting in
a real database.
Disclaimer: This is in theory, ie. this is how it
should work. Never tried it so am not sure if there
are any practical problems involved. Would someone
who has attempted something similar please speak up.
| [reply] |
THanx guys, its been steam ahead with mysql all week and im finally there - atlast, a proper database.
| [reply] |
THanx guys, its been full steam ahead with mysql all week and im finally there - atlast, a proper database.
| [reply] |