Recently I am trying to upload an image to my database by using Summernote
I found a problem when I am trying to upload different size of image.
Firstly, I'm trying to upload an images which contains 525 x 404 width and height and 39,9KB of file size. It succeeded insert into my database.
I'm trying to upload an images which is more larger than previous one which contains 1600 x 1697 width and height and 743KB of file size. But it failed to insert into my database.
I am using MySQL database. The field using TEXT to store all the content.
CREATE TABLE Newsletter (
ID INT,
Content TEXT,
PRIMARY KEY (ID)
);
May I know it is my database problem or it is Summernote limitation.
Thank you.
Thank everyone. I solved my problem already. Just simply change the TEXT to LONGBLOB will do.
TEXT can only store a limited amount of data, where LONGBLOB is much larger, and is more geared towards storing file data.
Didn't use Summernote, but I would bet the problem is in size of your POST. Bigger the image, bigger the base64 string with image data, and your server probably has a limitation of POST size which is exceeded if the image is bigger.
If you are testing this in local environment, you can try to raise post limit in Apache config and test this theory.
You can try
post_max_size=100M
in php.ini, or
php_value post_max_size 100M
in .htaccess
EDIT: Don't forget to restart Apache after changes, and let us know did this help or not.
Related
I wrote some basic blog system, which based on spring boot.
I'm trying to figure out, how can I create posts with videos and images, without the need to editing everything using HTML.
Right now, I am saving my blog posts in DB as plain text.
Is it possible to create content combined with text, images and videos , and saving this "content" as one row in my DB-Table, without creating connections between different tables?
Many thanks in advance.
Images and Videos are heavy content and storing them in database could be a costly affair, until you are developing application for research purpose. Also querying it from database and serving it over the network can impact your application performance.
If you want to store it in a single row that can be done as well using database BLOB object. But i would suggest to have 2 different tables. One containing the BLOB object of Image and Videos and other is your usual table containing blog as text and primary key of of BLOB table.
If you want to take your solution to go live, better use image-videos hosting servers because of following factors
Saves your database cost
Ensures 24x7 availability
Application performance is faster as these are hosted independent of application
Videos can directly be iframed i.e. you do not need to query complete MBs of record and serve over network
A strict answer to your question, yes, you can use BLOBs to store the video/images in the database. Think about them as a column that contains bytes of video or image.
For school/cases where you have a very small amount of videos/images its probably OK. However if you're building a real application, then don't do it :)
Every DBA will raise a bunch of concerns "why do not use Blobs".
So more realistic approach would be to find some "file-system" like storage (but distributed) style S3 in AWS, hardrive on server if you're not on cloud, etc.
Then store that big image / video there and get an identifier (like path to it if we're talking about the harddrive) and store that identifier in the database along with the metadata that you're already store probably (like blogPostId, type of file, etc.)
Once the application become more "mature" - you can switch the "provider" - Grow as you go. There are even cloud storages designed especially for images (like Cloudinary).
I have created emp table to store employees information and their PP size photo.
this table has empno (number), emp_image_link(varchar2), .... etc fields.
empno is auto generated using a database trigger (max empno+1).
Image : I don't want to store images into the database since I believe it will cause problems in terms of size, performance and portability. So images should be in the file system at D:\images\
and images URL should be D:\images\empno.jpg, which means emp_image_link field will contain only the image link.
I have searched Google a lot about this, everyone is discussing about how to store into the database.
I did not find any information about how to store only the link instead of the image.
I am going to use Oracle Forms Developer 11gR2.
Can anyone give me an idea of how I can do that please.
Thank you in advance.
Murshed Khan
"i dont want to store images into the database since it will cause
problem in terms of size, performance and portability i believe. so
images should be in the file system"
Your points are not valid ones.
Size. Passport photos are pretty small, so unless you are storing pictures with extremely high pixel counts they won't take up a lot of disk. Either way they will consume comparable amounts of space in the database and on the OS.
Performance. The only possible concern would be the network traffic between the database server and the middle-tier server. This would be a function of size, so may or may not be a real issue. Using na OS file store would introduce a time delay while you retrieve the JPG for each record.
Portability. An all-in-the-database solution is more portable than what you're proposing. Nothing breaks like directory paths.
One thing you haven't considered but you really should is DML on the employee records. If the pictures are stored in the database they are committed in the same transaction as (hence consistent with) the rest of the data, they are backed-up at the same time and they are recoverable in the same window. None of which applies to an OS directory on a separate server.
"Storing in the file system ... I got the solution using BFILE "
BFILE is the mechanism for linking a database record with an OS file. So it is the appropriate solution for the problem as you define it. But the BFILE points to files on the database server, so you would lose the only possibly efficiency to be gained from not storing records in the database, the network traffic between the database and middle tier servers. BFILEs would not be backed up with the database or subject to any transactional consistency.
"empno is auto generated using a database trigger (max empno+1)"
Another bad idea. It doesn't scale and more importantly it doesn't work in a multi-user environment. Please use a sequence, they're designed for this task.
Hello
I am working on codeigniter project.
And my question is that : Is it possible to store image as cookie ??
If yes then can please you provide me some documentation or examples on it?
A cookie is a short piece ox text that is stored on the user's computer. Typically it will be no more than 4096 bytes (the lower limit specified by RFC2109). If you can compress and base64 encode an image into this then it might be possible to store an image, but it will be a small image indeed!
There are many ways to tackle the situation,
1.Encode the image to string and store the string to a cookie, but the size limit is 4kb
2.Store the image link to a cookie, but it should either located in our server or the image must be in the internet for locating.
3.Use HTML5 to store images locally HTML5 code example: Intelligently store Images in localStorage for faster page loads!
i have not tried this but i think if you use codeigniter sessions - with a session database table - then you might be able to store the image in the session db table. when you use a session table, codeigniter only stores an ID in the users cookie.
http://ellislab.com/codeigniter/user-guide/libraries/sessions.html
I capture images within my app and need to store them. I'm not sure where the right place is to store the captured image. Storing the image as byte array in the database would be very nice but whats happening if the next-gen smartphones getting a high-resoltion camera and the images become bigger? Are they exceeding my database limit or my app becomes slowly?
Is it better to store the image into IsoStore?
I'd store in the isostore, if you want to use database, you might just store the path of the image or name to be able to find it from the isostore.
It should be faster to use isostore instead of database.
If you want to store image in database use blob type attribute in database,
Convert the image in byte-array and execute the database command.
To convert the object in byte array follow the link.
This answer is based on sqlite database.
I made a people maintenance screen. The client want me to store the photo of every person in the database, and I made it without problems. I have a separate table for the images with two fields, Id_person,and Image.
I'm a little worried because it's the first time that i work with images in database. will I have problems of performance when the table grows beyond 1000/5000 images? I suppose that the size of every image will make a difference. I'm sure that I will need to control that the user don't save very big images in the Database.
What would be a good size limit? The client only need pics of the face, but I'm sure that someone will try to make the pics with a "last model" camera in full quality ;)
Thanks.
It's usually preferred to keep a folder of images and the DB just references that folder. Ideally, each person has a unique ID and the files in the "images" folder match that ID.
If you really want to store the binary data directly, you can get a reasonable quality photo in 8KB of a JPEG (approx 250x250 pix # 25% quality). Of course, this would be unacceptable for printing, but is fine for identification.
Only you will know if you can accept an additional 8KB per row in your database server.
If you absoultely MUST do it this way, I would say limit it to just a few kilobytes each. However, every database admin in the world will probably tell you that blobing images into a database field is a very, very bad idea. Most noticably you will see the performance decrease drastically when the database file grows beyond two gigabytes in size.
I would prefer to do as jheddings said and have a folder with each person's ID be the file name and just use a standard .jpg or something after that on a network share so all computers using the app can access the images.
Some find that simply using the ID isn't good enough incase the photo needs to be deleted or archived, in which case they will put a NVARCHAR(MAX) field into their database and store the network file path to the image instead of the actual image.
I would only blob the image if your customer absolutely cannot have a network share path.
as long as it is in separate table with ID|BLOB only there shouldn't any performance issues fetching that photo, but on the other side i prefer keeping in DB only references to files on hdd (or even better if its only user photo you dont realy need a reference because user with ID 1 goes to /images/1.jpg)