Sorry, I should have said "Core data element", not data element. And I agree that each has its place, but I think that a relatively non-normalized structure like Remedy's works better when data needs to be preserved for reporting or auditing purposes.
Rick 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_______________________ _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers Are"
