You can either use joins, display only fields on regular forms, or a display only form to show the data. Each approach has its advantages and disadvantages.
Axton Grams 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? > > 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? > > 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? > > Am I on the right track here? > > 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. > > On 9/27/07, Axton <[EMAIL PROTECTED]> wrote: > > Not following you here Rick: > > > > "This means that every time that data element is updated, it must be > > propagated through every record in which it is referenced. If you > > want an example of applications built that way, look at Peregrine's > > applications." > > > > This the problem I see with a non-normalized model. For example, when > > you change a CTI, you have to update the assignment records, tickets, > > assets, components, changes, etc (speaking for 5.6 apps). Then you > > start to get into nasty situations: > > - workflow generates errors when workflow attempts to update the records > > - you have to consume a large number of resources on both the ar and > > db servers to update everything > > - data gets missed, if for no other reason that there are thousands of > > copies of it in hundreds of locations > > > > With a normalized model, you only update one value in one place to > > change what you see everywhere; it is only stored once. > > > > With a non-normalized model, the value has to be updated everywhere it > > is stored. > > > > There exists a proper application for both approaches. What I see in > > the Remedy apps is that everything is copied everywhere; this makes it > > very difficult to do certain types of operations in the apps. > > > > Axton Grams > > > > On 9/27/07, Rick Cook <[EMAIL PROTECTED]> wrote: > > > ** > > > Be careful of that, though. > > > > > > The upside to DB normalization is that you only have one copy of a data > > > element. > > > The downside to DB normalization is that you only have one copy of a data > > > element. > > > > > > This means that every time that data element is updated, it must be > > > propogated through every record in which it is referenced. If you want an > > > example of applications built that way, look at Peregrine's applications. > > > > > > Rick > > > > > > On 9/27/07, James Van Sickle > > > <[EMAIL PROTECTED]> wrote: > > > > Yes, you can design forms and workflow in such a way that they follow > > > > database normalization techniques. You can create an Assignment form > > > whose > > > > sole purpose is to track the many to many relationship. I would highly > > > > recommend mapping it out in Visio or another tool first before you start > > > > doing anything in Remedy Admin, though. > > > > > > > > (Embedded image moved to file: pic21520.gif)Countrywide > > > > > > > > > > > > James Van Sickle > > > > Remedy Developer > > > > IT - Remedy Development > > > > > > > > > > > > http://www.countrywide.com > > > > > > > > > > > > > > > > > > > > > > > > > > > > Robert Halstead > > > > <[EMAIL PROTECTED] > > > > COM> > > > To > > > > Sent by: "Action [email protected] > > > > Request System > > > cc > > > > discussion > > > > list(ARSList)" > > > Subject > > > > <[EMAIL PROTECTED] [ARSLIST] Is relational database > > > > ORG> design doable in > > > Remedy? > > > > > > > > > > > > 09/27/2007 10:38 > > > > AM > > > > > > > > > > > > Please respond to > > > > [EMAIL PROTECTED] > > > > RG > > > > > > > > > > > > > > > > > > > > > > > > > > > > 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 > > > __20060125_______________________This posting was > > > submitted with HTML in it___ > > > > _______________________________________________________________________________ > > UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where > > the Answers Are" > > > > > -- > "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"
