Forum Moderators: mack
I plan on adding another page with a listing of physicians by state who offer a niche treatment. Some of those listings will also have my comments next to them along with physician name and website links.
I could just do one page (e.g., www.example.com/ physicians.html), and that would be a mammoth page. However, navigation on this mammoth page would be easy since at the top of the page a visitor could click on his/her state of interest and the page would move to that state's listing (I would use the # command to do that) instead of the user having to scroll all the way down.
Another option (which might help me with Adsense, although I don't expect to get too many visitors to these pages) would be to have many separate subdomains for each of the 50 plus US states and possibly for a few other English speaking countries in the future.
e.g., www.example.com/physicians/Alaska.html
and www.example.com/physicians/California.html
etc...
I would thing that the one page thing is more user and programmer friendly and faster to navigate? I can only put around 5 total Adsense ads on the one page, so I would lose some revenue.
However, are there any other factors I should consider in favor of the multiple page concept before starting this project?
Thanks.
[edited by: encyclo at 2:40 am (utc) on Feb. 11, 2009]
[edit reason] switched to example.com [/edit]
a subdomain would be something such as:
http://alaska.example.com
http://california.example.com
What you had was just a "physicians" directory with a separate page for each state, all on the same domain.
It sounds like you plan to expand your index of physicians, so I would recommend a database-driven site. This will let you add new records with much greater ease than hand-coding hundreds of HTML records.
You could have a "physicians.php" file where the user can select a state, which will return the "physicians.php?state=alaska" with the appropriate data from the database.
Using a database, you can add, delete, and modify reccords easily, and it is generally a much more practical way of storing data.
[edited by: encyclo at 2:39 am (utc) on Feb. 11, 2009]
[edit reason] switched to example.com [/edit]
For example what I would want to acheive would be a page per state, but dont just limit it to one page. I suggest perhaps limiting the number of listings to 20 per page. So if you have only 15 listings for one state it would be one page. If you have 25 it would be 2 pages and so on.
As Webfoo mentioned a database driven site is certainly a good idea. There are in fact database driven directory applications that would allow you to run this sort of website with little or no modifications. there are even some free scripts that would be able to handle this type of site.
You might want to take a look through hotscripts.com from there you can search for a suitable directory script.
I hope this gives you some ideas.
Mack.
I only know basic html and even more basic CSS.
What language would I need to learn (php?) to create a basic database? I want to create something very very basic and fast.
Also, can I put in a World map and people can drag their cursor over the specific country and click on that country to go to that country's record in the database?
Thanks.
For your map idea. I would make an imagemap in HTML that links to your data reccords for that country.
Hey, my website is not data driven. Its only this one section that might require a database. Thats why I want to use the easiest and simplest database type solution, and not spend too much time on learning php as well as mysql if possible. I suppose php (+ msql) is still the best way?
A alternative solution that indexed better in search engines would be nice but the pages aren't critical to the site and it has never been worth the time and effort of reworking them.
