Jump to content

JasperSever Domains vs Oracle Views


kchanna

Recommended Posts

 I have a conundrum,

We recently purchased JasperServer pro 3.7 to primarily report on an Oracle database which is mainly used by our core business application. Previously we have been using a reporting tool which basically posted SQL queries to the database and had a rudimentary parameterisation capability.

We have about 90 views in Oracle which were used by the Reporting tool, some simple, some complex.  Now that we are implementing JS, I cannot decide whether to re-use the views in oracle (which by the way need to be cleaned up) or to migrate all the IP (i.e. SQL queries) to JS and build domains from scratch? or should we can Oracle Views and JS domains and build reports in iReport and deploy to JS?

My concern is that if we leave the views as they are and build reports based on the existing views, we have two maintenance points. And if we re-do everything in JS domains, there is too much work. Is there a best practice approach with this?

Thanks in advance

Kamran

Link to comment
Share on other sites

  • Replies 1
  • Created
  • Last Reply

Top Posters In This Topic

Popular Days

Top Posters In This Topic

I am not sure what kind of help you are looking for... But let's see what options you have:

1) You leave you views, you create reports in iReport and deploy them in JS
Pros:
- the process is straight forward
Cons:
- you leave views -> maintenance and possibly inherited mess in queries
- need to use iReport

2) You leave views, and create domains on top of them (threat them as tables)
Pros:
- all work in JS UI
- may take advantages of domains (security, business view structure, data strategies, etc.)
Cons:
- you leave views -> maintenance and possibly inherited mess in queries

3) You create domains from scratch, and map all your views to derived table by just copying your view queries there
Pros:
- a single maintenance point (domain)
- a possibility for incremental clean-up (you don't have to do everything at once)
Cons:
- some extra work is involved

4) You create domains from scratch, and create a new structure for your needs based on tables
Pros:
- a single maintenance point (domain)
- you get it all fresh and clean
Cons:
- more extra work is involved

As of best practice, it depends on your priorities.
The quickest thing would probably be (2).
The progressive thing with reduced risk would be (3).
The getting it right (at expense of time and efforts) would be (4).
And if you are not confortable with domains, (1) is there for you.

Thanks,
Andrew S.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×
×
  • Create New...