You don't use prepared statement to avoid SQL-injection. You use it to avoid server-side parsing. Make sure you only call prepared statement once per unique SQL in each physical DB-connection? Quit hard to do if you have a connection pool. But this is the way to go for max scalibility.
To avoid parsing is the number one thing here. (using bind variables). Avoiding SQL-injection is just some thing extra you get for free. But this can be achived with statement aswell.
So you think a simple select statement will always bring back the same data in 2 different DB:s. DB:s are too different you can't write one code that fits all.
Any idea what's happening with dynamic SQL ewhen it executes in the DB-server?
Ever heard of hard-parsing/soft-parsing/no-parsing.
You want to scale? Right => The only way to go is static SQL with binds. (Stored procedures even better)
I can't belive how little people know about how the DB-server works.
So do you really believe you use
Prepared statements to minimizes sql injection.
Ever given a thought what's actually happening on the DB-server?
Heard about hard-parsing/soft-parsing/no-parsing?
I wouldn't like to have you near a real DB.
Use stored procedure. That's the only way to go!
This discussion about JAVA/PHP/ASP would be irrelevant if you ha all business logic their.
Some advantages you get by using stored procedures:
1. Security. (Impossible yo by-pass business logic)
2. If you need a Admintoll written in whatever, just plug it in.
3. Transaction handling for free. Are you aware of the huge overhead on letting something like J2EE handle this)
4. Rather then millions of small calls, fewer bigger ones => More scalable system.
5. Less netwoek traffic between DB and application server.
6. Parsing of SQL statement only once. That's right I never ever seen anyone doing this in JAVA. Re-parsing kills the DB.
7. Code-Dependency tree fully controlled.
8. Auditing.
9. Miniumum amonut of locking.
10. Take advantage of the physical layout of tables. (Partitioned tables)
11. The BEST one! Which I can't believe people are still doing: Everything will always be CONSISTENT within a transaction. (for free)
Take a look at your application,
I bet you only have one DB, so where do you think the bottlenecks gone be =>
Use it as efficent as possible => Use stored procedures and have real DB-developers writing you app,
not people who belive they know SQL because the
4 commands.
Just put presentation logic in the middletier. All business logic has to go int the DB.
What would protect the data oterwise.?
Always avoid dynamic-SQL (even inside stored procedures).
Use stored procedure.
That's the only way to go!
This discussion about JAVA/PHP/ASP would be irrelevant if you ha all business logic their.
Some advantages you get by using stored procedures:
1. Security. (Impossible yo by-pass business logic)
2. If you need a Admintoll written in whatever, just plug it in.
3. Transaction handling for free. Are you aware of the huge overhead on letting something like J2EE handle this)
4. Rather then millions of small calls, fewer bigger ones => More scalable system.
5. Less netwoek traffic between DB and application server.
6. Parsing of SQL statement only once. That's right I never ever seen anyone doing this in JAVA.
Re-parsing kills the DB.
7. Code-Dependency tree fully controlled.
8. Auditing.
9. Miniumum amonut of locking.
10. Take advantage of the physical layout of tables. (Partitioned tables)
11. The BEST one! Which I can't believe people are still doing: Everything will always be CONSISTENT within a transaction. (for free)
Take a look at you layoy.
I bet you only have one DB, so where do you think the bottlenecks gone be => Use it as efficent as possible => Use stored procedures and have real DB-developers writing you app, not people who belive they know SQL because the 4 commands.
Just put presentation logic in the middletier.
All business logic has to go int the DB.
What would protect the data oterwise.?
Always avoid dynamic-SQL (even inside stored procedures).
Always, Alw
OBS! 9i Application Server is not their world-class DB.
It's just apache with some java around it.
Som the basically just include the apache PHP-module on the installation CD. Big Deal!
What does it matter if it's JAVA/PHP/ASP/VB/Delph/Coldfusion etc on the front end? As long as you have everything in an ACID DB (Read Oracle). The rest doesnt really matter.
Slashdot Mirror
You don't use prepared statement to avoid SQL-injection. You use it to avoid server-side parsing. Make sure you only call prepared statement once per unique SQL in each physical DB-connection? Quit hard to do if you have a connection pool. But this is the way to go for max scalibility.
To avoid parsing is the number one thing here.
(using bind variables).
Avoiding SQL-injection is just some thing extra you get for free. But this can be achived with
statement aswell.
So you think a simple select statement will always bring back the same data in 2 different DB:s. DB:s are too different you can't write one code that fits all.
Any idea what's happening with dynamic SQL ewhen it executes in the DB-server? Ever heard of hard-parsing/soft-parsing/no-parsing. You want to scale? Right => The only way to go is static SQL with binds. (Stored procedures even better) I can't belive how little people know about how the DB-server works.
So do you really believe you use Prepared statements to minimizes sql injection. Ever given a thought what's actually happening on the DB-server? Heard about hard-parsing/soft-parsing/no-parsing? I wouldn't like to have you near a real DB.
Use stored procedure. That's the only way to go! This discussion about JAVA/PHP/ASP would be irrelevant if you ha all business logic their. Some advantages you get by using stored procedures: 1. Security. (Impossible yo by-pass business logic) 2. If you need a Admintoll written in whatever, just plug it in. 3. Transaction handling for free. Are you aware of the huge overhead on letting something like J2EE handle this) 4. Rather then millions of small calls, fewer bigger ones => More scalable system. 5. Less netwoek traffic between DB and application server. 6. Parsing of SQL statement only once. That's right I never ever seen anyone doing this in JAVA. Re-parsing kills the DB. 7. Code-Dependency tree fully controlled. 8. Auditing. 9. Miniumum amonut of locking. 10. Take advantage of the physical layout of tables. (Partitioned tables) 11. The BEST one! Which I can't believe people are still doing: Everything will always be CONSISTENT within a transaction. (for free) Take a look at your application, I bet you only have one DB, so where do you think the bottlenecks gone be => Use it as efficent as possible => Use stored procedures and have real DB-developers writing you app, not people who belive they know SQL because the 4 commands. Just put presentation logic in the middletier. All business logic has to go int the DB. What would protect the data oterwise.? Always avoid dynamic-SQL (even inside stored procedures).
Use stored procedure. That's the only way to go! This discussion about JAVA/PHP/ASP would be irrelevant if you ha all business logic their. Some advantages you get by using stored procedures: 1. Security. (Impossible yo by-pass business logic) 2. If you need a Admintoll written in whatever, just plug it in. 3. Transaction handling for free. Are you aware of the huge overhead on letting something like J2EE handle this) 4. Rather then millions of small calls, fewer bigger ones => More scalable system. 5. Less netwoek traffic between DB and application server. 6. Parsing of SQL statement only once. That's right I never ever seen anyone doing this in JAVA. Re-parsing kills the DB. 7. Code-Dependency tree fully controlled. 8. Auditing. 9. Miniumum amonut of locking. 10. Take advantage of the physical layout of tables. (Partitioned tables) 11. The BEST one! Which I can't believe people are still doing: Everything will always be CONSISTENT within a transaction. (for free) Take a look at you layoy. I bet you only have one DB, so where do you think the bottlenecks gone be => Use it as efficent as possible => Use stored procedures and have real DB-developers writing you app, not people who belive they know SQL because the 4 commands. Just put presentation logic in the middletier. All business logic has to go int the DB. What would protect the data oterwise.? Always avoid dynamic-SQL (even inside stored procedures). Always, Alw
You mean the filesystem right? Or don't you have any clue why you need a database in the first place?
OBS! 9i Application Server is not their world-class DB. It's just apache with some java around it. Som the basically just include the apache PHP-module on the installation CD. Big Deal!
So in J2EE you work with inconsistent data? Great! Are you aware of what this actually mean?
What does it matter if it's JAVA/PHP/ASP/VB/Delph/Coldfusion etc on the front end? As long as you have everything in an ACID DB (Read Oracle). The rest doesnt really matter.
Don't see the difference here. J2EE is tied to JAVA which is tied to SUN.
Yes but that's just a theory. All databases are far to different to allow that.
So what's the difference between this an traditiona DB-stored procedures? To me it sound like a B-version of stored-procedures.
Where have uou been the last 15 years. This is exactly what every weel-tuned database is doing.