Doubt Regarding Collection Methods

Question

Hello,
I am working on Oracle version 10g Release 2
I wanted to know that how can we find a particular name (person) exists in a Collection..
Below is my Code
DECLARE
TYPE nested_tab IS TABLE OF VARCHAR2(100);
l_tab nested_tab := nested_tab();
BEGIN
SELECT e.ent_id BULK COLLECT INTO l_tab
FROM entity_master e
WHERE e.ent_id IN ('N002208', 'Z002011', 'V002313', 'X002011'..... & so on);
IF l_tab.EXISTS('N002208') THEN
dbms_output.put_line('element exists');
ELSE
dbms_output.put_line('NO element ');
END IF;
END;
ORA-06502 - Numeruc or Value Error
what can be the work around for this...?

Answer 1

Aijaz Mallick wrote:
Ok.
But It would be really helpfull if you Elaborate this Example a Bit...
I mean the I/O part because Quering table also Require I/OANY data that you need to access (in any computer system and language) requires I/O. That data needs to be read from disk (PIO or physical I/O) or buffer cache (LIO or logical I/O) and processed.
So the important part is optimising I/O. If you only need 1MB of data from a 100GB data structure, you do not want to I/O that entire data structure to find that 1MB of data that is relevant to your code.
The answer to this is three fold.
Firstly, you design that data structure optimally. In databases, that means a proper and sound relational database model.
Secondly, you implement that data structure optimally. In databases, that means using the most appropriate physical data model for storing that relational data model. Using the features like indexing, partitioning, index organised tables, and so on.
Lastly, in some cases your requirements will require scanning a large volume of that data structure. Which means that there is no option but to use a lot of I/O. In such a case, parallelising that I/O is important. I/O has inherent latency. Which means idle time for your code, waiting for data to arrive from the I/O system. Parallel processing enables one to address this and increase performance and scalability.
So what do you need to do with your "large" table?
- make sure it is correctly modelled at a logical data model level
- make sure it is optimally implemented physically in Oracle, making best use of the features that the Oracle RDBMS provide
- when your code has to deal with large volumes of data, design and code for parallel processing
& how about Java Part. ..?Java is worse than PL/SQL in this regard as the data path for data to travel from the database layer into Java is longer and slower than the same path to PL/SQL.
Storing/caching that data in the application layer is an attempt to address the cost of this data path. But this is problematic. If another application makes a change to data in the database, the cached data in the application tier is stale - and incorrect. Without the application layer knowing about it.
Storing/caching that data in the application layer means a bigger and more expensive h/w footprint for the application layer. It means that scaling also requires a cluster cache in the application layer to address scalability when more application servers are added. This is complex. And now reintroduce a data path that runs over the network and across h/w boundaries. Which is identical to the data path that existed between the database layer and application layer in the first place.
It also makes the border between the database layer and application layer quite complex as caching data in the application layer means that basic database features are now also required in the application layer. It is an architectural mess. Contains complex moving parts. Contains a lot more moving parts.
None of this is good for robustness or performance or scalability. Definitely not for infrastructure costs, development costs,and support and maintenance costs, either.
In other words, and bluntly put. It is the idiotic thing to do. Unfortunately it is also the typical thing done by many J2EE architects and developers as they have a dangerous and huge lack of knowledge when it comes to how to use databases.