Home » Php » Files into MySQL – PHP

Files into MySQL – PHP

Posted by: admin February 22, 2020 Leave a comment

Q(Question):

Ok, I have been told that it’s not a good idea to store binary files
(like pdfs etc.) in MySQL, but in the file system. I am in desperat
need of a system where I can upload binary files like this, categorize
them, add some extra info to each file, and list them/make them
downloadable. (listing and making files downloadable is easy with
PHP).
If I upload each file to a folder in the web server file system, how
is it then that I can refer extra information like a category and some
metadata to the files that I later will list? No database=no extra
info?
I need a human understandable answere, since I am a really newbie in
PHP and MySQL. Hopefully a code example. If someone could help.

A(Answer):

Message-ID: <11**********************@d57g2000hsg.googlegroups .comfrom
Nosferatum contained the following:

>If I upload each file to a folder in the web server file system, how
is it then that I can refer extra information like a category and some
metadata to the files that I later will list? No database=no extra
info?
I need a human understandable answere, since I am a really newbie in
PHP and MySQL. Hopefully a code example. If someone could help.

Well a database table would be best but you could store the information
as a csv file.


Geoff Berrow (put thecat out to email)
It’s only Usenet, no one dies.
My opinions, not the committee’s, mine.
Simple RFDs http://www.ckdog.co.uk/rfdmaker/

A(Answer):

Nosferatum wrote:

Ok, I have been told that it’s not a good idea to store binary files
(like pdfs etc.) in MySQL, but in the file system. I am in desperat
need of a system where I can upload binary files like this, categorize
them, add some extra info to each file, and list them/make them
downloadable. (listing and making files downloadable is easy with
PHP).
If I upload each file to a folder in the web server file system, how
is it then that I can refer extra information like a category and some
metadata to the files that I later will list? No database=no extra
info?
I need a human understandable answere, since I am a really newbie in
PHP and MySQL. Hopefully a code example. If someone could help.

You should really be asking this in a MySQL newsgroup – such as
comp.database.mysql.

But I will also add – how may of those people who say that have actually
tried? I suspect none. I have been doing it for almost 20 years and it
works fine.

==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================

A(Answer):

Nosferatum wrote:

Ok, I have been told that it’s not a good idea to store binary files
(like pdfs etc.) in MySQL, but in the file system. I am in desperat
need of a system where I can upload binary files like this, categorize
them, add some extra info to each file, and list them/make them
downloadable. (listing and making files downloadable is easy with
PHP).
If I upload each file to a folder in the web server file system, how
is it then that I can refer extra information like a category and some
metadata to the files that I later will list? No database=no extra
info?
I need a human understandable answere, since I am a really newbie in
PHP and MySQL. Hopefully a code example. If someone could help.

I’m certainly not the best coder here by miles but my suggestion is that
you create a table to store the information about the files and a filename
including path. You save the file to that path and use a SQL query to
extract the path name when you want to access the file. Up to you what you
use for file names. In my own photo database I am writing I use an auto
incrementing primary key as the file path for example, so the thumbnail for
photo_id=123456 lives at /data_dir/1/2/3/4/5/small.jpg. Someone will have
a better idea than this, but this one seems to work for low usage.


http://www.petezilla.co.uk

A(Answer):

Jerry Stuckle wrote:

But I will also add – how may of those people who say that have actually
tried? I suspect none. I have been doing it for almost 20 years and it
works fine.

Files belong in the filesystem. It’s what it does.

Data belongs in the database. It’s what it does.

There, done it: that should stoke the fires of debate.


"Checking identity papers is a complete waste of time. If anyone can
be counted on to have valid papers, it will be the terrorists".

A(Answer):

Peter Chant wrote:

photo_id=123456 lives at /data_dir/1/2/3/4/5/small.jpg.

Stick it in /data_dir/123456/small.jpg.


"Checking identity papers is a complete waste of time. If anyone can
be counted on to have valid papers, it will be the terrorists".

A(Answer):

Nosferatum wrote:

If I upload each file to a folder in the web server file system, how
is it then that I can refer extra information like a category and some
metadata to the files that I later will list? No database=no extra
info?

Store the metadata in a table; use the id as the directory name for the
files: /data_dir/$id/ contains the file.


"Checking identity papers is a complete waste of time. If anyone can
be counted on to have valid papers, it will be the terrorists".

A(Answer):

Mary Pegg wrote:

Jerry Stuckle wrote:

>But I will also add – how may of those people who say that have actually
tried? I suspect none. I have been doing it for almost 20 years and it
works fine.

Files belong in the filesystem. It’s what it does.

Data belongs in the database. It’s what it does.

There, done it: that should stoke the fires of debate.

Sorry, I don’t bite on trolling expeditions. If you want to discuss it,
take it to comp.database.mysql.

Or try it yourself.


==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================

A(Answer):

Mary Pegg wrote:

Nosferatum wrote:

>If I upload each file to a folder in the web server file system, how
is it then that I can refer extra information like a category and some
metadata to the files that I later will list? No database=no extra
info?

Store the metadata in a table; use the id as the directory name for the
files: /data_dir/$id/ contains the file.

Spoken by someone who obviously has no idea what they are talking about.


==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================

A(Answer):

Jerry Stuckle wrote:

Mary Pegg wrote:

>Nosferatum wrote:

>>If I upload each file to a folder in the web server file system, how
is it then that I can refer extra information like a category and some
metadata to the files that I later will list? No database=no extra
info?

Store the metadata in a table; use the id as the directory name for the
files: /data_dir/$id/ contains the file.

Spoken by someone who obviously has no idea what they are talking about.

Because files obviously belong in the database?


"Checking identity papers is a complete waste of time. If anyone can
be counted on to have valid papers, it will be the terrorists".

A(Answer):

Jerry Stuckle wrote:

Mary Pegg wrote:

>Jerry Stuckle wrote:

[Storing binary files such as PDFs in a MySQL database]

>>But I will also add – how may of those people who say that have actually
tried? I suspect none. I have been doing it for almost 20 years and it
works fine.

Files belong in the filesystem. It’s what it does.

Data belongs in the database. It’s what it does.

There, done it: that should stoke the fires of debate.

Sorry, I don’t bite on trolling expeditions. If you want to discuss it,
take it to comp.database.mysql.

Or try it yourself.

Why? Why would I *want* to put non-relational data in a relational
database? Why would I *want* to use a database as a filesystem?

Just saying "it works fine" is not enough.


"Checking identity papers is a complete waste of time. If anyone can
be counted on to have valid papers, it will be the terrorists".

A(Answer):

In article <fq******************@newsfe6-gui.ntli.net>,
Mary Pegg <in*****@invalid.comwrote:

Jerry Stuckle wrote:

Mary Pegg wrote:

Jerry Stuckle wrote:

[Storing binary files such as PDFs in a MySQL database]

>But I will also add – how may of those people who say that have actually
tried? I suspect none. I have been doing it for almost 20 years and it
works fine.

Files belong in the filesystem. It’s what it does.

Data belongs in the database. It’s what it does.

There, done it: that should stoke the fires of debate.

Sorry, I don’t bite on trolling expeditions. If you want to discuss it,
take it to comp.database.mysql.

Or try it yourself.

Why? Why would I *want* to put non-relational data in a relational
database? Why would I *want* to use a database as a filesystem?

Just saying "it works fine" is not enough.

Depends on your needs, dunnit?

If I’m providing as it might be a web page for our engineers to see what
the access procedure is for some site, that info is in the database. But
the hosting organisation might provide an extra Site Procedures doc,
that I also put in the database so the engineer can download it as
needed, at the same web page.

I’m not going to put it in some entirely separate filesystem that they
might not have access to while offsite, now am I.

— tim

A(Answer):

Tim Streater wrote:

In article <fq******************@newsfe6-gui.ntli.net>,
Mary Pegg <in*****@invalid.comwrote:

>Why? Why would I *want* to put non-relational data in a relational
database? Why would I *want* to use a database as a filesystem?

Just saying "it works fine" is not enough.

Depends on your needs, dunnit?

If I’m providing as it might be a web page for our engineers to see what
the access procedure is for some site, that info is in the database. But
the hosting organisation might provide an extra Site Procedures doc,
that I also put in the database so the engineer can download it as
needed, at the same web page.

I’m not going to put it in some entirely separate filesystem that they
might not have access to while offsite, now am I.

It’ll look the same to the user whether the document is stored as a
BLOB in the database or as a file.


"Checking identity papers is a complete waste of time. If anyone can
be counted on to have valid papers, it will be the terrorists".

A(Answer):

In article <_3*****************@newsfe2-gui.ntli.net>,
Mary Pegg <in*****@invalid.comwrote:

Tim Streater wrote:

In article <fq******************@newsfe6-gui.ntli.net>,
Mary Pegg <in*****@invalid.comwrote:

Why? Why would I *want* to put non-relational data in a relational
database? Why would I *want* to use a database as a filesystem?

Just saying "it works fine" is not enough.

Depends on your needs, dunnit?

If I’m providing as it might be a web page for our engineers to see what
the access procedure is for some site, that info is in the database. But
the hosting organisation might provide an extra Site Procedures doc,
that I also put in the database so the engineer can download it as
needed, at the same web page.

I’m not going to put it in some entirely separate filesystem that they
might not have access to while offsite, now am I.

It’ll look the same to the user whether the document is stored as a
BLOB in the database or as a file.

But they won’t have to go arsing about looking for it. I’ll have a
button on the page that’ll download it for them. NB, I got *asked* for
this feature by folks here.

— tim

A(Answer):

Tim Streater wrote:

In article <_3*****************@newsfe2-gui.ntli.net>,
Mary Pegg <in*****@invalid.comwrote:

>It’ll look the same to the user whether the document is stored as a
BLOB in the database or as a file.

But they won’t have to go arsing about looking for it. I’ll have a
button on the page that’ll download it for them. NB, I got *asked* for
this feature by folks here.

Let’s try again: it’ll look the same to the user whether the document
is stored as a BLOB in the database or as a file.

However an advantage to the site admin is that it’ll be humanly readable,
if it’s a file (e.g. "xpdf /var/www/html/documents/thing.pdf") whereas
if it’s a blob in the DB you have to do mucho arsing about to get at it.


"Checking identity papers is a complete waste of time. If anyone can
be counted on to have valid papers, it will be the terrorists".

A(Answer):

Mary Pegg wrote:

Jerry Stuckle wrote:

>Mary Pegg wrote:

>>Jerry Stuckle wrote:

[Storing binary files such as PDFs in a MySQL database]

>>>But I will also add – how may of those people who say that have actually
tried? I suspect none. I have been doing it for almost 20 years and it
works fine.
Files belong in the filesystem. It’s what it does.

Data belongs in the database. It’s what it does.

There, done it: that should stoke the fires of debate.

Sorry, I don’t bite on trolling expeditions. If you want to discuss it,
take it to comp.database.mysql.

Or try it yourself.

Why? Why would I *want* to put non-relational data in a relational
database? Why would I *want* to use a database as a filesystem?

Just saying "it works fine" is not enough.

Because it IS RELATIONAL. It is related to other data in the database.

A typical idiot spouting off about something about which she knows nothing.


==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================

A(Answer):

Mary Pegg wrote:

Tim Streater wrote:

>In article <_3*****************@newsfe2-gui.ntli.net>,
Mary Pegg <in*****@invalid.comwrote:

>>It’ll look the same to the user whether the document is stored as a
BLOB in the database or as a file.

But they won’t have to go arsing about looking for it. I’ll have a
button on the page that’ll download it for them. NB, I got *asked* for
this feature by folks here.

Let’s try again: it’ll look the same to the user whether the document
is stored as a BLOB in the database or as a file.

However an advantage to the site admin is that it’ll be humanly readable,
if it’s a file (e.g. "xpdf /var/www/html/documents/thing.pdf") whereas
if it’s a blob in the DB you have to do mucho arsing about to get at it.

Who cares if it’s "humanly readable" or not? It’s not going to be read
by humans.


==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================

A(Answer):

Mary Pegg wrote:

Jerry Stuckle wrote:

>Mary Pegg wrote:

>>Nosferatum wrote:

If I upload each file to a folder in the web server file system, how
is it then that I can refer extra information like a category and some
metadata to the files that I later will list? No database=no extra
info?
Store the metadata in a table; use the id as the directory name for the
files: /data_dir/$id/ contains the file.

Spoken by someone who obviously has no idea what they are talking about.

Because files obviously belong in the database?

Because files are just mechanisms for storing data. Same as a database.

But you obviously are spouting off something you’ve heard – but have no
real experience with.


==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================

A(Answer):

Message-ID: <8O******************************@comcast.comfro m Jerry
Stuckle contained the following:

>Why? Why would I *want* to put non-relational data in a relational
database? Why would I *want* to use a database as a filesystem?

Just saying "it works fine" is not enough.

Because it IS RELATIONAL. It is related to other data in the database.

If there were functions that could extract meta data about the image
(filename, size, type etc) then I think you would have a point. As it
is, you are simply using the database /as/ a filesystem when it clearly
isn’t. Now that’s not to say that that is a bad idea necessarily, I can
see arguments for adopting this approach (portability and ease of
maintenance for example) as well as arguments against.

>
A typical idiot spouting off about something about which she knows nothing.

Ad hominem remarks do nothing for your argument Jerry.


Geoff Berrow (put thecat out to email)
It’s only Usenet, no one dies.
My opinions, not the committee’s, mine.
Simple RFDs http://www.ckdog.co.uk/rfdmaker/

A(Answer):

Geoff Berrow wrote:

Message-ID: <8O******************************@comcast.comfro m Jerry
Stuckle contained the following:

>>Why? Why would I *want* to put non-relational data in a relational
database? Why would I *want* to use a database as a filesystem?

Just saying "it works fine" is not enough.

Because it IS RELATIONAL. It is related to other data in the database.

If there were functions that could extract meta data about the image
(filename, size, type etc) then I think you would have a point. As it
is, you are simply using the database /as/ a filesystem when it clearly
isn’t. Now that’s not to say that that is a bad idea necessarily, I can
see arguments for adopting this approach (portability and ease of
maintenance for example) as well as arguments against.

But it is relational. Every post in here has had comments about storing
the path to the file in the database. So if the path is relational
data, why isn’t the data?

You can save the size, type, etc. in the database, also – I do it all
the time. It makes things a lot easier – you don’t need to use the GD
functions to get the image size, for instance. Much more efficient.

>A typical idiot spouting off about something about which she knows nothing.

Ad hominem remarks do nothing for your argument Jerry.

I just call them like I see them. Someone who has made 1 other post in
the last 9 months, and comes in with an inane argument like hers is
obviously ignorant of the facts – yet still posts to the thread.

And I’ve seen too many people do the same thing about this subject. It
seems someone started a rumor years ago that you shouldn’t use an RDB to
store anything more than name, address and phone number. And too many
people have come to believe that’s gospel.

I started doing it with DB2 on mainframes in the 80’s (scanned documents
in that case). It works great. And I’ve been doing it for years on the
PC, using various databases. It works great there, also.


==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================

A(Answer):

In article <4L******************************@comcast.com>,
Jerry Stuckle <js*******@attglobal.netwrote:

Geoff Berrow wrote:

Message-ID: <8O******************************@comcast.comfro m Jerry
Stuckle contained the following:

>Why? Why would I *want* to put non-relational data in a relational
database? Why would I *want* to use a database as a filesystem?

Just saying "it works fine" is not enough.

Because it IS RELATIONAL. It is related to other data in the database.

If there were functions that could extract meta data about the image
(filename, size, type etc) then I think you would have a point. As it
is, you are simply using the database /as/ a filesystem when it clearly
isn’t. Now that’s not to say that that is a bad idea necessarily, I can
see arguments for adopting this approach (portability and ease of
maintenance for example) as well as arguments against.

But it is relational. Every post in here has had comments about storing
the path to the file in the database. So if the path is relational
data, why isn’t the data?

Don’t think I was talking about storing the path. Definitely the file
itself, in my example.

— tim

A(Answer):

Message-ID: <4L******************************@comcast.comfro m Jerry
Stuckle contained the following:

>If there were functions that could extract meta data about the image
(filename, size, type etc) then I think you would have a point. As it
is, you are simply using the database /as/ a filesystem when it clearly
isn’t. Now that’s not to say that that is a bad idea necessarily, I can
see arguments for adopting this approach (portability and ease of
maintenance for example) as well as arguments against.

But it is relational. Every post in here has had comments about storing
the path to the file in the database. So if the path is relational
data, why isn’t the data?

That’s beside the point. (well my point anyway) A one hour video
documentary might be relational also, would you store that in a db too?

Stuff in a database can usually be processed in some way (which is why I
added the caveat about functions that may be able to extract or
manipulate image data)

Another thing we haven’t talked about is data redundancy and
normalisation.

Let’s say you have a membership list. Some people have provided an
image others haven’t and you decide to use a placeholder image instead
(ok I’m sure /you/ wouldn’t but less experienced programmers might). In
this case you’d have to upload multiple copies of the placeholder image.
And if the placeholder image changes, all files would need to be
rewritten.

Say I have a CMS storing data about a site. A page may have images that
appear on other pages. To normalise the database you would need a
separate table for the images. Again, less experienced users may store
multiple copies of the images.

Geoff Berrow (put thecat out to email)
It’s only Usenet, no one dies.
My opinions, not the committee’s, mine.
Simple RFDs http://www.ckdog.co.uk/rfdmaker/

A(Answer):

Tim Streater wrote:

In article <4L******************************@comcast.com>,
Jerry Stuckle <js*******@attglobal.netwrote:

>Geoff Berrow wrote:

>>Message-ID: <8O******************************@comcast.comfro m Jerry
Stuckle contained the following:

Why? Why would I *want* to put non-relational data in a relational
database? Why would I *want* to use a database as a filesystem?
>
Just saying "it works fine" is not enough.
>
Because it IS RELATIONAL. It is related to other data in the database.
If there were functions that could extract meta data about the image
(filename, size, type etc) then I think you would have a point. As it
is, you are simply using the database /as/ a filesystem when it clearly
isn’t. Now that’s not to say that that is a bad idea necessarily, I can
see arguments for adopting this approach (portability and ease of
maintenance for example) as well as arguments against.

But it is relational. Every post in here has had comments about storing
the path to the file in the database. So if the path is relational
data, why isn’t the data?

Don’t think I was talking about storing the path. Definitely the file
itself, in my example.

— tim

Tim,

Sure, it works fine. As I said, I’ve done it a lot of times. And yes,
there are some really good reasons for keeping it in a database.

You need to design carefully to have good response, however. Generally
I’ve found it helps to keep the image/scanned doc/whatever in a separate
table consisting only of the id, the blob and what you will need only
when you display it (i.e. for an image you might want the size). Other
things like a description, etc. keep in its own table. This keeps the
load down on the server and makes for faster response.

But this is still off topic in a PHP newsgroup. A database newsgroup
would be better.


==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================

A(Answer):

Geoff Berrow wrote:

Message-ID: <4L******************************@comcast.comfro m Jerry
Stuckle contained the following:

>>If there were functions that could extract meta data about the image
(filename, size, type etc) then I think you would have a point. As it
is, you are simply using the database /as/ a filesystem when it clearly
isn’t. Now that’s not to say that that is a bad idea necessarily, I can
see arguments for adopting this approach (portability and ease of
maintenance for example) as well as arguments against.

But it is relational. Every post in here has had comments about storing
the path to the file in the database. So if the path is relational
data, why isn’t the data?

That’s beside the point. (well my point anyway) A one hour video
documentary might be relational also, would you store that in a db too?

Stuff in a database can usually be processed in some way (which is why I
added the caveat about functions that may be able to extract or
manipulate image data)

Not necessarily. There’s a lot of data in a database which is just
retrieved. For instance, do you normally search on every field in every
table? I don’t. I.E. it’s rather uncommon to "process" a street
address. You store it and retrieve it. Very seldom do you actually
search on it.

Another thing we haven’t talked about is data redundancy and
normalisation.

Let’s say you have a membership list. Some people have provided an
image others haven’t and you decide to use a placeholder image instead
(ok I’m sure /you/ wouldn’t but less experienced programmers might). In
this case you’d have to upload multiple copies of the placeholder image.
And if the placeholder image changes, all files would need to be
rewritten.

Not if you’ve created the database properly you don’t. You can easily
have a single placeholder image and have multiple members point at that
same image.

Say I have a CMS storing data about a site. A page may have images that
appear on other pages. To normalise the database you would need a
separate table for the images. Again, less experienced users may store
multiple copies of the images.

You’re just describing a normal many-to-many relationship, which, in a
normalized database, is always implemented with at least three tables.
In this case the page table, the image table and a link table. Just SOP.

And just because someone is less experienced and creates a bad design
doesn’t mean that it’s a bad idea. That person could also create a
separate directory in the file system for each page – and store multiple
copies of the image there. Does that mean it’s a bad idea to use the
file system to store images?


==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================

A(Answer):

Geoff Berrow wrote:

If there were functions that could extract meta data about the image
(filename, size, type etc) then I think you would have a point. As it
is, you are simply using the database /as/ a filesystem when it clearly
isn’t. Now that’s not to say that that is a bad idea necessarily, I can
see arguments for adopting this approach (portability and ease of
maintenance for example) as well as arguments against.

Thank you Geoff for some sensible input.

>>A typical idiot spouting off about something about which she knows
nothing.

Ad hominem remarks do nothing for your argument Jerry.

Quite, nor does banging on about X years experience.


"Checking identity papers is a complete waste of time. If anyone can
be counted on to have valid papers, it will be the terrorists".

A(Answer):

Jerry Stuckle wrote:

Sure, it works fine. As I said, I’ve done it a lot of times. And yes,
there are some really good reasons for keeping it in a database.

Such as?

You need to design carefully to have good response, however. Generally
I’ve found it helps to keep the image/scanned doc/whatever in a separate
table consisting only of the id, the blob and what you will need only
when you display it (i.e. for an image you might want the size). Other
things like a description, etc. keep in its own table. This keeps the
load down on the server and makes for faster response.

Or you could go one better, and store the blob in a separate "database".
One accessed with "readfile()".

But this is still off topic in a PHP newsgroup. A database newsgroup
would be better.

Welcome to the wonderful world of cross-posting.


"Checking identity papers is a complete waste of time. If anyone can
be counted on to have valid papers, it will be the terrorists".

A(Answer):

There’s a lot of ranting going on here – strange. Anyway, check out
the link below to store binary data in MySQL. Another solution would
be to create a table (files or whatever), and have fields like id,
name, description, category, path. In the path field, you could put
the location of the file (example: /home/nosferatum/uploaded_files). I
do this same thing on one of the websites I developed. Hope that
points you in the right direction.

http://www.onlamp.com/pub/a/php/2000…php_mysql.html

A(Answer):

BlenderStyle wrote:

There’s a lot of ranting going on here – strange. Anyway, check out

[snip file as blob, file as file]

The ranting is all about which of these two methods is better.


"Checking identity papers is a complete waste of time. If anyone can
be counted on to have valid papers, it will be the terrorists".

A(Answer):

In article <jl*******************@newsfe7-gui.ntli.net>,
Mary Pegg <in*****@invalid.comwrote:

BlenderStyle wrote:

There’s a lot of ranting going on here – strange. Anyway, check out

[snip file as blob, file as file]

The ranting is all about which of these two methods is better.

Horses for courses as I tried to point out.

— tim

A(Answer):

Tim Streater wrote:

In article <jl*******************@newsfe7-gui.ntli.net>,
Mary Pegg <in*****@invalid.comwrote:

>BlenderStyle wrote:

There’s a lot of ranting going on here – strange. Anyway, check out

[snip file as blob, file as file]

The ranting is all about which of these two methods is better.

Horses for courses as I tried to point out.

Yes, files in the filesystem, data in the database.


"Checking identity papers is a complete waste of time. If anyone can
be counted on to have valid papers, it will be the terrorists".

A(Answer):

Mary Pegg wrote:

Tim Streater wrote:

>In article <jl*******************@newsfe7-gui.ntli.net>,
Mary Pegg <in*****@invalid.comwrote:

>>BlenderStyle wrote:

There’s a lot of ranting going on here – strange. Anyway, check out
[snip file as blob, file as file]

The ranting is all about which of these two methods is better.

Horses for courses as I tried to point out.

Yes, files in the filesystem, data in the database.

And what do files contain? (Let me give you a hint. It’s a four letter
word which starts with "DA" and ends with "TA".


==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================

A(Answer):

Jerry Stuckle wrote:

Mary Pegg wrote:

>Yes, files in the filesystem, data in the database.

And what do files contain? (Let me give you a hint. It’s a four letter
word which starts with "DA" and ends with "TA".

You’ve already admitted the potential problems associated with sticking
large amounts of binary data into the database.

So far your arguments in favour seem to be (a) it works (b) it used
to work back in the 80s, too.


"Checking identity papers is a complete waste of time. If anyone can
be counted on to have valid papers, it will be the terrorists".

A(Answer):

Mary Pegg wrote:

Jerry Stuckle wrote:

>Mary Pegg wrote:

>>Yes, files in the filesystem, data in the database.

And what do files contain? (Let me give you a hint. It’s a four letter
word which starts with "DA" and ends with "TA".

You’ve already admitted the potential problems associated with sticking
large amounts of binary data into the database.

I have? Where? I did say it requires careful design for best results.
But then if you’re going to have 100K images you’ll have to design your
filesystem layout accordingly. 100K images in one directory? Right…

So far your arguments in favour seem to be (a) it works (b) it used
to work back in the 80s, too.

No, I gave you several good reasons as to why it’s a better way.
However, all you’ve done is say "data in a database and files in a
filesystem".

But files are just containers for data.

And obviously you’ve never tried it, so you really have no idea about
what you speak.

Followups set to comp.lang.mysql. This is off-topic in this group, and
I won’t discuss it further here. If you want to discuss it, go to the
appropriate newsgroup.


==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================

A(Answer):

Jerry Stuckle wrote:

No, I gave you several good reasons as to why it’s a better way.

Sorry, I missed them. Somebody else came up with portability.

So if you could briefly recap? If storing binary files in the database
really is a better way of doing things then I want to know. And all the
PHP coders on another mailing list I’m on will want to know too, because
currently when this question comes up they unanimously advise the questioner
to use the filesystem to store files.

And obviously you’ve never tried it, so you really have no idea about
what you speak.

What exactly would I learn from doing it? That it works? I can see that.
I don’t need to do it. I don’t need to fry an egg in a saucepan to see that
it can be done; the fact that I’ve never done it doesn’t invalidate my
opinion that by and large frying eggs is best done in frying pans, and
that I will continue to use saucepans for heating up sauces.

Followups set to comp.lang.mysql. This is off-topic in this group, and

A) it’s in both groups and B) it’s a scripting decision, it’s not a
mysql-specific discussion.

Anyway, you can continue to discuss it in comp.lang.mysql, I’ll carry on
in comp.lang.php, we can both be happy.


"Checking identity papers is a complete waste of time. If anyone can
be counted on to have valid papers, it will be the terrorists".

A(Answer):

Mary Pegg wrote:

Peter Chant wrote:

>photo_id=123456 lives at /data_dir/1/2/3/4/5/small.jpg.

Stick it in /data_dir/123456/small.jpg.

Yes, that does seem rather obvious. There was probably some reason why I
coded it the way I did. I think I was trying to avoid having one directory
with potentially thousands of sub-directories. Of course, with the scheme
I used there are still thousands of sub-directories in the tree created!

Pete


http://www.petezilla.co.uk

A(Answer):

Peter Chant wrote:

Mary Pegg wrote:

>Peter Chant wrote:

>>photo_id=123456 lives at /data_dir/1/2/3/4/5/small.jpg.

Stick it in /data_dir/123456/small.jpg.

Yes, that does seem rather obvious. There was probably some reason why I
coded it the way I did. I think I was trying to avoid having one
directory with potentially thousands of sub-directories.

All depends on the scale, I guess.


"Checking identity papers is a complete waste of time. If anyone can
be counted on to have valid papers, it will be the terrorists".