UI -- Web Services -- PL/SQL API

Question

Hi all,
We inherited an existing application, which has this architecture:
UI - C# (Windows forms, not web based), completely DB agnostic
WS - Web services, C#
DB - Oracle 10g, >500 tables
API - PL/SQL
Because the UI is DB blind, few information (parameters) can be sent to the WS, and this forces highly customized WS (thousands of them; hence, low probability of being by other applications in the future). More, each customized WS calls a customized SP.
What I'd like to do is, if not allowed to use generic WS, at least to be allowed to write generic SP (PL/SQL).
Here's a simple example:
say , in a UI an user enter 5 fields. These strings are sent to WS, as input. We know what table and columns the 5 strings will go to, but only in the WS (not in the UI). So, in the WS I can build:
INSERT INTO tableName(c1, ..., c5) VALUES (v1, ..., v5)
and then call a gSP which will merely execute the SQL statement.
The issue here is that some other apps would want to insert other column attributes in the table, and I do not want to write cSP for, say, 2 fields, or 6, etc. Instead, a cWS has to be written.
Any ideas?
Thanks a lot.

Answer 1

user10817976 wrote:
1. What are the pitfalls of dynamic SQL (OK, other than SQL injection, which can be easilly addressed with regular expressions scanning)Dynamic SQL is not a "+Bad Thing+". It is a very useful tool in the toolbox. The problem is how the tool is used - or abused.
SQL injection is basically only a problem with dynamic SQL when it does not use bind variables. To explain. Dynamically creating the SQL is not the problem - you write the (trusted) code that creates the SQL. The problem is when putting end-user input into that SQL. When the input is strung into the SQL, you're not exactly sure what you are adding to the SQL. If the SQL is using bind variables, and you bind the end-user input as variables values - that is safe. End-user input is not parsed as part of the SQL cursor.
2. How big an application APEX can take (as I said, we have 500+ tables, but we are on Oracle 10g)
Actually, I was considering myself looking into APEX. The thing is that we are tied to the existing architecture and will be hard to convince the IT to give it up.APEX is PL/SQL. How many tables do the large PL/SQL systems like Oracle Applications/Financials/etc have?
People often sees APEX as something else. Exactly what else I'm not sure as I deal with questions like "+Why is APEX down?+" when the database is up and running... or "+APEX is not enterprise enough+" when some of the biggest enterprise systems on Oracle is all PL/SQL. Just like APEX.
I have fought the APEX battle on my side since version 1. The developers choice was J2EE. I simply went ahead and did my stuff in APEX and kept on showing what APEX is capable of. Years later and they are sold on APEX.. as there is no denying that it is a lot faster ito development and deployment than J2EE. It is a lost easier, requiring a much smaller skill set (no real knowledge of stateless web architecture). Heck, basic APEX apps only require very little SQL knowledge. It is cheaper as no expensive app servers are needed. It scales, as APEX is PL/SQL and that scales with the database tier.
I do not like everything about APEX. I would have preferred a differently designed and coded run-time system. It is not generic enough as does not provide the flexibility I would like. But despite that - it is the fastest web development environment there is. And one of the most effective ones.
And as it is PL/SQL, it is "+enterprise+" and can scale and can deal with very large databases.