Joshua J. Kugler wrote:
There is one instance in which it is *not* convenient to store in seperate
files: when you are exporting to another machine (maybe a sub set of data
from an internal server to an external web server) or doing replication.
Very true. We use MySQL to store our blobs for
There is one instance in which it is *not* convenient to store in seperate
files: when you are exporting to another machine (maybe a sub set of data
from an internal server to an external web server) or doing replication.
j- k-
On Wednesday 19 May 2004 01:01 pm, Greg Willits said someth
On Fri, May 21, 2004 at 08:01:31PM -0400, [EMAIL PROTECTED] wrote:
> Luis - you're quite polite so I'll assume that you are ignorant rather than
> prejudiced.
I'm polite since I wanted to be respectful but honest at the same time.
> You have a university email so I'll also assume you're a studen
> Luis - you're quite polite so I'll assume that you are ignorant rather
th
> an prejudiced.
>
> You have a university email so I'll also assume you're a student who
wants > to learn.
>
> So here's your lesson for today: Don't judge people by their cover, or
by > their color, or by their name, or b
Luis - you're quite polite so I'll assume that you are ignorant rather than prejudiced.
You have a university email so I'll also assume you're a student who wants to learn.
So here's your lesson for today: Don't judge people by their cover, or by their color,
or by their name, or by their servic
--- [EMAIL PROTECTED] wrote:
> What I was saying was - everything slows down when
> it gets bigger. However, a lot of work has been put
> into database engines to keep them going fast even
> when they get big, whereas file systems slow down
> considerably when they get bigger.
>
> It's not the st
What I was saying was - everything slows down when it gets bigger. However, a lot of
work has been put into database engines to keep them going fast even when they get
big, whereas file systems slow down considerably when they get bigger.
It's not the storing of the link that's the issue. That's
cc:
Fax to:
05/20/2004 09:55 Subject: Re: BLOB's - General Guidance
> [EMAIL PROTECTED] wrote:
> > Another perspective on the subject of BLOB vs.
> Links.
> >
> > Links are easier to implement and may be an OK way
> to start. However, a file system is really a crude
> database, and I emphasize "crude". It's not very
> good at handling high transaction rates, acces
You might want to read it again. He is saying the performance and consistancy exists
in the database whereas it doesn't in a file system.
--ja
On Thu, 20 May 2004, David Blomstrom wrote:
> > [EMAIL PROTECTED] wrote:
> > > Another perspective on the subject of BLOB vs.
> > Links.
> > >
> >
> [EMAIL PROTECTED] wrote:
> > Another perspective on the subject of BLOB vs.
> Links.
> >
> > Links are easier to implement and may be an OK way
> to start. However, a file system is really a crude
> database, and I emphasize "crude". It's not very
> good at handling high transaction rates, acces
On Thu, May 20, 2004 at 05:45:58PM -0400, [EMAIL PROTECTED] wrote:
> Another perspective on the subject of BLOB vs. Links.
>
> Links are easier to implement and may be an OK way to start. However, a file system
> is really a crude database, and I emphasize "crude". It's not very good at handling
On May 20, 2004, at 2:45 PM, [EMAIL PROTECTED] wrote:
Another perspective on the subject of BLOB vs. Links.
Links are easier to implement and may be an OK way to start. However,
a file system is really a crude database, and I emphasize "crude".
It's not very good at handling high transaction rate
Another perspective on the subject of BLOB vs. Links.
Links are easier to implement and may be an OK way to start. However, a file system is
really a crude database, and I emphasize "crude". It's not very good at handling high
transaction rates, access from multiple machines, or volume.
If your
David Blomstrom wrote:
1. When you talk about including dimensions in image
names, do you mean it literally? For example, if I
create an image in photoshop that measures 150px X
125px, I could save it as horse.jpg, or save it as
horse.150X125.jpg?
Yep, horse.150X125.jpg
And feel free to add any ot
Hello David,
Thursday, May 20, 2004, 2:21:37 AM, you wrote:
DB> --- Hassan Schroeder <[EMAIL PROTECTED]> wrote:
>> Actually, if you include the dimensions in your
>> image *names* --
>> which is a great timesaver -- you can store them as,
>> say
>>
>>ak.200x150.gif
>>
>> and retrieve as
>>
--- Hassan Schroeder <[EMAIL PROTECTED]> wrote:
> Actually, if you include the dimensions in your
> image *names* --
> which is a great timesaver -- you can store them as,
> say
>
>ak.200x150.gif
>
> and retrieve as
>
>SELECT
> img
> , SUBSTRING(img,4,3) AS width
> ,
David Blomstrom wrote:
> then all I have to do is replace $seg with the path to
> the image folder to display my images. The images
> don't even have to be the same size, since I have to
> enter each state's image individually, anyway.
> Actually, it would be more convenient if I could enter
> imag
On May 19, 2004, at 3:12 PM, David Blomstrom wrote:
Suppose I have a field that stores links that look
like this:
images/states/ak.gif"
width="100" height="75" />
images/states/wy.gif"
width="100" height="75" />
and another field that stores image links that look
like this:
images/maps/ak.gif"
widt
On May 19, 2004, at 1:19 PM, David Blomstrom wrote:
All "conventional wisdom" I've ever come across for
this type of
application is that there's no advantage to keeping
the image in the db
itself. Just keep them as files on the server, store
a filename &/or
location in the db if necessary, and use
--- Michael Kruckenberg
<[EMAIL PROTECTED]> wrote:
>
> Having images in the database also makes scaling
> pretty simple in that
> we can add replicated slave machines for reading
> images.
I'm not yet familiar with scaling and "replicated
slave machines," but I'm beginning to see more uses
for
I have an application where I serve out blobs. I store the PDF files in blob fields
for two reasons.
1. I want to make an interface where staff can upload pdf's into the server but not
actually give them access to the server. I use my code to maintain the security of
who gets to write to wh
In a lot of cases storing images on the filesystem makes the most sense.
We store images in a database because we have multiple webservers that
need to both read and write images. Keeping them in MySQL makes this
easy. NFS isn't an option for us.
Having images in the database also makes scaling
On May 19, 2004, at 1:19 PM, David Blomstrom wrote:
I'd like to get some feedback on storing images in
MySQL databases. The stuff I've read so far suggests
that it's fairly difficult to work with images in
MySQL, and they also slow down databases.
I've also read that there isn't much you can do wit
I'd like to get some feedback on storing images in
MySQL databases. The stuff I've read so far suggests
that it's fairly difficult to work with images in
MySQL, and they also slow down databases.
I've also read that there isn't much you can do with
BLOB's that you can't do with PHP manipulating im
--- Greg Willits <[EMAIL PROTECTED]> wrote:
> On May 19, 2004, at 1:19 PM, David Blomstrom wrote:
>
> All "conventional wisdom" I've ever come across for
> this type of
> application is that there's no advantage to keeping
> the image in the db
> itself. Just keep them as files on the server, st
26 matches
Mail list logo
