哪个更快的mysql（查询）或PHP切换语句？

Question

i was wonder if anyone could point me in the right direction . i was wondering which is faster ..... i have a situation on a game im creating were there are over 630,000 combinations and i wanted to know is if my script is going to seek the database for one result , would be quicker then say a large switch statement? .... this game im creating is (im hoping) suppose to be a lightwight hit and i dnt want any problems

<?php
// is this quicker 
mysql_query(....) - meanwhile remeber this table should have anywere from 600,000-630,000 rows
// or is this quicker
switch{
case --
....
case--
....
were here this will be in one page with anywwhere from 600,000 - 630,000 different case's ?
}
?>

Answer 1

php will take ages to parse the page, which will probably make it slower regardless of execution time, which may or may not be slower (thought I'd expect query to be faster here as well). You may also consider associative array instead of switch, if query can do that, but it won't make parsing much faster. And think of memory consumption too.

And you can just try.

Answer 2

I would almost certainly go with the MySQL query, especially if the table(s) are indexed correctly. The switch method will be very hard to maintain - for example, what if someone other than you needed to add a new combination to the switch?

Answer 3

PHP doesn't use switch tables to optimize case selections. It would be the equivalent of a gigantic if-elseif-else... statement.

It's better to use queries to properly indexed tables for this.

Answer 4

Ok, just read that, take it or leave it (don't know what your game looks like).

If that is a high traffic (many users) game/website, I would split data in at least two tables, one holding just ID, some GROUP information and what you call COMBINATION. All other additional data would then be in the second table, accessable over a JOIN to that ID.

table 1
ID | GROUP | COMBINATION
1 | island | ABCDE
2 | house | FGHIJ

table2
ID | MORE INFO
1 | ...
2 | ...

Also I would (if possible) split those GROUPs into table chunks.

// ok, this is an example for ID and range of IDs, but I think you can get it
partition by range (id)
(
PARTITION P1 VALUES LESS THAN (10),
PARTITION P2 VALUES LESS THAN (20)
)

Logical Splitting: - No need to create separate tables - no need to move chunks of data across files

4 main reasons to use partitions: - to make single inserts and selcts faster - to make range selects faster - to help split the data across different paths - to store historical data efficiently - if you need to delete large chunks of data instantly