Robert,

Well hang on there a second buddy.... :)

IMHO, how "limiting" ARS is all depends on the end goals and how rigid
you are about how things "have to look".

To try to provide a direct answer to your questions... please see below...

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?

The same way you would in any data model.

If you want to model "one to many" or "many to many" it works the same
way in ARS.


> 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?

That kind of depends on the functions of each data object. ( Note: I
switched to application speak instead of DB speak.) I think of ARS
Forms as (OO) Objects. Some Objects are visible to the end user and
others are not. But the function of the Object is determined by the
fields (ARS Fields) and methods (active links/filters) that are
defined for that object.

In ARS:
"Regular forms": Hold data.
"View forms": point at RDBMS data (as long as it conforms to the ARS
form paradigm)
"Vendor forms": Point at code that exposes data in the ARS form paradigm
"Join Forms": Are Joins of ARS Regular forms
"Display Only forms": These are "pure" UI objects that do not store data.


> 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?

Well.. no.

To display data from several objects on the same UI for the user you
could also use table fields, or set field actions. ( and have zero
Join forms) However if you want to be able to do a report, then you
would need Join form(s) so that the whole data set is available. Well,
unless you use Crystal Reports or Jasper Reports and do sub reports.
Then you could again get by without the Join forms too.


> Am I on the right track here?

Kind of, but your not yet expressing the features that you need from
each object. (IMO)

> 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.

Comparing "Data-oriented language" to a "Object-oriented language" is
a poor way to try to say that "one is better than the other". They are
apples and oranges. A "better result" is often achieved by mixing the
two styles/languages together rather than only using one of the two.
:) [Umm.. now I want fruit salad.. .doh! ]

HTH

-- 
Carey Matthew Black
Remedy Skilled Professional (RSP)
ARS = Action Request System(Remedy)

Love, then teach
Solution = People + Process + Tools
Fast, Accurate, Cheap.... Pick two.

_______________________________________________________________________________
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the 
Answers Are"

Reply via email to