Menu
The answer by phpguy is correct but I think there is a lot of confusion in the additional details there.
The basic answer is in a BLOB data type / attribute domain. BLOB is short for Binary Large Object and that column data type is specific for handling binary data.
See the relevant manual page for MySQL.
For a table like this:
CREATE TABLE binary_data (
id INT(4) NOT NULL AUTO_INCREMENT PRIMARY KEY,
description CHAR(50),
bin_data LONGBLOB,
filename CHAR(50),
filesize CHAR(50),
filetype CHAR(50)
);
Here is a PHP example:
<?php
// store.php3 - by Florian Dittmer <[email protected]>
// Example php script to demonstrate the storing of binary files into
// an sql database. More information can be found at http://www.phpbuilder.com/
?>
<html>
<head><title>Store binary data into SQL Database</title></head>
<body>
<?php
// Code that will be executed if the form has been submitted:
if ($submit) {
// Connect to the database (you may have to adjust
// the hostname, username or password).
mysql_connect("localhost", "root", "password");
mysql_select_db("binary_data");
$data = mysql_real_escape_string(fread(fopen($form_data, "r"), filesize($form_data)));
$result = mysql_query("INSERT INTO binary_data (description, bin_data, filename, filesize, filetype) ".
"VALUES ('$form_description', '$data', '$form_data_name', '$form_data_size', '$form_data_type')");
$id= mysql_insert_id();
print "<p>This file has the following Database ID: <b>$id</b>";
mysql_close();
} else {
// else show the form to submit new data:
?>
<form method="post" action="<?php echo $PHP_SELF; ?>" enctype="multipart/form-data">
File Description:<br>
<input type="text" name="form_description" size="40">
<input type="hidden" name="MAX_FILE_SIZE" value="1000000">
<br>File to upload/store in database:<br>
<input type="file" name="form_data" size="40">
<p><input type="submit" name="submit" value="submit">
</form>
<?php
}
?>
</body>
</html>
I strongly recommend against storing binary data in a relational database. Relational databases are designed to work with fixed-size data; that's where their performance strength is: remember Joel's old article on why databases are so fast? because it takes exactly 1 pointer increment to move from a record to another record. If you add BLOB data of undefined and vastly varying size, you'll screw up performance.
Instead, store files in the file system, and store file names in your database.
While you haven't said what you're storing, and you may have a great reason for doing so, often the answer is 'as a filesystem reference' and the actual data is on the filesystem somewhere.
http://www.onlamp.com/pub/a/onlamp/2002/07/11/MySQLtips.html
It depends on the data you wish to store. The above example uses the LONGBLOB data type, but you should be aware that there are other binary data types:
TINYBLOB/BLOB/MEDIUMBLOB/LONGBLOBVARBINARYBINARY
Each has its use cases. If it is a known (short) length (e.g. packed data), BINARY or VARBINARY will work most of the time. They have the added benefit of being able to index on them.
While it shouldn't be necessary, you could try base64 encoding data in and decoding it out. That means the db will just have ascii characters. It will take a bit more space and time, but any issue to do with the binary data will be eliminated.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With