Jim
I don't know if what you say really makes a difference.
You say that: "The database sitting on the web is 99% read-only"
Well that is the way the the solution is currently implemented... not
a definition of the problem.
I assume that a database (say, using SQL Server) is running on a
server, somewhere (probably on a dedicated machine). The database is
accessible from both the LAN/extranet and the internet.
Selects/updates/inserts/deletes to the database originate from one or
both of these sources. Both are external (clients) to the SQL
(server).
Other considerations aside, where the client requests originate, do
not matter to the SQL Server.
A client-server relationship is logically the same whether:
they both exist on the same machines
they both exist on separate machines:
tightly coupled
another independent machine on the same LAN
across independent machine, across the world
If there is a situation where the entire database must be cycled and
batch-updated/reported every day, then it may make sense to tightly
integrate the client and server for possible gains in performance.
However, the gains could easily be lost when you consider that you must then:
1) temporarily prevent/encapsulate further updates (Prevent trying
to publish
interrelated data while it is being updated... yielding a corrupted copy)
2) create a copy for publication
3) resume updates
4) publish the (possibly out-of date) copy created in step 2
Why can't you have a single copy, somewhere accessible by all
clients, wherever they may be?
Data security/propriety don't appear to be a problem... after all,
you are publishing the data.
It appears that a universally-accessible location for the database is
required to satisfy the traveling salesmen... a web-centric db would
appear better than:
accessing the LAN/Extranet, then through it, the SQL Server
accessing the Web, through it, the LAN/Extranet, then through it, the SQL
Server
accessing an out of date copy directly on the web
I can think of lots of reasons to keep the database in-house, behind
a firewall... but I didn't detect any of these in this post or your
original.
Dick
At 10:58 PM -0700 2/23/01, Jim McAtee wrote:
>Dick,
>
>Your points are well taken. I agree, I'd much rather work from a single
>database, but the network structure of the situation would seem to preclude
>that approach.
>
>Forget for a moment that the in-house applications are browser based. If
>they were written in VB or C, using a client-server approach and hitting a
>MS SQL database, I'd have pretty much the same questions. How best to get
>that data out to a web server residing on another network?
>
>The database sitting on the web is 99% read-only, with the only data coming
>back in from the web being customer inquiries, where name, phone, etc. need
>to be captured in a db. This data can be isolated in either its own
>table(s), or in another db altogether. Therefore, there's minimal two-way
>updating of the database.
>
>Jim
>
>
>----- Original Message -----
>From: "Dick Applebaum" <[EMAIL PROTECTED]>
>To: "CF-Talk" <[EMAIL PROTECTED]>
>Sent: Friday, February 23, 2001 9:46 PM
>Subject: Re: OT: SQL Replication
>
>
>> 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
