Just at night? You must be new to Remedy lol Just think of it as a sql statement, except you have to limit yourself to one join per statement.
You would create a data form to hold the user id and the rule id Create a join between the rule and the new form so you can access the rule data Create a join between the user and new form so you can access the user data Create a join between the two new join forms so you can see the rule and the user info together Continue nesting your joins to get the group info in there. Really limited when it comes to joins, yeah I know, sucks. That's one way to keep it relational though. Dylan -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Robert Halstead Sent: Thursday, September 27, 2007 10:22 AM To: [email protected] Subject: Re: Is relational database design doable in Remedy? 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" This message and any attachments are for the intended recipient(s) only and may contain privileged, confidential and/or proprietary information about Downey Savings or its customers, which Downey Savings does not intend to disclose to the public. If you received this message by mistake, please notify the sender by reply e-mail and delete the message and attachments. _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers Are"
