suppose you have a database application that connect to a database with 2 tables . in a certain operation the user should add a record in one table and add a corresponding record in the other table (otherwise the data integrity become -for example - incorrect ).
the question is : what prevent a user from using any 3rd party database client ,logging in from there (using their legit user names and password) adding the record to one of the table but not the other.

you said it yourself -- data integrity

do some research on foreign keys

Probably the simplest answer is "application authentication" where the application itself

1. Logs into the database
2. Authenticates the application user
3. Controls what the user can/can't do
4. Makes those changes on behalf of the user using the application's connection to the database

This way the user doesn't need any database login, but if you create one for them it can have different permissions than those that the application has.

-PatP

what about reverse engineering ?
he could reverse engineer the program extracting the username / password needed to log into the database !!!

I suspect not - if the design was proper . . .

If anyone can get to it, a sufficiently talented and dedicated professional can breach it. There is no such thing as absolute security for any application/database/whatnot that can be used. If you want data to be 100% secure, never store it!

Within reason, no one with the necessary talent will spend the necessary time to crack 99.99% of the systems in existance. Since it is FAR easier to use social engineering or a man-in-the-middle variant than brute force against almost every system that I've ever seen deployed, hard core "cracking" like what Jeorge Kabbi is describing is nearly un-necessary anymore.

-PatP

I was once in a meeting with some rather big-wigs from the DoD and the discussion went on and on and on about how this data could be secured.

My cohort and i (invited to provide some technical perspective) had more than enough of this nonsense and he got the floor and offered "It could always be stored in a write-only file - one that no process or code could read". Unfortunately, the 2-star thought this was a fantastic idea (no IT guy this one). This was received with many grins and a few chuckles - until the 2-star realized he'd bit . . . Meeting ended not long after . . .

And no one died . . .

in 1998 i started learning visual basic 6 database programming as a hobby. i remember the possibility of using "stored procedure" to do stuff 100% server side. what about that ?
can we use stored procedure to do everything ? if so will the performance suffer ?