I may be completely off, and if so I would appreciate it if
someone simply slaps me, but a View is nothing more than a pre-defined
query. It is true at the DB that you can grant permissions to views and
such but for the purposes of running a remedy table field off of a view that is
just performing a select from another view (remedy built) or directly off of the
table itself it won't matter at all. Since your table field is a
pre-defined search I think you may be adding a layer of complexity to the
process that is not needed.
From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Joe DeSouza
Sent: Thursday, July 13, 2006 6:29 PM
To: arslist@ARSLIST.ORG
Subject: Performance concern about table field off a database table view..
This has been done before so I'm inviting comments from
those who have done it and are having a heavily used application that might have
a significantly large number of records in their main data table..
This is what I am in the process of designing.. I am
building a completely custom trouble ticketing application for a cable company.
Due to the nature of their business where they are going to use this trouble
ticketing application to ticket network outages reported both manually as well
as automatically from network monitoring system this table is expected to grow
rapidly.
On the control panel on their home page I need to have a
table field with a 'thin' list of their open tickets (much the same way as the
SHR:ConsolidatedList in the ITSM application). The design is that instead of
having a place holder Remedy data table to push new tickets on creation with the
functionality to modify and delete enteries in that table, I have elected to
create a database table view of the main data table with the constraint that it
would display only tickets that are in an open status eliminating the overhead
that might be caused by creating an additional table, and the push fields that
happens on every transaction on the main data table.
Then on the control panel I simply build a table
field that points to that database view of the table.
My question is - would this impact performance in
anyway.. I think this might have a positive impact on the performance.. If any
of you think otherwise please do write back with reasons why you think it might
not be the best design to adopt. If any of you think the traditional approach of
a thinner Remedy form to hold the list information is better please do write
about that too and your reasons supporting that approach.
I hope to hear from you guys..
So far my protype right now on my development
box rocks, but since I have never used this approach in a thick data table
that has the potential of eventually housing thousands - maybe a few hundred
thousand tickets eventually I would love comments from those using this approach
and their experiences with it...
Note that I will index the necessary columns that are
used in the construction of these database views of the data tables in question
so as to optimize the view creation.
Cheers
Joe D'Souza,
Remedy Consultant / Developer,
Shyle Networks,
New Jersey.
Do you Yahoo!?
Next-gen email? Have it all with the all-new Yahoo! Mail Beta. __20060125_______________________This posting was submitted with HTML in it___ __20060125_______________________This posting was submitted with HTML in it___
