Jump to content

1&1 Host and MySQL DBs


shlomikalfa

Recommended Posts

What exactly are you storing in the database? If it is images or files, you should store them as files in a folder.

 

I'm not knowledgable in databases to be honest (one of the next things on my self-educating list). In the risk of sounding foolish, wouldn't storing them in folders be a given? Or is there an actaul way to store the actual image itself within a database?

is there an actaul way to store the actual image itself within a database?

 

Yes. You can store binary data within a BLOB field type.

 

Ah, ok..just checking.

And as such, I suppose if the image size and / or count is large, it becomes unpractical to store it directly...

I use 1&1 too, and there is no way to increase the size of the DB without moving to a VPS, or Dedicated server. The shared packages are capped at 100MB. But you probably have like 100 of em.

 

Really when you think about it, since your storing just text strings and such, a 100MB database is pretty decent size. I don't think I have ever hit that size, not on the 1&1 db's, my personal testing server ( which runs a site for my wife that contains, address book, recipes, blog and a few other things).

 

Nate

And as such, I suppose if the image size and / or count is large, it becomes unpractical to store it directly...

 

It's the other way around. File systems are designed to store and retreive large quantities and sizes of files. Databases are designed to store data that you want to manipulate. You cannot manipulate the binary data in files stored in a database in a meaningful way. That combined with the additional overhead of serving files out of a database, limitations, such as the maximum packet size you can transfer in a single query that limits the size of a file that can be stored or retrieved, or that dumping binary blob data is done in hex giving data that is double the size of the actual stored binary file all make using a database as a file storage engine an exercise in inefficiency and wasted processing time.

And as such, I suppose if the image size and / or count is large, it becomes unpractical to store it directly...

 

It's the other way around. File systems are designed to store and retreive large quantities and sizes of files. Databases are designed to store data that you want to manipulate. You cannot manipulate the binary data in files stored in a database in a meaningful way. That combined with the additional overhead of serving files out of a database, limitations, such as the maximum packet size you can transfer in a single query that limits the size of a file that can be stored or retrieved, or that dumping binary blob data is done in hex giving data that is double the size of the actual stored binary file all make using a database as a file storage engine an exercise in inefficiency and wasted processing time.

 

Duly noted. Thanks for the correction... Something tells me my MySQL journey is going to be an interesting one to say the least.

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.