Re: Call for Suggestions

"Ashley M. Kirchner" wrote: > This is a call for suggestions really. I'm wondering whether anyone > has a[n] (better) idea of how to do the following (aside from what I > thought of already): > > Our company keeps the entire price list online, and I'm in charge of > maintaining the website containing all of those prices. The problem I > have is, whenever prices change, it's a hassle having to go through > certain pages to change it every dang time. What's even more > problematic, is when they completely drop certain services, and/or add > new ones to the list. > > So, the idea I came up with was to put these prices in a database > (probably mySQL), and have the website/pages query the DB every time to > get the prices for a specific product, whatever that may be. > > Problems: > > - If the mySQL server is down, so are all of the prices. This > means I have to build some sort of redundancy for the DB. > Maybe multiple mySQL servers (different machines) where the > web server will just poll, and see which one is operational > before querying? This may also be helpful for load balancing? You'll most likely need multiple web servers before you need multiple database servers. The redundancy may be necessary, but there will likely be other issues if the db goes down. (sessions?) Have error handling in your connection module redirect to a 'sorry, we're having problems page', and email you the problem. Don't just let the page come up with errors and sit there. ;) > > - It may take a while to fetch these prices, on products that have > a long list of prices. (Then again, we all know that Netscape > takes a loooooooong time to display a large table.) Limit your results - don't pull back 200 items on one page (info overload, and people will likely zone out - I know I don't pay attention to pages with 300 items on them). > > - What happens when a service is completely removed from the > price book? I have to update the DB as well. > - And what about when they ADD a new service? Or rename it? > The whole 'service' thing seems a little cloudy here - would this essentially a 'category' (in the general sense) with 'products' below it? If so, putting the 'services' in a table as well would make sense. Oh, I see below that's what you were thinking. It's probably how I'd approach it too, without seeing your data/layout beforehand. ;) > > And to add another twist to this whole idea: if I'm going to a DB > setup, how can I make it so that I don't have to personally change the > prices every time, but instead, have them (them being upper management) > change the prices themselves, and the website gets updated as they do it > (this also avoids me making mistakes on the prices, and/or services). > Also keeping in mind that all of our web servers are unix based, and all > of the machines these people work on, are Win32 based (Windows 95/98/NT) > Beware people putting in their own prices like that - it's often better to have someone else double check things, especially if it will be 'live'. Something they'll probably ask for is a 'staging' area: put the prices in, go to a 'test' area of the site to make sure the prices changed (and are correct), then 'publish' that to the live area. That publishing could be simply moving the data over to 'live' tables so the queries are live, OR... publishing the info to static HTML files. This solves your problem about what to do if the db goes down (tho I suspect you'll have other problems if your database goes down!) and potential speed issues could be avoided. With all due respect, tho, I'd have to say that PHP/MySQL have rarely been a bottleneck for me on 'moderate' equipment (moderate meaning an x86>250mhz or so and a decent disk drive). How much traffic do you anticipate? The 'publishing' to HTML can get sticky if you have more than one webserver on the front end (but you didn't say you had that situation). > > -- > > Description of what I had in mind: > > Have tables that contain the product name/description, and the > different pricing structure. Have the web page generate a dynamic list > of all the services in the DB (as a drop down list). Have that list be > specific queries to whatever the product is in the DB to get the pricing > structure for that product, then generate the page for it. > > This way, when a product gets changed/deleted/added, the list gets > dynamically updated without me having to do anything. Makes sense? > Maybe.... > > -- > > I'm open to suggestions. Right now, I'm redesigning the whole site > and stuff, so I figured, this is as good a time as ever. > > AMK4 > > -- > W | > | I haven't lost my mind; it's backed up on tape somewhere. > |____________________________________________________________________ > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > Ashley M. Kirchner <mailto:ashley@pcraft.com> . > 303.442.6410 x130 > SysAdmin / Websmith . 800.441.3873 x130 > Photo Craft Laboratories, Inc. . eFax 248.671.0909 > http://www.pcraft.com . 3550 > Arapahoe Ave #6 > .................. . . . . Boulder, CO 80303, USA > > -- > PHP General Mailing List (http://www.php.net/) > To unsubscribe, e-mail: php-general-unsubscribe@lists.php.net > For additional commands, e-mail: php-general-help@lists.php.net > To contact the list administrators, e-mail: php-list-admin@lists.php.net -- ========================== Michael Kimsal http://www.tapinternet.com 734-480-9961