Just a quick question I am wanting to allow users to link there facebook account to my new product, and I am wondering how do I take there facebook photo URL and save it as an image in BLOB formate for MYSQL
I am using this example to connect to Facebook
https://github.com/facebook/connect-js/blob/master/examples/jquery/login.html
and to send the image to my server I use the $.ajax formate to submit it to the core.php (I have not coded this yet, as I need to know the best way.
Well my first recommandation is to NOT store image data in your database unless you absolutely need that in your database backups. You will clutter your database massively. Instead, just get the url to the picture using the server-side $facebook class, and just "file_get_contents" it to your php memory.
Then dump it on disk and save a reference of that dumped image in your database. It will do much more good to your database this way.
Else, if you really want to save it to a BLOB, use the same method to fetch the image to memory and then use the hex() function to transform it to a textual representation that can be fit into an INSERT/UPDATE query...
Just save a reference to the location where Facebook stores the image. That way you can abuse their servers (which are very nice/fast) and just serve image tags that refer to their servers.
Also when you save images to a database you lose the native compression that you get when you save an image to the filesystem, so you bloat your data storage size for not much reason (backups are easier I suppose).
Related
Is it good to store blob images in mysql database and fetch them in the flutter app using php or should I store them in a separate folder with their links in database? For a database with above 100K images what would be a better solution. Storing image paths would be difficult while backup i think. Can someone suggest what to do. It will be very helpful. Thank you in advance!
The best practice is to store the images in a folder and just save their path's in the database. So basically convert the images to base64 and send it to your webserver in a regular POST method. then in your PHP code decode the base64 to a file and save the image wherever you want, just remember to keep track of the image new path so can fetch it later. fetching, by the way, works the same. good luck :)
I am new to Android development. I am just trying to store an image in MySQL database and want to display that image in an ImageView.
What should I do?
I think I have to store the URL of image in MySQL database but I don't know how to do it either.
I am using PHP too.
One method is to store the base64 version of image using a php script with
base64_encode() wich returns the base64 encryption of the image but i don't recommend it because this is increasing the size of the image.
You should upload the image to a server and only store in the database the path to the image and then load it inside the Android application.
Here is a nice Java tutorial that explains how to upload an image through HTTP http://www.jguru.com/faq/view.jsp?EID=62798 it should work for your application.
Try to avoid if you can, storing images in database (as it would increase the size)..
If you cannot avoid, try using BLOB in database.. as mentioned here.
NOTE: Also do some research before asking questions.
What should I use to save an image in the database. In what type I have to use to store and retrieve the image in PHP and MySQL.
Rule of thumb is you shouldn't be storing images in the database. Blob is available but is pretty crappy.
What you should be doing is storing the binary file on the filesystem which is many times faster than a database and in the database just store a path or link or file name and have the application load the image from the path instead.
This allows you to easily implement stuff like cdn's or san storage etc for static files. It even allows you to use something like lighttpd to display the static content images rather than apache.
https://blogs.oracle.com/manveen/entry/blob_vs_file_system_storage gives a little more information but there's plenty of stats and data on the web about the disadvantages of blobs
use BLOB Datatype which means Binary Large Object
BLOB
BLOB's may be slower than file storage, but it is much easier to copy, backup, and restore a single database file than it is to manage/maintain images in a file structure.
I also recommend storing the images in their own dedicated database (store the properties/tag information in a separate database).
Simple & optimized option is to upload the image on the server and store the string of "url of the image" in database.
Incase, you want to store actual image file only, then use Blob datatype.
Its a very bad idea to store images in database. Database is determined to save a little pieces of information - not images or files. You have HDD on that purpose.
Instead, you should save image on disk and save its filename in database. Like that:
$name = uniqid();
file_put_contents($name.".png",$image_data);
mysql_query("INSERT INTO `images` (image) VALUES ('$name.png')") or die(mysql_error());
If you really insist on saving images in DB use BLOB.
Lets say I'm building a image gallery using PHP, where users would be able to upload their photos.
Every user would have 1 folder on server side with all their images there.
Now lets say I need to provide information in browser. Users would be able to browse images and should see lots of information about them, like image size, image dimensions, even EXIF information etc.
I could do this in 2 ways:
Save all information about image into database when uploading image.
Use PHP functions to browse through folder, and get information from every image.
I have something like file manager class, that can do all manipulations with files on server side, like deleteDir, deleteFile, countItems, getFileSize, getDirSize.
And it would be easy to only write one more class that would inspect images, and then I could just upload images, and get their information right from the folders without a need for relation database.
And now the question you all been waiting for is: ... :)
What would be faster, first or second solution? Lets say that site gets loads of traffic.
What solution would be better if I want it to be fast, and not to stress server to much?
actually, I got this situation like yours, this is my solution:
Save all information about image into database when uploading image.
Why?
I tested 2 ways:
Using php to get the image info for 1000 times.
Getting image info from database for 1000 times.
And the result is :
Getting image info from database is faster and faster.
Last but not least:
What would you do if you want to do a image info analystics?
If you save all info in database ,you can easily get them and analyse them ,but if you using php to get the info? it's hard to image.
So, just save all information about image into database when uploading image.
Good luck.
storing it in the database once
reading the data from the database and store it in cache,
redoing things always costs especially if it happens all the time
Depending on the size of these images, you probably want to show thumbnails instead of the original when people are browsing, which means you need to generate them. I would generate the thumbnail on upload and grab all the file info. Then save the file info in the database and put the original and thumbnail in the file system. If you get a lot of traffic, throw memcache on there too.
Storing data in separate places has a way of creating maintenance headache. I would just serialize the metadata for images in each folder and dump it to a file there. If you use gzip compression on the file, retrieval and storage should be very fast.
I'm creating a blog with a featured image on each post. I have a dilemma, I'm unsure what to do with my image data...
Should I insert image data into my MYSQL database using BLOB?
Or should I just create an uploader which makes a directory into the users images folder and upload the photo that way...then just reference it directly in the image field when adding a Blog Post?
Is there a standardised way?
Kind regards,
adam
Upload the files to your server and save the location of the file in your database. Less strain on your DB and your HTTP daemon is better at serving images than MySQL.
The general approach is not to store files in DB, unless you understand why do you need it to be stored there. So, since you are not sure, it's much simplier storing them in upload folder.
But, just in case you decide you need storing files (no matter images or some other) in DB, you have to declare BLOB field and then save it using some BLOB-supporting DB mechanism. 'PHP's MySQLi extension: Storing and retrieving blobs' is a good example of how it can be made
You should store images in folder. Click on below link from where you can get idea how to crop different-different size images and store images name in to database table:
How can I upload images in a normal insert form (MySql)? after upload the image should have three versions of different sizes and different names
convert the image data to base64. This can be done within PHP:
<?
$image=file_get_contents("image.png");
$image=base64_encode($image);
?>
Storing images in a DB is a good idea for secure images.
Always store images, music files etc in system files on disk, and then store the urls to them in the database. That will make it
1) faster
2) easier to configure security settings
3) better in any ways I can imagine
Disadvantage
If file system is corrupted you will have hard time recovering.
You can also use third party Image hosting sites too, you can use Amazon S3 or Mosso Cloud Files.
Problem with file system is it is difficult to scale.
Facebook uses cassandra to store images.
Since it is blog you can store images in filesystem.
Both are valid approaches.
They have different advantages/disadvantages.
Storing it in the database means you need to add extra code to change the image to a representation which will fit inside a INSERT/UPDATE statement (base64 is one approach, and requires equivalent decode, but you could just use mysql_real_escape_string()). Although you can't query the image directly (other than finding exact matches) it may reduce the number of seek and I/O operations required to retrieve the data compared with looking up the path in the database then retrieving the file.
It's also a lot simpler to set up replication of a database compared with setting up replication of the database AND the filesystem if you run on multiple nodes. And there's the issue og keeping filesystem and database backups synchronized.
OTOH, using a filesystem makes your data tables much smaller, and therefore faster to retrieve records from.
which makes a directory into the users images folder
You certainly don't want to allow users to upload content directly into your webserver's document tree - regardless of which route you take, the data should be stored in a location not directly accessible by the webserver but accessible by your code.