While fetching data by query
select * from ALL_ARGUMENTS
It will return two types in DATA_TYPE column
1- TABLE
2- PL/SQL TABLE
I have checked through containing procedure, both types are declared in a similar way.
What is the difference between them?
Example -
Have declaration
TYPE Bom_Revision_Tbl_Type IS TABLE OF Bom_Revision_Rec_Type - PL/SQl TABLE
OBJECT_NAME PKG NAME ARGUMENT_NAME DATA_TYPE
PROCESS_BOM BOM_BO_PUB P_BOM_REVISION_TBL PL/SQL TABLE
TYPE inv_ebi_name_value_pair_tbl IS TABLE OF inv_ebi_name_value_pair_rec - SQL TABLE
OBJECT_NAME PKG NAME ARGUMENT_NAME DATA_TYPE
ID_TO_VALUE INV_EBI_ITEM_HELPER P_PK_COL_NAME_VAL_PAIRS TABLE
There are three collection types in PL/SQL.
Your Bom_Revision_Tbl_Type is an associative array:
An associative array (formerly called PL/SQL table or index-by table) is a set of key-value pairs. Each key is a unique index, used to locate the associated value with the syntax variable_name(index).
It's defined with an index by clause. That is still reported in all_arguments as a "PL/SQL table", using the old name for that collection type.
Your inv_ebi_name_value_pair_tbl type is a nested table.
The documentation explains the differences between them, and when each type is appropriate; associative arrays:
An associative array is appropriate for:
A relatively small lookup table, which can be constructed in memory each time you invoke the subprogram or initialize the package that declares it
Passing collections to and from the database server
and nested tables:
A nested table is appropriate when:
The number of elements is not set.
Index values are not consecutive.
You must delete or update some elements, but not all elements simultaneously.
Nested table data is stored in a separate store table, a system-generated database table. When you access a nested table, the database joins the nested table with its store table. This makes nested tables suitable for queries and updates that affect only some elements of the collection.
You would create a separate lookup table, with multiple entries for each row of the main table, and access it through join queries.
Related
I am trying to create an associative array in Oracle, when I create a nested table, it works fine:
CREATE OR REPLACE TYPE TRNG_BOOK_AUTHORS_TAB
AS TABLE OF VARCHAR2(500);
But when I add the index I get errors:
CREATE OR REPLACE TYPE TRNG_BOOK_AUTHORS_TAB
AS TABLE OF VARCHAR2(500) INDEX BY PLS_INTEGER;
Error: PL/SQL: Compilation unit analysis terminated
Error(2,4): PLS-00355: use of pl/sql table not allowed in this context
What do I have wrong?
You are creating a schema type; those can be nested tables or varying arrays (varrays), but not associative arrays.
From the documentation for the create type statement:
A standalone collection type that you create with the CREATE TYPE statement differs from a collection type that you define with the keyword TYPE in a PL/SQL block or package. For information about the latter, see "Collection Variable Declaration".
With the CREATE TYPE statement, you can create nested table and VARRAY types, but not associative arrays. In a PL/SQL block or package, you can define all three collection types.
I'm not familiar with stored procedure yet. For optimize a time consuming operation of select count(1). I want to save the result to another table or dictionary data structure.
and I can quickly fetch the value of a given keyword.
Such as:
select name, count(1)
from mytable where ... group by name
How to save pairs of name and count to another table or a dictionary data structure?
I am writing pl/sql code with dynamic sql statements to ALTER TABLE on table B when new columns are found in table A. When I query all_tab_columns from table a I can return all I need to do this, but in some cases it throws an error when I specify a length for the new column in table B (for example, DATE which I expected). So, I need to parse the results from all_tab_columns to include or exclude a length in the ALTER TABLE statement. On which data types should I leave off a length specification?
Just want to know is this possible.
Say that if i have value 'X' and iam sure that this is referenced in some other tables as PK value but not sure about exactly which table is that, so i would like to know the list of those tables.
Pseudo query of above what i mentioned
SELECT TABLE_NAME FROM DBA_TABLES WHERE <<ATLEAST ONE OF THE TABLE ROW PK VALUE IS MATCHING EQUAL TO 'X'>>;
I am just curious whats the difference between object and record type in oracle, More specifically between the below declarations
create type emp2_oty is object
(
empno number,
ename varchar2(20),
deptno number
);
create type emp2_nt is table of emp2_oty;
and
type emp2_oty is record
(
empno number,
ename varchar2(20),
deptno number
);
create type emp2_nt is table of emp2_oty;
Please elaborate.
record:
Cannot be stored in the database.
Cannot be recursively referenced.
Cannot have logic defined as part of their definition.
object:
Can be stored as a database table column or as an entire row.
Can be recursively referenced using the SELF parameter.
Can have logic defined as part of their definition using member methods.
The OBJECT type can be stored in the database and can be used in both SQL and PL/SQL
Understanding PL/SQL Records
Records are composed of a group of fields, similar to the columns in a row.The %ROWTYPE attribute lets you declare a PL/SQL record that represents a row in a database table, without listing all the columns.
Basically, if you are familiar with C/C++ or similar languages, you could tell that Records are nothing but structures (i.e a data type that can be used to group items of possibly different types into a single type) they can not have methods within. Objects on the other hand are completely different:
Oracle Objects
Oracle object types are user-defined types that make it possible to model real-world entities
1. Objects Can Encapsulate Operations Along with Data
Database tables contain only data. Objects can include the ability to perform operations (i.e methods) that are likely to be needed on that data (e.g a purchase order object might include a method to sum the cost of all the items purchased).
2. Objects Can Represent Part-Whole Relationships
An object can have other objects as attributes, and the attribute objects can have their own object attributes too. An entire parts-list hierarchy can be built up in this way from interlocking object types.
3. Objects Are Efficient
3.1 Object types and their methods are stored with the data in the database, so they are available for any application to use.
3.2 You can fetch and manipulate a set of related objects as a single unit (e.g when you select a customer object and get the customer's name, phone, and the multiple parts of his address in a single round-trip between the client and the server) .