[UPHPU] MySQL questions?

Mac Newbold mac at macnewbold.com
Fri Apr 23 09:22:21 MDT 2004


Yesterday at 9:53pm, Steve Dibb said:

>>>- caching queries
>>
>> Can you clarify that for me? Do you mean inside MySQL, or in your PHP
>> code?
>
>In PHP.  Or MySQL.  I dunno, actually.  All I know is that PEAR's Cache
>and Cache_Lite are completely undocumented (save the actual php file
>itself, which I don't really wanna dig through to try and understand
>it), and O'Reilly's tutorial that you find when you google for 'php
>cache mysql' makes their own caching functions which doesn't make sense
>to me...  Anyway, a starting point would be nice.

I don't know much at all about PEAR. But I just sent a message with all I
could find about PHP caching, which hopefully will help. I don't know of
any general mysql query caching scheme for PHP, so I won't be covering it
in the meeting, I don't think.

[transactions]
>which runs *amazingly* fast... I've heard of doing rollbacks on commits,
>but maybe that's just a postgres thingie.  I don't have a clue how to do
>that either.

Okay, I'll talk about them. They're a general thing, and MySQL has them.
And you're right... the commits can usually be very fast, sometimes just
as fast as without a transaction, but the rollbacks are where you might
see some performance impact.

>>>- how the file access thing works
>>
>> I'm not sure what you mean here. To which "file access thing" do your
>> refer?
>
>the "User" table has a setting for "File" permissions of some kind ...
>letting the mysql user access the filesystem somehow... again, no clue. :)

This must be for using LOAD DATA INFILE and SELECT INTO OUTFILE. I'll take
a look and try and cover it.

>>>- maybe an intro to table/row permissions?
>>
>> I haven't used them at all, but I could do some research and talk about
>> them briefly if there's time.
>
>me neither -- I'm not sure they're highly used, its just something that
>could be gleaned over.  Or even just feed me an opinion on whether or
>not to use em, and I'll be happy. :)

:) That I can do: In general, don't use them unless you absolutely have
to, because they can slow things [way] down. In practice, I've never had
to use them because most often, the control I am trying to achieve can
better be done in my PHP code than in the database.

This actually is true for a lot of the advanved features in MySQL - if the
only "client" using your database is your PHP code, it is almost always
better just to do it in PHP. The place where those features really come in
handy is when you've got a PHP web site, a Java Applet, a perl report
generator, and a legacy COBOL system that all need to access the database,
and are all expected to obey "the rules" to keep your data consistent. In
that case, the more you can push into the database (or somewhere else
where all four clients can use the same mechanism and code), the better
off you'll be, because otherwise you'd have to implement your controls for
each client, and they'd all have to match and all have to be implemented
correctly to guarantee that the database will stay consistent.

>p.s. I'm pleding $5 to the "Fix the Reply Settings" fund.

They're already fixed, but we can take your $5 anyway, I guess. At least
on the messages I get, there doesn't seem to be a Reply-To header. Does
yours have one? That's odd, but we'll make sure to get it removed right
away.

Mac

;)

--
Mac Newbold		MNE - Mac Newbold Enterprises, LLC
mac at macnewbold.com	http://www.macnewbold.com/



More information about the UPHPU mailing list