[Tutor] suitability to task
Sean 'Shaleh' Perry
shalehperry@attbi.com
Wed, 21 Aug 2002 10:21:35 -0700
On Tuesday 20 August 2002 05:55 pm, Darren Reynolds wrote:
> just doing some planning work on a project i'm going to be doing for
> myself, and was wondering if ppl might be able to tell me if python (or
> another language) would be better suited for it. i'm also not decided
> yet on what form the data storage is going to take place. the program
> isn't going to be very complex (mp3 database / indexing), and is going
> to run in the console as opposed to graphical interface. in essence it=
s
> operation will be this ...
>
easily accomplished in python (-;
> -- will do an 'ls -R /cdrom' (or some other command that will give me
> recirsive listing of all files and directories on the cd) and re-direct
> output to a temporary flat-text file
import os.path and look into os.path.walk.
> -- will name the text file based on user input
> -- once disc has been read, text file will be processed to read the
> following information; artist, album, year pf release, # of tracks per
> album, track names, format, disc "name" (as entered by user ... as all
> the cds will have consistent layout, program shouldn't have a problem
> picking these pieces out or knowing when new album listing has started)
> -- take this information and place it into data storage (both flat-text
> file storage and mysql have been suggested by friends of mine)
a db of sort sort (sql or not) is probably a good idea, more on this in a=
=20
moment.
> -- remove the temporary text file once data has been successfully
> committed to storage
> -- will also have options for user to search indexed cds by; artist.
> album, track name
this would be aided by a db backend, most of the hard work would be done =
for=20
you.
> -- will pipe search results to screen (through pager such as less) and
> indicate to user all criteria matches and which cds the tracks / albums
> can be found (the user entered "name" for each cd will be used as the
> indicator as to track location)
>
> so, if anyone has any in advance "caveats" for me to look out for, or
> could make any suggestions about data storage ... i'm all "ears" ... :)
>
A sql db has some pros and cons:
cons --
* Must be running to use it. This means you lose some cpu and memory. N=
ot=20
bad if you use the db for other projects or if it is on another machine.
* Must maintain the db.
* Must learn about dbs.
pros --
* they have solved the storage and efficiencies problems
* can output the data to multiple programs / views
* flat text can be implemented via the db and even by a separate app
* flexibility in general
There are other db style approaches that may not require an actual runnin=
g db=20
server.