This might be a basic question: I am using a temporary table in some of my php code like so:
CREATE TEMPORARY TABLE ttable( `d` DATE NOT NULL , `p` DECIMAL( 11, 2 ) NOT NULL , UNIQUE KEY `date` ( `date` ) );INSERT INTO ttable( d, p ) VALUES ( '$d' , '$p' );SELECT * FROM ttable;
As we scale up our site, will this ever be a problem? ie, will user1’s ttable & user2’s ttable ever get mixed up & user1 sees user2’s ttable & vice versa? Is it better to create a unique name for each unique temporary table?
thx
It is almost always better to find a different way than using temporary tables.
The only time I would consider them is under the following conditions:
All three of those really go with building some type of generic bulk import routines where the data mapping is defined at run time.
If you find yourself creating temp tables frequently in the application, there’s probably a better way.
Scalability is going to depend on the amount of data being loaded and frequency of temp table usage. For a low trafficked site it might be okay.
We’re in the process of ripping out a ton of temp table usage by a client’s app. 90% of the queries in their system result in a temp table being created. Analysis of all the queries have shown that the original dev used this mechanism simply because they didn’t understand SQL. We’re doing this because performance has radically dropped off as new users are added to the system.
Can you post a use case? Maybe we can help provide an alternate mechanism.
UPDATE:
Now that we have a use case, here is a simple table structure to accomplish what you need.
Table ZipCodes
ZipCode char(5) [or char(10) depending on need]
CityName varchar(50)
*other columns as necessary such as latitude or whatever.
Table TempReadings
ZipCode char(5) [foreign key to the ZipCode table]
ReadingDate datetime
Temperature float (or some equivalent)
To get all the temp readings for a given zip code you would do something like:
if you need info from the main ZipCode table:
add where clauses as necessary. Note that none of the above requires having a separate table per zip code.