|
OK - here's the model I want everyone to know about... 1) Communicating to a back end system, and having a sacrificial lamb system sitting on the web is a turn on to all supermodels! They like it because the front end can be re-built with data from the back end, while the back end does what it always did. Only case where this may not work is B2B where they need access to the MOST recent info 2) Since the E-commerce front end can spend 100% of it's activities on selling stuff, connecting into it and sending info every 10 minutes works just fine. Keep one good backup handy in a save file in the back end, and if/when the site goes belly up - take the backup, re-build the site as if it were brand new, and re-synchronize the data to the back end. User ID's & PW's - should only be a few of them active - all the rest should be disabled. For E-Commerce app's (higher traffic) this works. For high traffic B2B - maybe use the same technique, and keep a copy of the live data on the web server, and trigger something (Sounds like a DB2 technique!) it to DDM or data queue or whatever the changed records to homebase. At all costs, try not to have traffic get to your bread and butter machine!! Andrew Borts / E-Commerce Project Leader Seta Corporation 6400 East Rogers Circle Boca Raton, FL 33499 E-mail: Andrewb@setacorporation.com Corporate web site http://www.setacorporation.com E-Commerce web site http://www.palmbeachjewelry.com Voice: 561-994-2660 Ext. 2211 / Fax: 561-997-0774 -----Original Message----- From: Evan Harris [SMTP:spanner@ihug.co.nz] Sent: Friday, May 04, 2001 3:42 PM To: WEB400@midrange.com Subject: RE: Hey Guys - people actually think that I know what I'm talking about... Brad Yes I was talking about more than just the data. User profiles, Hosts tables, the whole shebang. Agreed you have to decide which is the lesser of two evils - but sometimes it is not your decision. It seems you are in the fortunate position of deciding at the moment It sound like the system is fairly static and not a lot happens on it, otherwise your approach would be somewhat more problematic. Regards Evan Harris >Evan, > >You'll have to explain more what you are talking about. I'm talking data, >it sounds like you're talking system settings, etc. > >Again, you need to decide which is the lesser of two evils. Being down for >an hour to do a system save once a month, or not being able to restore if >your machine crashes. I choose the first. No amount of reasoning will be >able to convince me that doing that one hour a month to do backups is more >important than the customer wanting 24/7 no matter what, even if it means >total disaster and the inability to get anything back. > >Of course, if the customer was so blind that they didn't think of that, I >would specifically put in my contract that they declined the backup option >and that any rebuilding of the system as a result of a crash would be >charged triple time rates. > >Brad > > > > Brad > > > > To be honest I meant a system rebuild :) If anyone still does > > these these > > days. I take it from your comments that the webserver is > > easily rebuilt > > somehow, and from that point of view, a recovery could be > > accomplished > > using scripts that rebuild things rather than restoring. Recovery and > > restore are not necessarily the same thing even though the > > point is often > > missed >+--- >| This is the WEB400 Mailing List! >| To submit a new message, send your mail to WEB400@midrange.com. >| To subscribe to this list send email to WEB400-SUB@midrange.com. >| To unsubscribe from this list send email to WEB400-UNSUB@midrange.com. >| Questions should be directed to the list owner/operator: david@midrange.com >+--- +--- | This is the WEB400 Mailing List! | To submit a new message, send your mail to WEB400@midrange.com. | To subscribe to this list send email to WEB400-SUB@midrange.com. | To unsubscribe from this list send email to WEB400-UNSUB@midrange.com. | Questions should be directed to the list owner/operator: david@midrange.com +--- +--- | This is the WEB400 Mailing List! | To submit a new message, send your mail to WEB400@midrange.com. | To subscribe to this list send email to WEB400-SUB@midrange.com. | To unsubscribe from this list send email to WEB400-UNSUB@midrange.com. | Questions should be directed to the list owner/operator: david@midrange.com +---
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.