On Sat, 3 Mar 2007, steve wrote:
Also, when you hit the 1024 image limit you have to think about
directory schema to store the images, as the linux filesystem (and also
on other 32 bit systems) will start getting slow, until things like ls
will just give you an error.
We have a system (I didn't
# martin@bugs.unl.edu.ar / 2007-03-03 09:18:08 -0300:
> We have a system (I didn't work on it, just maintaining it) that has
> about 1100 images in a directory. I think we aren't seen any problems
> just because it's on a 64bit system.
You should test that assumption.
--
How many Vietnam vets
Also, when you hit the 1024 image limit you have to think about
directory schema to store the images, as the linux filesystem (and also
on other 32 bit systems) will start getting slow, until things like ls
will just give you an error.
We have a system (I didn't work on it, just maintaining it) t
>> > At 10:01 AM -0500 3/1/07, markw@mohawksoft.com wrote:
tedd said:
>Well... it's not just me, but from what I've learned and read over the
> years.
>
> Your claim is that in ALL cases using a file system to store images
is preferable to using a database. As such, you claim that using a
On Sat, 2007-03-03 at 08:22 -0500, markw@mohawksoft.com wrote:
> > On Fri, 2007-03-02 at 22:53 -0500, markw@mohawksoft.com wrote:
> >> > On Fri, 2007-03-02 at 17:31 -0500, markw@mohawksoft.com wrote:
> >> >> > Your claim is that in ALL cases using a file system to store images
> >> >> > is preferab
> On Fri, 2007-03-02 at 22:53 -0500, markw@mohawksoft.com wrote:
>> > On Fri, 2007-03-02 at 17:31 -0500, markw@mohawksoft.com wrote:
>> >> > Your claim is that in ALL cases using a file system to store images
>> >> > is preferable to using a database. As such, you claim that using a
>> dB
>> >> > f
steve wrote:
As a newbie, is storing an image in a dB a "good" thing or a "bad" thing?
I tend to go with "depends". We actually store files in a DB in
development, as those machines are separate from the grid. Since some
are windows, linux, and MacOS, it is far easier to store in a DB than
ha
On Fri, 2007-03-02 at 22:53 -0500, markw@mohawksoft.com wrote:
> > On Fri, 2007-03-02 at 17:31 -0500, markw@mohawksoft.com wrote:
> >> > Your claim is that in ALL cases using a file system to store images
> >> > is preferable to using a database. As such, you claim that using a dB
> >> > for storin
> On Fri, 2007-03-02 at 17:31 -0500, markw@mohawksoft.com wrote:
>> > Your claim is that in ALL cases using a file system to store images
>> > is preferable to using a database. As such, you claim that using a dB
>> > for storing images is "bad" practice.
>>
>> That is fairly close to my profession
On Fri, 2007-03-02 at 17:31 -0500, markw@mohawksoft.com wrote:
> > Your claim is that in ALL cases using a file system to store images
> > is preferable to using a database. As such, you claim that using a dB
> > for storing images is "bad" practice.
>
> That is fairly close to my professional opi
>> It is funny, but most people don't get the fact that SQL databases are
>> not
>> the best way to store data. They are designed to select algebraic
>> relationships from a data set. They are designed to ensure accuracy of
>> the
>> relationships and the integrity of the data.
>
> Like blobs in se
>> > I'm making assumptions about the layout again. The database will
>> > likely already have the table files opened, but will need a seek to
>> > get the data. The webserver will have to do an additional seek (I was
>> > assuming on a far slower drive system, and likely twice for stat and
>> > re
On Saturday 03 March 2007 00:00, Roman Neuhauser wrote:
> # [EMAIL PROTECTED] / 2007-03-02 21:37:48 +0100:
> > However... 6000 small files (and a sub if obliged) I cannot see one heck
> > of a good reason NOT to hold storage in a database... Imagine the rotten
> > backup cyclus.
>
> I cannot imagin
# [EMAIL PROTECTED] / 2007-03-02 21:37:48 +0100:
> However... 6000 small files (and a sub if obliged) I cannot see one heck of a
> good reason NOT to hold storage in a database... Imagine the rotten backup
> cyclus.
I cannot imagine it. What was the problem?
--
How many Vietnam vets does it t
> I'm making assumptions about the layout again. The database will
> likely already have the table files opened, but will need a seek to
> get the data. The webserver will have to do an additional seek (I was
> assuming on a far slower drive system, and likely twice for stat and
> read).
I'm not
It is funny, but most people don't get the fact that SQL databases are not
the best way to store data. They are designed to select algebraic
relationships from a data set. They are designed to ensure accuracy of the
relationships and the integrity of the data.
Like blobs in separate files, this
>> > Not in my environment. All db servers have RAID 10 over 8 SCSI 15K
>> > disks. Pulling from them is always faster than a webserver pulling
>> > from its SATA drive.
>>
>> That's not exactly an apples to apples comparison.
>
> That is true, and sort of the point.
Not really, anything that you
>> > At 10:01 AM -0500 3/1/07, markw@mohawksoft.com wrote:
>>
>>> If you are open to honestly consider, then I shall provide a couple
>>> of examples. But if I do and you do not agree, then your only
>>> recourse will be to *prove* otherwise.
>>>
>>> So, what say you?
>>
>>Absolutely, I'm all
> But storing them in the DB invariably ends up with too many issues
> involving DB storage size and query buffer size, compounded by data
> escaping/security issues.
This on the other hand... I'm a newbie, whatever your saying, BUT and it is a
big one; The data has to be escaped anyway, the bina
On Friday 02 March 2007 21:13, tedd wrote:
> At 7:52 PM +0100 3/2/07, Børge Holen wrote:
> >On Thursday 01 March 2007 22:24, Richard Lynch wrote:
> > > I believe that for a newbie, it would be easier to use the filesystem
> >>
> >> rather than the DB.
> >
> >THAT on the other hand is BS! not to j
At 7:52 PM +0100 3/2/07, Børge Holen wrote:
On Thursday 01 March 2007 22:24, Richard Lynch wrote:
> I believe that for a newbie, it would be easier to use the filesystem
rather than the DB.
THAT on the other hand is BS! not to jerk around with you, but no and HELL no.
Storing in the databas
At 1:49 PM -0500 3/2/07, Brad Bonkoski wrote:
Overall this has been a cool and interesting thread. For the most
part, I would say I side with Mark, but again the fatal flaw appears
to be the insistence that one approach is right in 100% of the
time...which 99% of the time is false.
-B
Brad
On Friday 02 March 2007 14:48, tedd wrote:
> At 5:24 PM -0600 3/1/07, Richard Lynch wrote:
> >On Wed, February 28, 2007 6:41 pm, Robert Cummings wrote:
> >> What about when you need to share those files across a 50 node
> >> network?
> >> I'd keep it in a database, then when I need it cache a lo
On Thursday 01 March 2007 22:24, Richard Lynch wrote:
> I have reflected upon this thread for awhile now.
>
> I believe that the only "new" thing I have to add is for newbies.
>
> I believe that for a newbie, it would be easier to use the filesystem
> rather than the DB.
THAT on the other hand is
On Fri, 2007-03-02 at 13:49 -0500, Brad Bonkoski wrote:
>
> Overall this has been a cool and interesting thread. For the most part,
> I would say I side with Mark, but again the fatal flaw appears to be the
> insistence that one approach is right in 100% of the time...which 99% of
> the time is
At 10:28 AM -0800 3/2/07, steve wrote:
Putting the files in the DB doesn't always remove extra cleanup/management
stuff. Sometimes the database stores binary objects as files and sometimes
they don't get deleted correctly.
I'm dying to know what database you are using that puts every blob in
a
For the record, I will *never* say one size fits all in the realm of
computer programming...
Consideration 2
If your project is to supply images across several web servers on
different host, then you are caught in a sync problem. Images stored
in a file system must be stored on a local host
> Not in my environment. All db servers have RAID 10 over 8 SCSI 15K
> disks. Pulling from them is always faster than a webserver pulling
> from its SATA drive.
That's not exactly an apples to apples comparison.
That is true, and sort of the point.
However, the whole thing started because some
> At 10:01 AM -0500 3/1/07, markw@mohawksoft.com wrote:
If you are open to honestly consider, then I shall provide a couple
of examples. But if I do and you do not agree, then your only
recourse will be to *prove* otherwise.
So, what say you?
Absolutely, I'm all about computer science. G
On Fri, 2007-03-02 at 11:01 -0500, markw@mohawksoft.com wrote:
I'm going to mostly skip your drivel... and cut straight to a short
comment and an example proving the invalidity of your general argument
that the filesystem is always a better place to store image content.
> > There we go... you onl
>> I highly recommend a dark ale or two
>> to bring down the core temperature :)
A good Zinfendel, sit back and relax.
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
> On Thu, 2007-03-01 at 19:42 -0500, markw@mohawksoft.com wrote:
>> > On Thu, 2007-03-01 at 21:08 +0100, Roman Neuhauser wrote:
>> >> # [EMAIL PROTECTED] / 2007-03-01 12:46:09 -0500:
>> >> > At 10:01 AM -0500 3/1/07, markw@mohawksoft.com wrote:
>> >> > >In this discussion I have stated reasons why
At 5:24 PM -0600 3/1/07, Richard Lynch wrote:
On Wed, February 28, 2007 6:41 pm, Robert Cummings wrote:
What about when you need to share those files across a 50 node
network?
I'd keep it in a database, then when I need it cache a local copy on
the
filesystem. Then I can just check the time
> I highly recommend a dark ale or two
> to bring down the core temperature :)
Amen!
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
On Thu, 2007-03-01 at 19:42 -0500, markw@mohawksoft.com wrote:
> > On Thu, 2007-03-01 at 21:08 +0100, Roman Neuhauser wrote:
> >> # [EMAIL PROTECTED] / 2007-03-01 12:46:09 -0500:
> >> > At 10:01 AM -0500 3/1/07, markw@mohawksoft.com wrote:
> >> > >In this discussion I have stated reasons why it is
>> > To follow up with Ted, nobody said using the filesystem is bad,
>>
>> No, it is the most efficient way.
>
> Not in my environment. All db servers have RAID 10 over 8 SCSI 15K
> disks. Pulling from them is always faster than a webserver pulling
> from its SATA drive.
That's not exactly an appl
> To follow up with Ted, nobody said using the filesystem is bad,
No, it is the most efficient way.
Not in my environment. All db servers have RAID 10 over 8 SCSI 15K
disks. Pulling from them is always faster than a webserver pulling
from its SATA drive.
Also, there is issue of going to the da
> On Thu, 2007-03-01 at 21:08 +0100, Roman Neuhauser wrote:
>> # [EMAIL PROTECTED] / 2007-03-01 12:46:09 -0500:
>> > At 10:01 AM -0500 3/1/07, markw@mohawksoft.com wrote:
>> > >In this discussion I have stated reasons why it is a bad idea. No one
>> has
>> > >come up with a counter point which can
On Wed, February 28, 2007 6:41 pm, Robert Cummings wrote:
> What about when you need to share those files across a 50 node
> network?
> I'd keep it in a database, then when I need it cache a local copy on
> the
> filesystem. Then I can just check the timestamp in the database to see
> if the file h
On Wed, February 28, 2007 4:04 pm, Mark wrote:
> Kevin Waterson wrote:
>
>> This one time, at band camp, zerof <[EMAIL PROTECTED]> wrote:
>>
>>> It is not a good practice to store pictures in DataBases, use
>>> links,
>>> instead of.
>>
>> Rubbish, where are your benchmarks?
>
> It has almost nothi
I have reflected upon this thread for awhile now.
I believe that the only "new" thing I have to add is for newbies.
I believe that for a newbie, it would be easier to use the filesystem
rather than the DB.
True, you then have to do some extra cleanup/management work for
deleted records, so that
On Thu, 2007-03-01 at 21:08 +0100, Roman Neuhauser wrote:
> # [EMAIL PROTECTED] / 2007-03-01 12:46:09 -0500:
> > At 10:01 AM -0500 3/1/07, markw@mohawksoft.com wrote:
> > >In this discussion I have stated reasons why it is a bad idea. No one has
> > >come up with a counter point which can only be s
# [EMAIL PROTECTED] / 2007-03-01 12:46:09 -0500:
> At 10:01 AM -0500 3/1/07, markw@mohawksoft.com wrote:
> >In this discussion I have stated reasons why it is a bad idea. No one has
> >come up with a counter point which can only be served by a database and
> >thus proves me wrong. I think that says
At 10:01 AM -0500 3/1/07, markw@mohawksoft.com wrote:
In this discussion I have stated reasons why it is a bad idea. No one has
come up with a counter point which can only be served by a database and
thus proves me wrong. I think that says something.
Contradiction is not a sign of falsity, nor
Information on image storage in DB's
http://www.webmasterworld.com/forum88/9091.htm
Quoting markw@mohawksoft.com:
> >> > >> The web browser sees an image as a single HTTP request. Invoking
> >> the PHP
> >> > >> script engine, parsing the script, and executing a SQL query to
> >> retrieve
> >> >
Rubbish, where are your benchmarks?
^^ whoever wrote that needs to check the manual before you make bold
statements and my friend it is not 'Rubbish'
On 2/28/07, Richard Lynch <[EMAIL PROTECTED]> wrote:
On Tue, February 27, 2007 8:03 pm, Kevin Waterson wrote:
> This one time, at band camp, "R
> At 5:04 PM -0500 2/28/07, Mark wrote:
>>Images are typically best supported in the form of files. They are more
>>easily manipulated by external tools.
>>-snip-
>>I could go on, but it should be clear enough that putting images in a
>>database is not a good idea.
>
> It's clear enough to me that
At 5:04 PM -0500 2/28/07, Mark wrote:
Images are typically best supported in the form of files. They are more
easily manipulated by external tools.
-snip-
I could go on, but it should be clear enough that putting images in a
database is not a good idea.
It's clear enough to me that it's not a b
>> > >> The web browser sees an image as a single HTTP request. Invoking
>> the PHP
>> > >> script engine, parsing the script, and executing a SQL query to
>> retrieve
>> > >> the image from the database is less efficient than letting the web
>> > >> server
>> > >> just send the file.
>
>
> In a si
> On Wed, 2007-02-28 at 22:08 -0500, markw@mohawksoft.com wrote:
>> > On Wed, 2007-02-28 at 17:04 -0500, Mark wrote:
>> >> Kevin Waterson wrote:
>> >>
>> >> > This one time, at band camp, zerof <[EMAIL PROTECTED]> wrote:
>> >> >
>> >> >> It is not a good practice to store pictures in DataBases, use
> >> The web browser sees an image as a single HTTP request. Invoking the PHP
> >> script engine, parsing the script, and executing a SQL query to retrieve
> >> the image from the database is less efficient than letting the web
> >> server
> >> just send the file.
In a simple setup, that is pro
On Wed, 2007-02-28 at 22:08 -0500, markw@mohawksoft.com wrote:
> > On Wed, 2007-02-28 at 17:04 -0500, Mark wrote:
> >> Kevin Waterson wrote:
> >>
> >> > This one time, at band camp, zerof <[EMAIL PROTECTED]> wrote:
> >> >
> >> >> It is not a good practice to store pictures in DataBases, use links,
> On Wed, 2007-02-28 at 17:04 -0500, Mark wrote:
>> Kevin Waterson wrote:
>>
>> > This one time, at band camp, zerof <[EMAIL PROTECTED]> wrote:
>> >
>> >> It is not a good practice to store pictures in DataBases, use links,
>> >> instead of.
>> >
>> > Rubbish, where are your benchmarks?
>>
>> It ha
On Wed, 2007-02-28 at 17:04 -0500, Mark wrote:
> Kevin Waterson wrote:
>
> > This one time, at band camp, zerof <[EMAIL PROTECTED]> wrote:
> >
> >> It is not a good practice to store pictures in DataBases, use links,
> >> instead of.
> >
> > Rubbish, where are your benchmarks?
>
> It has almost
Kevin Waterson wrote:
> This one time, at band camp, zerof <[EMAIL PROTECTED]> wrote:
>
>> It is not a good practice to store pictures in DataBases, use links,
>> instead of.
>
> Rubbish, where are your benchmarks?
It has almost nothing to do with benchmarks.
Images are typically best supporte
On Tue, February 27, 2007 8:03 pm, Kevin Waterson wrote:
> This one time, at band camp, "Richard Lynch" <[EMAIL PROTECTED]> wrote:
>
>> *ALL* of the arguments on this topic, and benchmarks, are in the PHP
>> General archives.
> I am not concerned with past benchmarks done by others, I am asking
> w
This one time, at band camp, "Richard Lynch" <[EMAIL PROTECTED]> wrote:
> *ALL* of the arguments on this topic, and benchmarks, are in the PHP
> General archives.
I am not concerned with past benchmarks done by others, I am asking what
current benchmarks this user has made to make his claim.
Kevi
On Sun, February 25, 2007 8:27 pm, Kevin Waterson wrote:
> This one time, at band camp, zerof <[EMAIL PROTECTED]> wrote:
>
>> It is not a good practice to store pictures in DataBases, use links,
>> instead of.
>
> Rubbish, where are your benchmarks?
In the archives.
Unless your images are teeny-t
This one time, at band camp, zerof <[EMAIL PROTECTED]> wrote:
> It is not a good practice to store pictures in DataBases, use links,
> instead of.
Rubbish, where are your benchmarks?
kevin
--
"Democracy is two wolves and a lamb voting on what to have for lunch.
Liberty is a well-armed lamb c
On 2/25/07, zerof <[EMAIL PROTECTED]> wrote:
Alain Roger escreveu:
> Hi,
>
> i stored all my pictures in my PostgreSQL DB as bytea type.
> Now i would like to know how can i display them in my PHP pages ?
>
> where can i find some example ?
>
> thanks a lot,
>
--
It is not a good
60 matches
Mail list logo
