Ah' I love these "friendly chats" about database, and whether to Normalize or not.
Yes Remedy Supports it, but as the thread has mentioned, a join form of only 2 tables, is extremely limiting say the least. Of course, you can always manually create a complex DB-View, and then a Remedy Vendor on-top of that. Of course, this is a maintenance nightmare, but workable in certain conditions. I have always considered data-normalization/non-normalized in a slightly different thinking. For "Live Ticket Data" (as Axton mentions) I still continue to feel it is best to have this data completely normalized. For "Historical 'Field' Tracking" this is where you simply create a storage table, based upon the reporting/tracking requirements. (Think of this as the Audit-Records so to say). You want to track the CTI Changes? Click-Done (simple table and 1 filter). User Location Change? Status Changes? You can create as many or as few 1-to-M tables to store this stuff as necessary. (Wide -vs- Narrow debate :) ) Inside the User-Tool / Reporting this history is extremely easy to visualize and report upon. In your example of using normalized data, and "extending" a categorization, what I have used in the past, is to take the "one" 'Printer Outage' and change that to "printer outage old'. Then Create new entries for the extension. (yes, hopefully you have a status flag for menu selection, active/inactive) In this manner (as Axton also pointed out) all workflow that "validates configuration data" will completely work as expected. If you had a normalized relationship to say a support-team, that would still work. (ever kick yourself because of the 4/5/6x bug where SHR:Assignment was not updated when you modified a SHR:Categorization entry? Application Groups?? Aarruugghh!!!) So for me it boils down to the following statements / strategies: Non-Normalized Data : * Must have rules for "When to cascade changes", and this must be implemented Normalized Data : * Must have rules on "how to change" this configuration data (inactive old and create new, or update and reflect immediately) This is what a 'developer' must take into consideration when building an application, and it's all based upon the requirements, and "time to deliver" - definitely a non-normalized application at times is quicker to develop, as long as that meets the functionality requirements. HTH Thanks-n-advance; HDT Platform Incident / Problem Manager & Architect Robert Molenda IT OS PA Tel: +1 408 503 2701 Fax: +1 408 503 2912 Mobile: +1 408 472 8097 [EMAIL PROTECTED] Quality begins with your actions. -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Bob Sent: Thursday, September 27, 2007 11:37 AM To: [email protected] Subject: Re: Is relational database design doable in Remedy? 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" _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers Are"
