However if you view Remedy more as an information repository rather than a transaction system then there are several advantages using a denormalized form: - historical data. Tickets generated while I work in DC should remain in DC, even after I move to CA. Much of the data in a helpdesk ticket should reflect the data at the time that event took place. Normalizing data makes this difficult. - while changing data seems easy in a normalized database, it is usually easier with static data. For example, lets say that you alter a CTI that reflects a printer outage into more granular elements like paper jam, out of toner, etc. Denormalized data allows you to go through each ticket, one by one, and alter the CTI to the new item. Normalized data makes this a little more difficult (but it is possible). - reporting is much, much easier on denormalized data, a reason why data warehouses are usually denormalized. With remedy, multiple joins are complicated and very inefficient. - normalized data is useful for quicker transactions and updating of key components, not sure why that would be important in a low transaction/high retrieval system like remedy that mostly relies on historical data.
If something should be retrieved that is constantly updated (like relationships with other tables) then remedy does provide facilities to do this mostly with buttons to dialogs (like a user profile) or table fields. So there really isn't a good ARS argument, but perhaps many of the fields in the out of the box applications would be better served with lookups instead of data being copied. However I would probably argue that easing reporting is more important than easing updates. bob -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Carey Matthew Black Sent: Thursday, September 27, 2007 2:26 PM To: [email protected] Subject: Re: Is relational database design doable in Remedy? Robert, Well hang on there a second buddy.... :) IMHO, how "limiting" ARS is all depends on the end goals and how rigid you are about how things "have to look". To try to provide a direct answer to your questions... please see below... On 9/27/07, Robert Halstead <[EMAIL PROTECTED]> wrote: > I'm a software engineer and not a database modeler so excuse me if I'm > a little slow putting this together as the last time I did something > like this was in college. I realize the ups and dows of the 3rd > normal form and all that. How exactly would I implement that in > remedy? The same way you would in any data model. If you want to model "one to many" or "many to many" it works the same way in ARS. > My regular forms are the Rules, Groups, and Individuals in my > scenario. Would the assignment forms be a regular form that would > just store the id's? That kind of depends on the functions of each data object. ( Note: I switched to application speak instead of DB speak.) I think of ARS Forms as (OO) Objects. Some Objects are visible to the end user and others are not. But the function of the Object is determined by the fields (ARS Fields) and methods (active links/filters) that are defined for that object. In ARS: "Regular forms": Hold data. "View forms": point at RDBMS data (as long as it conforms to the ARS form paradigm) "Vendor forms": Point at code that exposes data in the ARS form paradigm "Join Forms": Are Joins of ARS Regular forms "Display Only forms": These are "pure" UI objects that do not store data. > And say I wanted to display a Rule and on the same form display the > groups and individuals that would get notified for this rule, I would > need to create Join Forms to link everything together correct? Well.. no. To display data from several objects on the same UI for the user you could also use table fields, or set field actions. ( and have zero Join forms) However if you want to be able to do a report, then you would need Join form(s) so that the whole data set is available. Well, unless you use Crystal Reports or Jasper Reports and do sub reports. Then you could again get by without the Join forms too. > Am I on the right track here? Kind of, but your not yet expressing the features that you need from each object. (IMO) > I cry sometimes at night when Developing Remedy applications cause of > the limited functionality compared to the languages I'm used to > working with. Hell, SQL is more functional lol. Comparing "Data-oriented language" to a "Object-oriented language" is a poor way to try to say that "one is better than the other". They are apples and oranges. A "better result" is often achieved by mixing the two styles/languages together rather than only using one of the two. :) [Umm.. now I want fruit salad.. .doh! ] HTH -- Carey Matthew Black Remedy Skilled Professional (RSP) ARS = Action Request System(Remedy) Love, then teach Solution = People + Process + Tools Fast, Accurate, Cheap.... Pick two. ________________________________________________________________________ _______ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers Are" _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers Are"
