[GLLUG] Retrieving a row from mysql

[Seth Bembeneck]

The original intent of this application was to have 9 tables per server.
The tables are created with a prefix that the user configures in a
config.php file. This prefix allows for multiple servers to use the same
database, but have their own tables. $stats_table contains the name of
the table, with the prefix (e.g. rso_stats), which is figured out at
runtime.

 

 I'm trying to get multiple servers to use the same tables. To see an
example of this server. check http://dfstats.sdbnetworks.net/dfcw/ and
http://dfstats.sdbnetworks.net/omega/ . Both sites use the same database
and tables. I have to figure out why Omega's site is pulling dfcw's data
though. hopefully will get that done today.

 

I don't know why the author of this script doesn't use a database
abstraction mechanism. I'm just adapting it. I don't know enough
mysql/php to completely re-write the software.

 

Seth

-----Original Message-----
From: jason D. Justman [mailto:justmanj at msu.edu] 
Sent: Tuesday, February 17, 2004 11:36 PM
To: Seth Bembeneck
Cc: 'GGLUG'
Subject: Re: [GLLUG] Retrieving a row from mysql

 

as rodney hampton suggested about using a database abstraction mechanism
(or, if you are really 'reet, write your own if you ever need to do load
balancing with mysql).  ado sends shivvers down my spine, but the pear's
dbi design is pretty decent.  you'll find that doing:

mysql_query(....) or die("error")

gets very tedious, and a consistant entry and failure mode for this case
saves you a lot of time down the road.  likewise, the population of a
result set container will make your life happy, as in never having to
type in multipe mysql_fetch_container/mysql_fetch_object - thus
transferring your focus of database i/o to integration with your
application.

but in general, "total_games AS total_games" isn't need since you aren't
renaming, using as an alias, or doing a join which might shadow upon
return to php.

likewise, adding an index on player_name in your stats table would be a
good idea, since you'll probably be using that.

also, again, its really confusing to see $stats_table.  trust me, unless
you have some amazing need for it - dont use it.  it just makes
maintnence that much harder down the line since there shouldnt need to
be more than one stats table.  any other table that extends the stats
table should be designed for extension, not replacement (again, a proper
design is helpful here in ensuring proper referential integreity).

j
Seth Bembeneck wrote:



 





  _____  



 
_______________________________________________
linux-user mailing list
linux-user at egr.msu.edu
http://www.egr.msu.edu/mailman/listinfo/linux-user
  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.egr.msu.edu/mailman-archives/linux-user/attachments/20040218/3e8bc4b4/attachment.htm