Jim
My tendency would be to recommend making the database (or some
portion of it) web-centric.
That is, a single copy updated from the LAN/extranet or the Web.
Trying to maintain concurrent copies of data is near impossible under
the best of conditions.
If the copies are get of synch... what then... which is right... how
do you determine that... how long does it take... what else goes bad
while you are fixing the problem?
What happens when you change the structure/content of the database
and its copies, and/or the programs which update/maintain them.
There are a multitude of similar issues you must address when trying
to maintain multiple operational copies of a single database.
(Backups are a whole 'nother issue).
It's not so much "putting all your eggs in one basket"... rather
putting "one set of eggs in one of several available baskets"
So, you have;
1 up-to-date database.
if the server (basket) breaks, you move it to another.
data integrity is not compromised.
data concurrency issues disappear
backup/restore/recovery issues are minimized
MHO
Dick
At 9:10 PM -0700 2/23/01, Jim McAtee wrote:
>I've got the following situation:
>
>A real-estate company wants us to develop a suite of browser based
>applications for managing listings, client contact management, billing, etc.
>These applications would be used primarily in-house, but could be accessed
>by employees working from their homes or while traveling, so I guess the
>buzzword to apply to this setup would be 'extranet'. The dbms that will be
>used is MS SQL 7, possibly SQL 2000.
>
>They also have a public website that is on a collocated server in a pricey
>colo facility. They have no desire to bring the hosting of the site onto
>their LAN, for many reasons: bandwidth requirements, security, and
>reliability of the net connection being foremost.
>
>Now, much of the information being updated on the extranet needs to be
>published to the web site (real estate listings) and they want it to get
>there in nearly real-time. When they enter a new listing, they want it on
>the public site within the hour.
>
>Would using SQL replication be a good approach in this situation, or would
>it be better to have the CF extranet applications somehow directly update
>the external db simultaneously? We're looking into SQL replication to
>(hopefully) make the job easier. One problem with the connection to the
>LAN/extranet is that it doesn't have 100% uptime. It's down maybe 1 hour
>per week, so dealing with a loss of connection to the remote server is
>something to consider.
>
>Also, can SQL replication replicate only a 'subset' of a database, rather
>than having to duplicate the db in it's entirety? The reason for this
>question is that the internal database will contain a lot of fairly
>sensitive information, such as customer billing records that need not reside
>in the external database. For security reasons, we'd rather not push that
>data to the public database.
>
>Jim
>
>
>
>
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Structure your ColdFusion code with Fusebox. Get the official book at
http://www.fusionauthority.com/bkinfo.cfm
Archives: http://www.mail-archive.com/[email protected]/
Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
