Custom folder - basic question(s)

Question

Hi Everyone,
Hope all is well...
I am aware that one can create an
statement and than use that to create a Discoverer custom folder.
I was wondering when do you have a tendency to go with this approach?
Do you do this so that you can -
1) avoid complicated Discoverer queries - for example you want to avoid using too many analytic functions
so you prepare the data using SQL?
2) create a NEW Discoverer query off this custom folder
thus this technique is like doing a query against a query
I would like to to create a custom folder for the above 2 reasons.
What are your opinions? tx, sandra

Answer 1

Hi Sandra,
let's clarify the terms:
Normally you have developed your Select statement that returns the data that you need in Discoverer. Now you have two choices:
1. send this SQL to your Disco Administrator and let him/her create a custom folder in Discoverer, where he/she uses your SQL directly (copy&paste into discoverer admin)
2. you can use your Select statement and store it in the database and give it a name. you do this via:
create view your_view_name
as
select ... from ....;
Then you can use this view like any other table for selects:
select * from your_view_name;
And it will return the same results like your initial select statement. The advantage is that this view exists as an object in the DB, means everyone else can use it (for example for tests), while you as a developer maintain it.
When you have a view, then in discoverer administrator instead of creating a custom folder you can create a "normal" folder via "New folder from Database". Then it will list all your tables and views on the database, so you select your view "your_view_name" and it will create a folder for this (each column in the view will get an item in the folder etc.)
Regarding performance: You can not generally say that this or that performs better, since the select statement in the view and in the custom folder can be the same. However if it's in the DB as a view, then the DBA can monitor and optimize performance better, since he can see it there as an object.
Next to that there are certain limitations to the select statements that you can use in a custom folder. You do not have these limitations in the DB Views. However those are pretty complex statements that you maybe did not miss so far...
Regarding benefits for tests:
The benefit with a DB view is: you create a view for your select statement and then you can ask someone else to check if it returns the correct data. They will have to do a:
select * from your_view_name where...;
If something is not correct, you change the view but you don't need to send them the SQL via mail again... sending SQLs via mail is something I avoid, because people always do copy&paste mistakes or the mail program does some stupid things with the code or whatever.. I prefer to keep the "implementation" (source code/select statement) hidden to the person that tests... they can validate based on the results.
But I don't want to stress too much on this one, since normally your users should test in Discoverer, that's what they will use finally, so they should test there. And here it does not make a difference to the end users whether you have views or custom folders.
Regarding Source Code control or "Version Control":
We use CVS or Subversion to store our program code. So all program code is stored in such a version control system, so that you can keep track of the changes over time, see which version was installed when (we place "tags/labels" with the date of deployment on the version that is installed) etc.
I guess you store your program code somewhere in a folder, and you use different folders for different versions or something. This is pretty nasty, CVS or Subversion or systems like this make your life easier ;)
Regarding Automatic deployment:
Once we have developed a certain program (statement, package, whatever) and it's working fine, then we store it as new version in our CVS (version control). Then we do a UAT (user acceptance test). IF everything is fine and approved for production, then it needs to be installed on the production server.
For this we have a so called build&deployment system. We use ANT for this (comes from the Java community I think).
What we do when we want to have something installed: we run a script called "build.sh" with some parameters:
build.sh deploy_production my_project
this means we want to deploy the program "my_project" to the production system. the rest is handled by the script:
1. get the latest version of the program code from CVS
2. prepare & copy all needed files to the production servers
3. run one or more install scripts on the production servers to install everything (for example it will execute our "create view ... " script via SQLPlus)
4. verify if installation went fine
5. place a tag/label in CVS that this specific program version has been installed on the current date onto the production system
You can add there some more things if you want to... of course not everything is automated at our site, for example the discoverer folders are still manually created. But this is a one time action. If you make a minor change to the DB view (no new columns) then you need to install only the new version of the View, but nothing needs to be done in Discoverer with the folder.
Well, I could continue for a while explaining the concept more and more... But meanwhile I forgot already what the initial problem was :-D
best regards,
David.