Connecting external web application with internal database

[Big Charles]

Hi,

We have developed an ASP.NET web application and are planning to host
it in an external Server, which provides us a good bandwidht. We need
to put he web application outside because the bandwidtht that we have
in our local office won't be enough for the number of users that access
to our web app.

But for backup issues, the database server will be in our local office.

Is it possible to connect a web application hosted in an external
server with our database server in our local office?

Will performance decrease?

Is it enough to change in the web.config the conecction string?


<appSettings>
<add key="ConnectionString"
value="server=Server_At_Local_Office;database=An_Oracle_DataBase;user=My_User_01;password=secret;"
/>
</appSettings>

 

[Mark Fitzpatrick]

If the remote server can talk to the office server then you shouldn't have
any issues. Of course you will suffer some latency simply becuase of the
connection distance, but there should be little else. I often will run local
development applications against my remote live databases to ensure that
they work properly with production data. Usually there is a minimal delay
simply due to extended hops across a network, but nothing else. Of course,
some drivers may have heavier communication needs between them and the
source database and that may add extended delays, but I believe you should
be reasonably ok as most network delays I've seen are still only fractions
of a second. You'll definitely want to keep an eye on your usage of code to
ensure you are using the most efficient database methods you can in your
specific circumstances.

 

[Eliyahu Goldin]

Your office network has to publish the database server on an external IP
address. Then it is a good idea to enable connecting to the published
database only from the IP address of the web server.

 

[Alec MacLean]

Big Charles,

If your office bandwidth is already a concern, you probably don't really
want to have the database sitting at the office end of the connection,
particularly if you ever need to use SSL to preserve security.

You _will_ have performance issues as the hosted web app crosses whatever
security boundaries (firewall/DMZ) are in place between itself and your DB
location. At best this will manifest as a (tolerable?) latency/delay -
though this will be variable according to just how much bandwith is
available at that moment. At worst it will cause timeouts.

I would suggest that you keep the database as physically and logically close
to the application as possible and then implement a backup routine to pull a
copy of the DB on a regular schedule.

So long as the DB is not enormous, this can be performed without buying any
fancy software simply by using an FTP script that is run from a batch file
which is in turn called by the Scheduled Tasks (assuming you're using
Windows) - these are using basic supplied Windows features. If you're using
a standard ADSL link, this model should be reasonably efficient as you get
more speed for pulling down to the office than pushing out from the office
to the web.

If the DB grows to a larger size (>100Mb?) then you might want to consider a
different backup model - perhaps the host ISP offers a package for a small
increase in the monthly fee, or perhaps try a dedicated offsite backup
service, etc.

[ For background info, my company hosts it's own webserver, as we have a
leased-line connection. I use a separate server to host SQL server. Both
servers are behind our firewall, with appropriate rules for reaching the web
server with http and https. The various web apps use their web.configs to
store the db connection strings as you have indicated. As the servers are
both on same LAN, this virtually eliminiates any risk of DB latency.

A browser client then only needs to traverse one firewall connection (at our
end) in order to access the site/app.

BTW, I wouldn't recommend running a dev app directly against production data
as another respondee has mentioned, due to the risk of data loss or
alteration. I would export a copy of the production data to a separate Dev
instance. SQL server 2000 upwards (including the free versions) support
multiple instances on the same physical server, so you can easily have a
complete copy available for testing without posing any risk to live data and
without increasing your hardware count/expenditure. ]

Hope that helps.

Al