Should I create a new database for a public website when the data already exists?

Question

I am looking for advice on how to create my data schema for a public web site.

Currently, we have an Intranet website where our agents create the data needed for reservations. The data includes tables like Establishments, products, prices per periods, and a typical Users table.

This intranet is already in production.

I've been tasked to create a public web site, where anonymous Joe and Jane will be able to book a reservation without calling one of our agent. The site will offer registration and will display the data available from the Intranet, albeit as read-only.

The public site itself will have some data of its own.

I am a bit reluctant to combine the data from the public site into the same database than our intranet, but most of the information that will be displayed on the public site will come from the pre-entered data from the intranet.

Are there any best practices concerning the separation and sharing of information between a public and a private website?

Answer 1

Write web services to expose the necessary data and other actions, as needed by your site, and deploy the services so that they have access to the database, but can only be accessed by your specific web site (only allow a certain IP to perform actions, etc.).

This gives you access to your data, removes the necessity of creating another schema, syncing data between the two, and eliminates some of the hazards of wiring up your agent's database directly to your web application.

There may be other solutions, but this worked well for my company.

Answer 2

Since its your code thats manipulating the databases, the safety of accessing the internal database from a public facing site really isnt an issue. You just need to make sure you follow safe coding standards to prevent things like sql injection. You can also use in the public facing app, as an extra precaution, a database user name with proper GRANT privileges such that it only has rights to modify certain tables - your sessions table, for example - but not the rights to modify other data.