>
> Ave,
>
> "Three: Insert everything and remove duplicates later."
>
> Out of the suggested options, this option is sounding the most sane
> attainable on my end. I don't have a complete grip on how to accomplish
> this, but certainly sounds feasible. Let me look at ways to achieve this.
>
> Than
> On 3/22/07, Roman Neuhauser <[EMAIL PROTECTED]> wrote:
>> # markw@mohawksoft.com / 2007-03-22 08:49:59 -0400:
>> > Tijnema ! wrote:
>> >
>> > > On 3/22/07, Roman Neuhauser <[EMAIL PROTECTED]> wrote:
>> > >>
>> > >>
> markw@mohawksoft.com wrote:
>>>
>>> http://www.postgresql.org/docs/current/static/functions-sequence.html
>>>
>>> It is perfectly safe to use this.
>>
>> In theory that may be true, but can the application developer make any
>> assumption
> markw@mohawksoft.com wrote:
>>> markw@mohawksoft.com wrote:
>>>>> On Sat, 2007-03-17 at 12:19 -0400, Mark wrote:
>>
>>>> There in lies the biggest problem with LAMP, and that's MySQL. The
>>>> architecture of your methodology *on
> markw@mohawksoft.com wrote:
>>> On Sat, 2007-03-17 at 12:19 -0400, Mark wrote:
>> There in lies the biggest problem with LAMP, and that's MySQL. The
>> architecture of your methodology *only* works with MySQL, and not more
>> capable databases like Oracl
> On Sat, 2007-03-17 at 12:19 -0400, Mark wrote:
>> Robert Cummings wrote:
>>
>> > On Sat, 2007-03-17 at 09:43 -0500, Myron Turner wrote:
>> >> Colin Guthrie wrote:
>> >> > Philip Thompson wrote:
>> >> >
>> >> >> For auto increment values, you don't have to specify the id. For
>> >> >> example:
>>
> On Tue, March 13, 2007 7:27 pm, Mark wrote:
>> I have a web session management server that makes PHP clustering easy
>> and
>> fast. I have been getting a number of requests for some level of
>> redundancy.
>>
>> As it is, I can save to an NFS or GFS file system, and be redundant
>> that
>> way.
Just FYI:
I have a couple web sites and I kept getting this bozo submitting comments
with just a bunch of links to porn sites. For a while I didn't notice, but
then Google threatened to drop my blog-bits (adsense) account.
So, I looked at my logs, and the TCP/IP address is 195.225.176.66 and a
qu
> On Mon, 2007-03-05 at 14:48 -0500, markw@mohawksoft.com wrote:
>> > On Mon, 2007-03-05 at 10:16 -0500, Mark wrote:
>> >> Alain Roger wrote:
>> >>
>> >> > Hi,
>> >> >
>> >> > It's amazing that my previous post
> Robert Cummings escribió:
>>> This is engineering, not art class. There are ways to evaluate
>>> solutions
>>> as being better than others.
>>
>> This is computer science, not engineering. There are considerations for
>> one approach over another not necessarily confined to your idea of
>> "effic
> On Mon, 2007-03-05 at 10:16 -0500, Mark wrote:
>> Alain Roger wrote:
>>
>> > Hi,
>> >
>> > It's amazing that my previous post has raised so much consideration
>> about
>> > the fact to store or not pictures into DB.
>>
>> And yet you ask again!? Did you not learn? No good can come from this
>> qu
> 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 datab
> 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" pr
>> 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
>> > 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.
>>&
>> 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:
>> >&
>> > 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
> 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
>>
>
> It's clear enough to me that it's not a bad idea -- it depends upon
> the purpose.
Obviously, I don't agree.
>
> You also said:
>
> At 10:08 PM -0500 2/28/07, markw@mohawksoft.com wrote:
>>No, it just seems like if the only tool you are comfort
>> > >> 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:
>> >>
> 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
> markw@mohawksoft.com wrote:
>> [snip]
>>> seems the perceived problem is being caused by something else?
>>>
>>
>> Sorry, I have to respectfully disagree.
>
> ok :-).
Men of integrity must be able to disgree peacefully. :-)
>
>>
>>
[snip]
>
> seems the perceived problem is being caused by something else?
>
Sorry, I have to respectfully disagree.
I was converting all indexes to string indexes, and simply using
"zend_hash_update" to re-constitute the objects and they simply did not
work. When I scanned indexes strings to test
> markw@mohawksoft.com wrote:
>>> On Sat, July 1, 2006 5:30 pm, Mark wrote:
>>>> If the frames do any sort of processing on the session information, as
>>>> is
>>>> the case with squirrelmail, the last session to exit will overwrite
>>>>
> On Sat, July 1, 2006 5:30 pm, Mark wrote:
>> If the frames do any sort of processing on the session information, as
>> is
>> the case with squirrelmail, the last session to exit will overwrite
>> all the
>> changes made by prior frames. This can corrupt session information or
>> lose
>> versions
> [snip]
> Here is a problem I am seeing,
>
> A browser hits a site the uses frames, for the sake of argument, lets
> call
> this site a squirrelmail web mail server.
>
> The browser seems to spawn a number of requests at the same time (I
> think
> one for each content frame), I get multiple PS_RE
30 matches
Mail list logo
