I am using Sencha Touch to capture data from a user on an iPad. This includes a standard form (name, email, etc.) as well as the customer's signature (see the plugin here).
Essentially, the plugin takes the coordinates from the user's signature and gives me back Base64 PNG data.
Once I have the signature data, I want to store it. My two questions are:
Should I store the Base64 data in my
(MySQL) database along with the rest
of the user's information, or should
I create a static file and link as
necessary?
If storing in the
database is the way to go, what data
type should I use?
There's no need to base64 encode the image. MySQL's perfectly capable of storing binary data. Just make sure you use a 'blob' field type, and not 'text'. text fields are subject to character set translation, which could trash your .png data. blob fields are not translated.
As well, base64 encoding increases the size of text by around 35%, so you'd be wasting a large chunk of space for no benefit whatsoever.
However, it's generally a bad idea to store images in the database. You do have the advantage of the image being "right there" always, but makes for absolutely huge dumps at backup time and all kinds of fun trying to get the image out and displayed in your app/web page.
it's invariably better to store it externally in a file named after the record's primary key for ease of access/verfication.
Just save files in BLOB field. Such PNG file shouldn't be larger than 1KB if you turn some optimizations (grayscale or B/W).
Storing files outside DB seems easy but there are things to consider:
backup,
additional replication if multi-server
security - access rights to files dir, but also to files,
no transactions - e.g. DB insert ok but file write fails,
need to distribute files within multiple directories to avoid large dir listings (depends on filesystem capabilities)
Blob will store Base64. It will get you what you need. Storing it in the database gives you built in relational capabilities that you would have to code yourself if you stored it in a static file. Hope this helps. Good luck sir.
Edit: mark's right about binary v. base 64
Set your field as Blob data type, it stores perfectly base64EncodedString
Related
I have JSON file that I want to save as a blob to Microsoft SQL Server.
The pros for zipping is saving space, the cons is the readability that getting lost.
I want to know if T-SQL has any optimization in which it zips the blobs on its own. I know that columnar databases work this way, like Vertica or Postgres for example.
I personally would not compress them if I wanted to be able to search by them. I do not believe it compresses a blob on it's own. I know for a fact even just very large VARCHAR columns do not compress on their own, so I would not expect a blob to. However there is built in compression you can turn on:
https://blogs.msdn.microsoft.com/sqlserverstorageengine/2015/12/08/built-in-functions-for-compressiondecompression-in-sql-server-2016/
https://learn.microsoft.com/en-us/sql/relational-databases/data-compression/enable-compression-on-a-table-or-index?view=sql-server-2017
There are some advantages to it but usually at the cost of CPU. So if I were you, I'd probably not zip up the files to put in SQL, but I might compress the tables I store. It would depend on exactly what the data was, json probably gets a lot of space back on compression, but a .jpeg would not.
An option I have done in the past is to simply store my files on a content server somewhere, and store in SQL the meta data about the file (name, tags, patch to where I stored it, file extension, etc.) That way my data is easy to get at/put there and I simply use SQL to look it up. Additionally it has allowed me when it was large text files to also use Lucene indexes from solr to make a full text searchable solution since the data wasn't stuffed into a SQL table. Just an idea! :)
One more thought, if I were to store big json files into SQL I would probably choose VARCHAR(MAX) or NVARCHAR(MAX) as my datatype. Anytime I have tried to use TEXT, IMAGE, etc. I would later run into some kind of SQL error if I tried to do a tricky query. I believe Microsoft is trying to use VARCHAR(MAX) to replace the blob type of data types and is slowly deprecating them.
I have uploaded a csv file into database as a byte[] data, using hibernate and spring, I have 3 columns in my database (id, file name and byte[] data). I would like to display the 3rd column which is a csv file, into a front page. Any help?
From the database perspective, this is nothing more than querying the table by ID and reading the BLOB from the database.
The tricky thing is that unformatted BLOBs/CLOBs are usually read using streams of some sort, and rarely are available as straight columns. Depends on your database implementation, hibernate can sometimes hide the complexity, but something to watch out for.
In terms of displaying it, it's a matter of using the returned BLOB and throwing it into something to force it to display. A quick search found this, but this is really the more difficult part of the problem, the database side can be fairly boring here.
i'm developing an android app where the user can take a photo. The app will have to upload it. I'm new of servers/databases. What's better? Store the image file "image.jpg" on the server or store the image string, encoded with base64, in MySQL db?
Are there other strategies?
CONSIDER THAT i will have to reload the image to visualize it on the phone.
i think better way is to store the images in a folder on the server and store their link in database..
Reasons
1) Normally time required to perform file operations is less than time required to perform database operations.
2) Updating the image is easy because its stored in file system which prevents the update operation on database which takes more time.
I think it is not a good idea to store image string in database instead of just its path (image name). Store your image on server and its name or path in database. Because retrieving image string from db and creating image for it each time you need that image is expensive. So better store its name only in server.
I have to display images on website and I can store image in the folder on my website and also I can store the image in image column of SQL Server.
So which way of storing image is better : in folder or in Image column of SQL Server.
1. Which way of storing image and retrieving it is faster
With SQL Server 2008, while you can store BLOB data, it's best to avoid it. I've done it in the past, grudgingly, and it did have negative performance implications. Unless you have some constraint which prevents it, use the file system. That's what it's built for, and it's much faster.
As #Martin Smith pointed out you could use FileStream. We started storing our files using FileStream so that we could also add full-text indexing and allow the users to not only search the data, but the files on our site. It is also nice because we can easily move our files along with teh Database to other environments (Dev, Test).
nice file stream Article: Here
Also, please use varbinary(max) if you are going to store in the DB. The image column is going to be deprecated in future versions.
--S
I am trying to prepare a sample question paper preparation app.
I am using tinyMCE editor and ajax-file-uploader plugin with it - as some questions may need images along with text.
How do I store my questions that have both image and text into MySql using PhP?
I would suggest storing the image on some sort of NAS or some other location, and store the path to the image in the database along with the other data in respective fields.
You can store the image in the DB but it is not good idea to retrieve and present the image from the database to the user (It doesn't perform that great either). There might be a performance hit
MySQL handles images very well. You insert them in BLOBs. On the other hand you could store the image file name and path or a link, as text in your DB.
Which solution is the best depends on the requirements of your application. In general if you have a huge amount of images, your database will become huge and backing up will be slow. There might be a similar impact on your file system in order to store a huge amount of images.
Here is the interesting Microsoft To BLOB or not to BLOB paper, that will give you more information on the topic and even some metrics.
I would echo the answers already given by #harigm and #Costis Aivalis but if you really wanted to go "all out" and store both the HTML content and the images in the same BLOB why not have a look at RFC 2557 which allows you to place binary data (like images) in the document itself using the url scheme data:. To make this work you will need to parse your HTML once it gets back to your server and base64 encode all the images to be placed in the HTML, quite a lot of work for what would probably turn out to be little reward.