To blindly use one approach is to be, well, blind. There are certain applications where a normalized model makes sense: - application configuration data - a cmdb - service level agreement config data
As for the reporting limitations of using a non-normalized model, well, that's just that, a limitation of the reporting capabilities of the product. If a more robust component for join capabilities were introduced, as I mentioned earlier in the thread, this code could easily be exposed as an odbc driver or some other type of interface that is capable of driving reporting. As for the historical data reporting capabilities, that should also be addressed outside the application working data set. Data warehouses are designed to do this. Ideally dw should record a transactional history of all data changes, allowing you to do point in time reporting. We have such a system implemented in our environment, but it would be nice if this existed natively. If the arsystem were capable of creating a separate schema and/or instance where it warehouses the data, this would would alleviate a lot of the problems inherent on reporting against the production db. The reason I say this should be addressed outside the arsystem server's local database is because of the overhead often associated with reporting. People writing reports against a remedy db typically stumble their way through it and knock the servers pretty hard when they do things like return a cartesian product. Instead of working around the limitations of the product and bogging down the applications, BMC should be actively scouting and incorporating components to their arserver stack that allows the software to act as a robust, scalable application stack. This means providing the capabilities within the product to write efficient and streamlined applications using the native capabilities of the product; it also means not having to bloat your applications for functions not directly related to the use of the application (e.g., reporting). Just my views on it. Axton Grams On 9/27/07, Bob <[EMAIL PROTECTED]> wrote: > 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"
