I believe the main advantage of a form such as
SHR:ConsolidatedList is it's ability to bring multiple tables together into a
single list which would be somewhat more difficult with a creative join
view. But you expressed purpose if I understand it properly is the need to
build a table field on your control panel correct? If you are not planning
on using this Remedy View Form (which is based on a view table in the DB that is
a query of your main custom HD table) as anything more than the source for the
table field on your control panel then I don't think you will gain anything from
a performance perspective. This approach would be a query (Table Field) of
a query (view) of a table. I agree that it is simpler than duplicating the
data to a second form but if your source is only one table to begin with I think
the easiest and best thing for performance would be to simply base your table
field off of your main HD form and only display the columns that you want.
This approach would have the added ability of allowing table drill down allowing
for easy access to the data in question without
re-direction.
From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Joe DeSouza
Sent: Tuesday, July 18, 2006 11:10 AM
To: [email protected]
Subject: Re: Performance concern about table field off a database table view..
No you can create a remedy View form out of a database view of a table.. So
I have done that before, but was not quite sure what the performance
impact that would have over larger table and hence had put this question
out to the list... Apparently I got a response offline from one member here
who has over 600K records in his main data table that he/she has created a view
out of, and then created a view form in Remedy and built a table field out
of that view.. and that works for them much better than the SHR:ConsolidatedList
in terms of performance..
I think creating a view as such from data tables for building a thin view
of your main table is a great idea and reduces the amount of workflow you
have to define to build a parallel form as such and increasing data
redundancy instead of reducinging it...
Joe D'Souza
Remedy Developer / Consultant,
BearingPoint,
Time Warner Cable Project,
Virginia.
-----
Original Message ----
From: L. J. Head <[EMAIL PROTECTED]>
To: [email protected]
Sent: Tuesday, July 18, 2006 12:33:53 PM
Subject: Re: Performance concern about table field off a database table view..
**
From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Joe DeSouza
Sent: Thursday, July 13, 2006 6:29 PM
To: [email protected]
Subject: Performance concern about table field off a database table view..
**
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___
From: L. J. Head <[EMAIL PROTECTED]>
To: [email protected]
Sent: Tuesday, July 18, 2006 12:33:53 PM
Subject: Re: Performance concern about table field off a database table view..
**
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: [email protected]
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___
