best way to design site...

I would use one page. Theoretically you can write a total web site using one page. The advantage is that it is easier to keep track of and variables do not have to be pasted between pages. This came up about a site I am working on at the Chicago User Group meeting. A good place to get advice. Come on over some time. I use something like. if(something){include(nestedview.php3);} else{include(flatview.php3);} Also look at switch(). > This site will be hosting over 3000 BBS so I would also like to ask is > it better to have one database, with 3000 tables, or split the BBS into > perhaps a dozen tables, but with many more rows, and an extra field > identifying the BBS. Read the MySQL manual for this one. Ted Knudson http://www.automatedcabinets.com http://www.pulsarusa.com > -----Original Message----- > From: Will Macdonald [mailto:wfm@macscan.co.uk] > Sent: Friday, May 19, 2000 10:26 AM > To: php-general@lists.php.net > Subject: best way to design site... > > > Hi everyone on the list, this is my first post here... > > Quick background to question: > I am writing a BBS system for the company I just joined with PHP4 and > MySQL. This will be running on a Linux box. > > Quick question: > What is the best way to approach the issue of designing the system. > Would it be best to have a few fairly large php files that do all the > work, or would it be better to have many smaller scripts each with there > own job. > > For example, the system will offer the choice to switch from nested view > to flat/ chronological view. This could be done by having a php script > for each view, or just one bigger script, and just pass a variable > (view=flat/tree). > > I would like to make the script as efficient as possible. So which > method would be better ? I am wondering if there are issues regarding > opening and closing files, or would one file sit in the cache better ? > > This site will be hosting over 3000 BBS so I would also like to ask is > it better to have one database, with 3000 tables, or split the BBS into > perhaps a dozen tables, but with many more rows, and an extra field > identifying the BBS. > > Will >