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"
