|
|
Posted by Jerry Stuckle on 01/27/07 03:29
Gary L. Burnore wrote:
>>
>>> Jerry,
>>>
>>> Regarding storing images in the database:
>>>
>>> 1. If one is looking for quick and easy (as in a hobby application),
>> then I
>>> totally agree - store them in the database. If one needs to keep a
>> scalable
>>> product life-cycle in mind, then I would not keep them in the database.
>> I disagree. It scales quite well to larger databases. I've had
>> databases over in the tens of gigabytes containing pictures, PDF's and
>> other binary data. It works great.
>
> Wow, tens of gigabytes? Heh.
>
Yep. How many databases of that size do you deal with? From your other
statements I suspect you haven't gotten over 50Kb.
>>> 2. If this is a commercial or community driven venture, then it will
>> have to
>>> scale if it is successful. If it is not successful, then it really won't
>>> matter.
>> The busiest has upwards of 100K hits per day average Peaks have been
>> over 250K. During testing we pushed it at > 1M hits/day. That's well
>> beyond a "hobby site". In fact I wish some of my other sites got this
>> much traffic :-)
>>
>>
>>> 3. Transferring binary data from the native file system is way faster
>> than
>>> any SQL database.
>> I suggest you check your figures. It may be a little faster - but in no
>> way is it "way faster".
>
> Its dependent on the filesystem, the databsae and many other things.
> You're both blowing hot air.
>
Wrong. I don't know of any filesystem which can handle 100K files in
one directory very well. But 100M rows is easily handled by a good
database.
You really should get some facts before you start accusing others of
blowing hot air.
>>> 4. File systems are more easily scaled than databases.
>> Again I disagree. I've been doing RDB work since the early 80's when I
>> started with DB2 on IBM mainframes. If properly designed, databases can
>> scale much better than file systems.
>
> Two more moronic statements. (His and yours). Either can scale well
> if designed correctly.
>
Let's see you scale a filesystem to handle 100K files in a single
directory. And no, I'm not talking about putting them in separate
directories - where the program has to decide which directory(ies) to
search for the file. I'm talking about like you do in a database - with
everything in a single table.
>>> 5. Automated image management utilities (for creating thumbnails,
>> converting
>>> image formats, reading image meta-data, etc.) love working with file
>>> systems, but hate working with databases.
>> So don't use them. Not a problem.
>>
>> I do use them. When a new image is uploaded, for instance, I may store
>> a thumbnail as well as the image itself. But I don't need it after that.
>>
>> And why should I waste CPU and other system resources creating
>> thumbnails every time they are requested?
>>
>>> 6. Its far easier to distribute images to the "edge of the web" with
>>> companies like Akamai or Digital Island hosting the content close to the
>>> users.
>>>
>> That's one way to do it. But it also creates nightmare backups and the
>> like. Mu customers use mostly dedicated servers and VPS's.
>
> So backing up a bunch of dedicated servers is better how, exactly?
>>> I guess what it really boils down to is: thousands of pictures or
>> millions
>>> of pictures? hi res, low res, thumbnails, etc.?
>>>
>>> -- Bill
>>>
>> Tens of thousands of pictures. Hi res and thumbnails, mostly. As I
>> said, database size in the tens of GB. Don't know what it is lately - I
>> haven't looked at the size.
>
> When you get to tens of terabytes, then you can talk about how well
> you scale. Tens of gigs or even a couple hundred is nothing anymore.
>
No, but it's bigger than most of the websites out there.
And how many filesystems handle 10's of terabytes in a single directory?
> He's right about one thing. It makes far more sense to NOT store
> images in a database table.
>> I suggest you try it before you start telling me how bad it is. As I
>> said - I've done it for a number of sites. It works great. And I've
>> been doing it with RDB's for a lot longer than most people in this
>> group.
>
> Bullshit.
>
Yep, and you're the one who's full of it. You know nothing about my
background or my experience.
Stoopid asshole.
>> Proper design, tuning and implementation and it works quite well.
>
> Now that is true.
>
>> How many have you actually done this on? Or are you just talking
>> through your hat?
>
> Better than out your ass.
>> P.S. Please don't top post.
>
> We agree on this.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================
Navigation:
[Reply to this message]
|