|
|
Posted by Mikee Freedom on 01/29/07 22:54
hey again,
Thanks for your advice on this one. Given me some sound info to mull
over.
Geoff, you're probably right. Will think on it some more. And next
time I will put more thought in to the exact language I use to ask
questions RE "I like the idea". Any tips on the use of apostrophe
would be much appreciated.
AlterEgo (and others), I think I will go with the filesystem solution
on this one.
Jerry, different users won't be uploading their own scripts nor
creating tables. They will have various configuration options they can
manage for their own area. The client would like these sites to be as
seperate as possible which was my original motivation to go for
seperate databases.
Anyway, thanks again all for your help on this one. And for the info
on storing images in the DB.
cheers,
mikee
On Jan 27, 4:29 pm, Jerry Stuckle <jstuck...@attglobal.net> wrote:
> 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.
> jstuck...@attglobal.net
> ==================
Navigation:
[Reply to this message]
|