As per title, is it possible to write my own query in OracleSQL Developer and then plug it into Oracle Peoplesoft? Or is it possible to have a pivot query in Peoplesoft?
Yes, you can do that using a view.
After that you will create a new Query using your view, and if you want to, use the query as datasource for your pivot grid
Oracle PIVOT clauses are not supported, nor are any other database pivot-like clauses. And as suggested by Walucas, you can use a view with the PIVOT clause already written and then query the view. An alternate approach would be to use a series of left outer joins where each join is to the same table, each with a mutually exclusive set of rows. This is a hammer-like approach and very inelegant, but you can do this without having to create a view.
Related
we are creating a pivot table in OBIEE, we need to hide columns from the pivot table if those columns are null. Is there any implicit way of doing this in Oracle OBIEE?
Thanks in advance
No you can't. For the very simple reason that a pivot is a cross-table and does intersections of data so you quite literally can never be sure that a whole "column" as you call it retrieves only NULLs. It simmply doesn't make sense.
Is it possible to do updates via Resultset to an Oracle view? Asking as my code is giving me insufficient priviledge error when it does the rs.updateRow() call. I have checked and I definitely have access to the table/view.
The code looks like:
white (rs.next()) {
int updateStatus = getPSCforAction(status);
rs.updateInt("SPSC", updateStatus);
rs.updateRow;
}
The SELECT statement changes depends on operation but it will always be querying an Oracle view (and in some cases multiple views). My main question is whether updating via resultSet can be done to an Oracle view (or views)?
To answer your question one must see a definition of you view and a SELECT statament that is used to produce the resulset in your Java code. Without looking at this it is hard to give the answer
Anyway, generar rules and limitations are described in the Oracle Database JDBC Developer's guide:
Result Set Limitations
The following limitations are placed on queries for enhanced result
sets. Failure to follow these guidelines results in the JDBC driver
choosing an alternative result set type or concurrency type.
To produce an updatable result set:
A query can select from only a single table and cannot contain any
join operations.
In addition, for inserts to be feasible, the query must select all
non-nullable columns and all columns that do not have a default value.
A query cannot use SELECT * . However, there is a workaround for this.
A query must select table columns only.
It cannot select derived columns or aggregates, such as the SUM or MAX
of a set of columns.
To produce a scroll-sensitive result set:
A query cannot use SELECT *. However, there is a workaround for this.
A query can select from only a single table.
Scrollable and updatable result sets cannot have any column as Stream.
When the server has to fetch a Stream column, it reduces the fetch
size to one and blocks all columns following the Stream column until
the Stream column is read. As a result, columns cannot be fetched in
bulk and scrolled through.
They vaguely write that:
A query can select from only a single table and cannot contain any
join operations.
Could be that they mean "exlusively from tables, but not views", but also they could mean: "from tables and views", nobody knows, one must test this.
Another possible problem - your view may not be updatable, that is it doesn't conform to the following rules:
Notes on Updatable Views The following notes apply to updatable views:
An updatable view is one you can use to insert, update, or delete base
table rows. You can create a view to be inherently updatable, or you
can create an INSTEAD OF trigger on any view to make it updatable.
To learn whether and in what ways the columns of an inherently
updatable view can be modified, query the USER_UPDATABLE_COLUMNS data
dictionary view. The information displayed by this view is meaningful
only for inherently updatable views. For a view to be inherently
updatable, the following conditions must be met:
Each column in the view must map to a column of a single table. For
example, if a view column maps to the output of a TABLE clause (an
unnested collection), then the view is not inherently updatable.
The view must not contain any of the following constructs:
A set operator
A DISTINCT operator
An aggregate or analytic function
A GROUP BY, ORDER BY, MODEL, CONNECT BY, or START WITH clause
A collection expression in a SELECT list
A subquery in a SELECT list
A subquery designated WITH READ ONLY Joins, with some exceptions, as
documented in Oracle Database Administrator's Guide
In addition, if an
inherently updatable view contains pseudocolumns or expressions, then
you cannot update base table rows with an UPDATE statement that refers
to any of these pseudocolumns or expressions.
If you want a join view to be updatable, then all of the following
conditions must be true:
The DML statement must affect only one table underlying the join.
For an INSERT statement, the view must not be created WITH CHECK
OPTION, and all columns into which values are inserted must come from
a key-preserved table. A key-preserved table is one for which every
primary key or unique key value in the base table is also unique in
the join view.
For an UPDATE statement, the view must not be created WITH CHECK
OPTION, and all columns updated must be extracted from a key-preserved
table.
For a DELETE statement, if the join results in more than one
key-preserved table, then Oracle Database deletes from the first table
named in the FROM clause, whether or not the view was created WITH
CHECK OPTION.
I understand that a view is a window to an underlying table or set of tables in Oracle. For instance if I have a view that is created by joining multiple tables , will the view perform the actual join operations when I select data from the view? Does a view perform better than joining multiple tables to fetch data or is it the same with respect to performance?
There is usually no performance difference between a single query and a logically equivalent query that uses views.
Oracle has optimizer transformations that can combine views with the outer query; predicate pushing, simple and complex view merging, etc. Think of views more like a text macro that builds a large query, instead of a function that returns rows.
For example, in the below query Oracle would probably be smart enough to push the predicate on the primary key column into the view. Although the view by itself might return millions of rows, when the entire query is run Oracle will apply the predicate on the primary key column first.
select *
from view_returns_millions_of_rows
where primary_key_value = 1;
I have a view in Oracle that uses PIVOT and I would like to apply it to an h2 database. However, Pivot is not yet supported in h2.
I am currently using CASE statements to do the pivot which is fine for now.
However, I am intrigued by user defined functions in h2.
Is it possible to create a generic PIVOT function in h2 by using user defined functions? Has anyone already done it?
Oracle and SQL Server are the only popular databases to have a PIVOT (or UNPIVOT) clause, which generates several aggregate columns for input rows.
In all other databases, you'll have to resort to do manual pivoting, the way you did.
Stack Overflow is full of such questions for MySQL, for instance:
MySQL pivot table
MySQL pivot in same table
MySQL pivot query
MySQL Pivot or Excel Solution
Let's assume I have two tables of the same row count. Both tables contain a column that allows for 1-1 join between them.
If those tables were turned into one table instead and thus JOIN statement eliminated from the query, would there be any performance benefit of that?
Another example... Let's assume I have table with 10 columns. From that table I created new table but only taking one column. If I issue statement selecting that one column with WHERE predicate on the same column would there be any performance difference in executing this query on both tables?
What I'm trying to get to is if performance is the same in above cases is it safe to say tables are only containers wrapping number of columns together?
I did run couple tests but with non conclusive results.
Let's assume I have two tables of the same row count. Both tables
contain a column that allows for 1-1 join between them. If those
tables were turned into one table instead and thus JOIN statement
eliminated from the query, would there be any performance benefit of
that?
Performing that join for every query is of course more expensive than materializing the table once and then reading it. So yes, there would be a performance benefit.
Another example... Let's assume I have table with 10 columns. From
that table I created new table but only taking one column. If I issue
statement selecting that one column with WHERE predicate on the same
column would there be any performance difference in executing this
query on both tables?
No, there would be no difference, since tables are represented as collections of columns, which are each stored in their own file.
What I'm trying to get to is if performance is the same in above cases
is it safe to say tables are only containers wrapping number of
columns together?
That is indeed safe to say.