The custom apps I write use a normalized data structure as much as possible. There are some cases where a normalized data model is not desirable, and I don't use it in those rare cases.
So, to answer your original question, yes, it is possible. In the custom apps I write, the configuration data is never copied to the working data, only a reference is stored in the working data. This does lead to deeply nested joins, but that is ok by me. The benefits to using this model is the resilience the apps have to configuration changes. As we all know, the non-normalized apps (e.g., Remedy's canned apps) are not at all resilient to configuration data changes. In fact, it outright breaks your working data. Prime examples: - I want to completely rearrange the CTI structure within our apps. I have a from/to mapping. I will just go and change them in the config forms - I want to rename all our groups so they are prefixed with the division abbreviation. I will just go change them all in the config manager - I want to change the login name of a user. I'll just update it in their profile. The list goes on and on. I guess what I am trying to illustrate is that non-relational models serve to etch in stone any and all configuration data, meaning the flexibility you have to alter that in the future is non-existent. As far as making the apps Remedy writes normalized, forget about it. It would require a rewrite. I really wish the join form capabilities were expanded in Remedy. It would make normalized data models much easier to implement. An interface capable of the following is what I envision: - Ability to define any number of data sources for a single join without having to nest joins inside joins - Set of scalar functions available in join forms - Expanded join capabilities; e.g., union - Grouping, and along with this a set of aggregate functions These features would really open up the potential of the ARSystem and allow apps to be written that have a nice architecture. Axton Grams On 9/27/07, Robert Halstead <[EMAIL PROTECTED]> wrote: > Hey listeners, > > As we all know, a many to many table relationship in a database is a > bad thing and the way to accomplish this correctly, in a database, > would be to create an assignment table such that the ID's from the > first table and second table are the only things stored. > > Is this possible to accomplish in Remedy? > > I am fixing our OLA violation workflow and need to modify the forms so > that users may set their own. I came across this problem where, in > our instance, a OLA Rule has 4 levels. Each level can have multiple > groups assigned with multiple individuals per group. I would like to > modularize this a little more in that group and the individuals are > not copied again and again for each rule that wants to assign that > group to them but instead have an "assignment table" to join the two. > > So I have a many to many relationship between Rules and Groups. I > could have a many to many relationship on the Group -> Individuals as > well, but lets just stay with Rules -> Groups for now as the solution > (if there is one) will solve that problem. > > Is an "assignment table" possible in Remedy? Is this relational > database design possible? Or do we just copy the data over and over > again? > > -- > "A fool acts, regardless; knowing well that he is wrong. The ignoramus > acts on only what he knows, but all that he knows. > The ignoramus may be saved, but the fool knows that he is doomed." > > Robert Halstead > > _______________________________________________________________________________ > 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"
