I'm looking for a means of somehow exporting or visualizing the parse tree of an arbitrary PL/SQL object in Oracle in such a way as to allow comparison between the parse trees of two similar objects. Is this possible?
In theory this should be possible (and will need lots of time to implement!):
PL/SQL is parsed and stored in the DB as a tree-like structure PLUS m-code. The structure is some variant of DIANA plus IDL which in turn is something Ada uses to store the parse results too (PL/SQL is rather similar to Ada). For reference see http://download.oracle.com/docs/cd/B14117_01/appdev.101/b10807/e_limits.htm and http://cs.felk.cvut.cz/10gr2/appdev.102/b14261/tuning.htm
Another option is to build your own parser - a starting point is http://it.toolbox.com/blogs/oracle-guide/building-a-plsql-code-parser-using-plsql-part-1-29704
A very helpful resource is http://www.blackhat.com/presentations/bh-usa-06/BH-US-06-Finnigan.pdf - you will find lots of information on how to extract DIANA-/IDL-information from an Oracle DB which should help you achieve your goal.
Related
What package is best to create a table for a presentation that shows the difference between the means of two variables? I've been using gt_summary but had trouble generating summary stats for multiple variables so used vtable instead which is great for a newbie, but I can't find a way to display the difference between means. Thank you!
I have a lookup table that is harvested from the XML file and not physically stored in the MySQL database. Because of that all the data are represented in one word when it is queried out using jasper adhoc for example
ridikill
peon
thegreat
All these lookup should be like so
ridi kill
pe on
the great
how to make the data to show correctly in separate words.
You are going to have some trouble doing this exclusively in the Ad-Hoc editor, it simply doesn't have this kind of functionality on it's own. You could create a calculated field with the following code in the formula builder:
CaseWhen("RigType" == 'deepwaterdrillship', 'deep water drill ship', "RigType" == 'standardjackup', 'Standard Jack Up',"RigType"=='standardfloater','Standard Floater')
Replace all instances of "RigType" with your original field name. Obviously this will get quite manual if you have a lot of different strings.
If you created a calculated table in the domain/topic that you are using, with similar logic to the code above, this would be more powerful since you can join to your other tables. However, as Petter commented, this is a data source problem and in my experience it is always better to fix the source if possible.
As an organization we are moving towards the purchase of ODI as an ELT tool.
We have plenty of PLSQL resource but I have heard ODI is powerful enough at data manipulation to replace much of what was previously done in PLSQL.
What are its strengths? And weaknesses?
And can it completely do away with coding the data transformation in PLSQL?
No, it doesn't however you might be 99% correct here.
It's actually a tricky question as PL/SQL might be submitted by ODI too.
I would reserve it (PL/SQL) for defining functions/procedures (if you REALLY need to) to be later called by ODI.
This should NEVER be something immediately related to ETL like INSERT INTO … SELECT … FROM … - that's where ODI fits the bill perfectly.
The only justified cases, I came across during my ODI experience (9yrs) were:
- creating PL/SQL function to authenticate (and later authorize through OBIEE) an LDAP/AD user
- creating helper functions to be later called by ODI DQ(CKM) modules like is_number, is_date
- creating XML files directly by DB (even with never ODI XML driver you might still find it's best to use native DB XML API/functionality to produce XML) - for performance reasons. Other direct file operations (load/unload) could be done in this way.
- creating my own (optimized) hierarchy traversal query for performance reasons (beaten the standard Oracle SQL 'Recursive Subquery Factoring' feature to about 1000:1)
It's up to you if you want to make a reusable piece of logic by using PL/SQL and call it from ODI or code it from ODI directly (in the PL/SQL form)
I have one "big" TOracleDataSet which I can't change 'cause it's using in many different parts of huge project. I want to add just one record to this dataset for using in another grid. The solve way I see it is create another one oracle data set which will combine wanted record and another ones from "big" dataset. In other words, "small" dataset includes "big" dataset.
Try this maybe?
TxQuery Project
This was a commercial project at one time, but the auther was convinced to release it opensource.
TxQuery component is a TDataSet descendant component that can be used to query one or more TDataSet descendant components using SQL statements. It is implemented in Delphi 100% source code, no DLL required, because it implements its own SQL syntax parser and SQL engine.
That quote was taken from the page of the current maintainer, I believe, Chau Chee Yang .
Either this or maybe TClientDataset might be your best options.
I am developing a enterprise software for a big company using Oracle. Major processing unit is planned to be developed in PL/SQL. I am wondered if there is any ORM like Hibernate for Java, but the one for PL/SQL. I have some ideas how to make such a framework using PL/SQL and Oracle system tables, but it is interesting - why no one have done this before? What do you think will that be effective in speed and memory consumption? Why?
ORMs exist to provide an interface between a database-agnostic language like Java and a DBMS like Oracle. PL/SQL in contrast knows the Oracle DBMS intimately and is designed to work with it (and a lot more efficiently than Java + ORM can). So an ORM between PL/SQL and the Oracle DBMS would be both superfluous and unhelpful!
Take a read through these two articles - they contain some interesting points
Ask Tom - Relational VS Object Oriented Database Design
Ask Tom - Object relational impedance mismatch
As Tony pointed out ORMs really serve as helper between the App and Db context boundaries.
If you are looking for an additional level of abstraction at the database layer you might want to look into table encapsulation. This was a big trend back in the early 2000s. If you search you will find a ton of whitepapers on this subject.
Plsqlintgen still seems to be around at http://sourceforge.net/projects/plsqlintgen/
This answer has some relevant thoughts on the pros and cons of wrapping your tables in pl/sql TAPIs (Table APIs) for CRUD operations.
Understanding the differences between Table and Transaction API's
There was also a good panel discussion on this at last years UK Oracle User Group - the overall conclusion was against using table APIs and for transaction APIs, for much the same reason - the strength of pl/sql is the procedural control of SQL statements, while TAPIs push you away from writing set-based SQL operations and towards row-by-row processing.
The argument for TAPI is where you may want to enforce some kind of access policy, but Oracle offers a lot of other ways to do this (fine-grained access control, constraints, triggers on insert/update/etc can be used to populate defaults and enforce that the calling code is passing a valid request).
I would definitely advise against wrapping tables in PL/SQL object types.
A lot of the productivity with pl/sql comes from the fact that you can easily define things in terms of the underlying database structure - a row record type can be simply defined as %ROWTYPE, and will be automatically impacted when the table structure changes.
myRec myTable%ROWTYPE
INSERT INTO table VALUES myRec;
This also applies to collections based over these types, and there are powerful bulk operations that can be used to fetch & insert whole collections.
On the other hand, object types must be explicitly impacted each time you want to change them - every table change would require the object type to be impacted and released, doubling your work.
It can also be difficult to release changes if you are using inheritance and collections of types (you can 'replace' a package, but cannot replace a type once it is used by another type).
This isn't putting OO PL/SQL down - there are places where it definitely simplifies code (i.e. avoiding code duplication, anywhere you would clearly benefit from polymorphism) - but it is best to understand and play to the strengths of the language, and the main strength is that the language is tightly-coupled to the underlying DB.
That said, I do often find myself creating procedures to construct a default record, insert a record, etc - often enough to have editor macros for it - but I've never found a good argument for automatically generating this code for all tables (a good way to create a lot of unused code??)
Oracle is a Relation database and also has the ability to work as an object-oriented database as well. It does this by building an abstraction layer (fairly automatically) on top of the relational structure. This would seemingly eliminate the need for any "tool" as it is already built-in.