realtime connections to an existing database?

Hi there,

I have a question that I'd like to get the opinions of the pros on--

If a company has an existing (very large) database containing client information and all other sorts of information for the company, and they are looking to create an interactive web site for members to update their information etc,-- what do you think about letting the members hit the existing database directly online, as opposed to the website using a "dummy" ODBC that can export data that is then imported into the main database?

Keep in mind that this is a company who is used to dealing with their members on pen and paper, and is completely oblivious to new technology. Would a middle-man, reviewing the information from a dummy data source help prevent any potential catastrophes or just hinder the process? I am under the impression that easing into a transition of this magnitude is much easier than jumping right in.

Also are there any security issues they should be concerned about if there was an open connection to the "real" database?

Thank you for any opinions you can provide on this!

The world of idiot proofing is a complicated one. I personally don't have any problem with letting people loose on the real database. It's increasing the workload doing two databases to catch for user mistakes. The real saviour for any mishaps is doing good backups and keeping them safe. As long as you can trust your backup procedure then you can trust people with using the real database and not a 'dummy' database.

The other side of the coin is permissions, you can't just let all and sundry in to every part of a database (unless you can, then forget the next part). What you need is some way of restricting access. If you're doing a web front end then this is a good place to restrict users. When I say restrict by the way I don't mean completely in the usual sense. It includes the automated checking of database entries by using javascript/PHP/ASP etc to make sure entries that go into the database are logical and sensible.

There's no problem with letting the intended audience loose on the real database as long as you are prepared for any problems that may arise, and try to stop the obvious from even emerging.

First of all consider the load, if there are hundreds of submission it will be impossible to review by hand!
On the other side, if the db is already under heavy load it is wrong to stress it more by adding web requests!
One important thing is to have users connect with the least privileges, I mean that if the user connects to update data in one table, he should be allowed to operate only on that table, another important thing is to validate user input on server side, because client side can be fooled easily, you should use complex validation rules, i.e. the user inserts phone number city and zip code, you should verify that the number is "made by numbers" and the city by char, but also that the zip code and the city match and so on ...
It's long and boring but it pays out!

"Nothing is idiot proof, because idiot is smarter than you!" Quote from a professor.

Added to that. A further quote to prove that nothing is idiot proof.

'An idiot with a computer is an idiot ten times faster.'

What it means is that backups are essential. The only remedy for rectifying an idiot.

This is basically the concept that the company I work for does. We have a large database in which several different departments/locations/personnel need access to real time information about different things going on with the data.
I built a web front end for this but followed these restrictions:
1)The site is protected in two forms, user & password validation and group level access.
2)In most areas, the user only has read permissions to do anything on the site. For the sections that have to send updates/inserts they are severely scrutinized before the data is sent to the database.
Do as much checking on the server side as you can and only do data modifications only where it is absolutely necessary.