toadi has asked for the wisdom of the Perl Monks concerning the following question:

well,
in light of Protocols, SQL, hardware, anyone? from BBQ I've got a Mysql question.

I'm stuck on a problem.
I'v got a picture database with some info on the picture.I made a HTML::Template file with a form where you can put the info in from the picture. This forms has "action=write_to_db.cgi" which writes the info to the database. All nice, but people need also have the opportunity to upload this foto and the path should be in the database so I can display it with the info afterwards.

Some suggestions on the problem???
I tried several things... Got still some ideas in my head, but I thought why not ask it in PM

Replies are listed 'Best First'.
Re: Mysql & perl
by ar0n (Priest) on Jul 14, 2000 at 22:28 UTC
    Though somewhat confused, like btrott, I think what you're
    asking is how to handle a file-upload in Perl.
    See this node, for an explanation on how to do this.

    You could save the picture itself in a MySQL table as a BLOB.
    An IMHO better idea would be to save the picture with a random key for a filename
    in some directory. Perhaps an MD5::Digest of the picture could be
    used as the filename to avoid having duplicates.


    -- ar0n
[reply]
Re: Mysql & perl
by btrott (Parson) on Jul 14, 2000 at 22:09 UTC
    I'm not sure really what the problem is, actually. You seem to have a good idea of how to write this program.

    I'd use the database as a repository of meta-information about the picture; in other words, I wouldn't actually store the picture data in the database, even though it *would* be possible. I'd store the actual picture file in the filesystem (somewhere in some protected directory, probably), then store the path to that file in the database. Which is exactly what you seem to be saying yourself.

    For the file upload, I'd use either CGI or Apache::Request, the latter if you're using mod_perl. And I'd use DBI to communicate with the database.

    Does this help? Were you looking for suggestions other than what you wrote, or more for confirmation that your idea made sense?

[reply]
      Why would your preference be to not store the image in the database? It has the advantage of being implicitly backed up when a backup is run on the database file system. It also eliminates the need for unique file names, and gives you the access control facilties provided by the database itself.

      Typically, my *personal* preference would be to store the image in the database. And disk space is disk space, no matter where you put the image.

      I wonder if this is one of those religious war things, possibly?

      --Chris

      e-mail jcwren
[reply]
        You wrote: > I wonder if this is one of those religious war > things, possibly? Well, possibly--but if so, I'm not one of the participants, I don't think. It's really just a personal preference rather than a religious thing. :)

        The big reason I'd rather store binary content in the filesystem is that the facilities for dealing with BLOBs are very ugly in certain databases. (Admittedly, this isn't really the case in MySQL.) But still, I just like keeping the data separate, because when inserting/updating/selecting records, I think it keeps things simpler.

        But there are probably reasons both way, and your points are well taken.

[reply]
      To be fair, one problem I have with not storing the data in a database is the issue of maintainability. Imagine if you only have one script, one database, and one path for the images. That's three pieces to the puzzle instead of two. The more you toss in, the more difficult the system is to maintain when you come back to it later. If you are creating a document management system, you'd probably have many scripts and tables. Adding many paths to store documents in is just adding to the complexity (IMHO).

      Cheers,
      Ovid

[reply]
        OTOH, putting the images into the database means that if you have to move the stuff around, there is a lot less to move. Also, if you are going to put the data on a different network node than the script, having everything in the database reduces the logical complexity. 
        Paris Sinclair    |    4a75737420416e6f74686572
pariss@efn.org    |    205065726c204861636b6572
I wear my Geek Code on my finger.
[reply]
      Actually,
      I had a real good idea of writing the program. But the problems is I didn't really thought of error-checking.

      I've got a mediadb were you've got a login.
      Then you've got a foto-table news-tablelly there are more).
      Well I use HTML::Template for the forms where you can give the input for the db. I give a hidden variable which is your loginID to put in the table so when you want to change input afterwards this checks the logonID and gives oyu permission to change your own input.

      But my problem is I don't really understand the upload-scrits... Is it possible to put a input=file in the form with the information of the pic and pass it through with a submit and a cgi that AND writes the pic to disc AND writes it pathinfo + all the other information to the foto-table????

      Why are dead-lines also so close?

      --
      My opinions may have changed,
      but not the fact that I am right

[reply]

Back to Seekers of Perl Wisdom