fenway

the former is for bulk inserts, directly from from a file, for example; the latter just allows for PK collisions; DELAYED is actually what I meant, if you don't need the UID back.

It can be done, but it's preferable to simply include a relative path if at all possible.

See how many rows you're getting back... also, I don't know if _array() defaults to ASSOC.

First way has less for the server to parse; but then you don't get back the ID of the inserted records. Go with "insert2" -- if you're doing bulk inserts, use LOAD DATA INFILE, or the IGNORE attribute.

Not to sound brash, but get it up and running first... I've seen way too many projects plan for phase III without ever getting off the ground.

Not even remotely mysql-related...

You don't -- the "future" is very far away. Leave it be, make sure you abstract the connection strings, and you can fiddle with load balancing later. I've built 100s of websites on the same db server with no issues yet.

If you have to let it go, then so be it... I've been pre-occupied on my end, too, and haven't been able to actually run any other these on my test box... if it ever comes back, let me know.

They're exactly the same, the php function just wraps it.

the former is the mysql function, the latter is the php function.

Whatever you're not optimizing... for example, mysql 5 has merge indices, so that you can use multiple keys on a single table. Sounds great, right? Well what about all those queries where this would be disastrous? Like almost every old query you've ever written? No so simple.

Yes, LAST_INSERT_ID().

Let's ignore the timezone issue for a minute... yes, timediff() return HH:MM:SS, have you proved that you can use this for an interval? There's always the extract() function... and you should be using CURTIME() instead of that craziness with NOW().

And you've checked the grants table to make sure do have this permission?

TIMEDIFF only takes time fields as arguments, don't concat.

Which mysql version?

There are many blogs on optimization, they deal with nitty-gritty things like tables in memory, row cache, etc. It get's really ugly, trust me, you don't want to go there.

You optimize one thing at the expense of another, always.

I don't understand your fascination with performance issues... everything comes at a price.

It's only education if you apply what you learn.

Normalize it as much as reasonably possible, and then fix it when it breaks.

Same question as before, eh? If you can generate summary tables, do so....

If there is an appropriate index in place, you'd be surprised how quickly it will run.

You'd have to check the refman, I have no idea.

I don't see that function, I don't see tmp_name, and don't see you doing it 3 times.