|
|
Posted by eholz1 on 12/25/06 20:48
ewholz wrote:
Thanks Nick, I will give this a try. I like it, and it is much easier
than loading the binary image data in the db. (although loading binary
images was educational and fun!!!)
Thanks,
ewholz
!
Nick DeNardis wrote:
> eholz1,
> What I mean by the "mod 30" hash folder is basically what I did was
> setup 30 folders numbered (0-29) inside a directory. Then when ever a
> photo is uploaded it would go to a temporary area then its primary key
> would be modded by 30 to get a number between 0 and 29 then the photo
> would be placed in that folder. So like this:
>
> 1. User uploads photo to temp directory.
> 2. Info is grabbed from the photo.
> 3. The information is inserted into the database.
> 4. The primary key is modded by 30, so $folder = ($primary_key % 30);
> 5. The photo is moved into that $folder.
> 6. A thumbnail is also created in the $folder/thumbs/ directory.
>
> The things that would be stored in the database about the image are the
> filename, hash folder so it does not have to be recalculated, original
> width, original height, thumbnail width, thumbnail height, filetype,
> filesize, and other things related to the user but nothing really too
> crazy is stored in the database.
>
> I hope this helps.
> Nick D.
>
> On Dec 22, 4:03 pm, "eholz1" <ewh...@gmail.com> wrote:
> > Hello Nick and Seaside (an den See!!),
> >
> > The only reason I have for putting the image data in the table is for
> > learning and fun(??).
> > but it does seem like a better idea (now) to use a file system scheme,
> > like Nick mentions.
> >
> > I will do a little research on the term "mod 30 hash folder" (i am
> > fairly new to this!!), and see what I can do with it. I may need to
> > get back and ask more questions.
> >
> > Thanks for the good info,
> >
> > eholz1 aka ewholz
> >
> > Nick DeNardis wrote:
> > > Very True, I use to run a photo hosting web site and I experimented
> > > with this in the beginning and oh man once there was 100,000+ images in
> > > there the MySQL DB slowed down quite significantly. Almost 3 gigs of
> > > data in a MySQL table is not the way to do it, I have found the file
> > > system does a much better job holding and serving images.
> >
> > > What I ended up doing is just creating a simple mod 30 hash folder
> > > setup to store all the actual photos and then have a table to store all
> > > the attributes of the photos. This improved the performance very
> > > significantly over the pure MySQL setup. Also separating the photos
> > > into 30 different folders helped in case I actually had to do any
> > > folder scans, it would not need to scan though all the photos just
> > > 1/30th of them.
> >
> > > I hope this helps.
> > > Nick D.
> >
> > > On Dec 21, 10:57 pm, "seaside" <seaside...@mac.com> wrote:
> > > > eholz1 schrieb:
> >
> > > > > Hello Members,
> >
> > > > > I am setting up a photo website. I have decided to use PHP and MySQL.
> > > > > I can load jpeg files into the table (medium blob, or even longtext)
> > > > > and get the image(s) to display without a problem.Just a small performance note:
> >
> > > > If you use blobs and various other types, MySQL is likely to fall back
> > > > in table-scan mode which might slow down your queries very much. A
> > > > table-scan needs to read the full table data, at least much more, than
> > > > an index.
> >
> > > > Even if you use some indexes, MySQL might not use them - the exact
> > > > behaviour depends on your indexes and queries.
> >
> > > > Are there good reasons to keep image data in tables and not in file
> > > > systems - other than simpler coding, e.g.?
Navigation:
[Reply to this message]
|