Articles on Many to Many 
Author Message
 Articles on Many to Many

Anyone know if there are any articles on a Many to Many relationship?

I have books on design but there is never enough (for me anyway) about Many
to Many.

Scenario:

If you receive payments from a customer against an invoice, it could be many
payments to one (large $'s) Invoice and that's simple enough; Invoice <-->>
Payments

However, if there are many small invoices and the customer makes one payment
for many Invoices we have a simple straight forward many Invoices to one
Payment;  Invoice <<--> Payment.

We currently handle this via a third "Cash" file, but I'm personally
interested in learning more on Many to Many (get rid of the 3rd file?)
without creating the obvious probable disasters.  The 3rd file can cause
lots of pain when displaying the 3-Up browse of Customer, Invoices,
Payments. No doubt a direct Many to Many will have it's own problems also,
but one needs to know and compare the merits/problems.

Any publication would be appreciated

Thanks

Ron M.

Australia



Mon, 22 Mar 2004 06:04:51 GMT  
 Articles on Many to Many
Tom Ruby in Clarion mag.

--

Steve Parker

====================================
  kb and download center at: www.par2.com
====================================


Quote:
> Anyone know if there are any articles on a Many to Many relationship?

> I have books on design but there is never enough (for me anyway) about
Many
> to Many.

> Scenario:

> If you receive payments from a customer against an invoice, it could be
many
> payments to one (large $'s) Invoice and that's simple enough; Invoice
<-->>
> Payments

> However, if there are many small invoices and the customer makes one
payment
> for many Invoices we have a simple straight forward many Invoices to one
> Payment;  Invoice <<--> Payment.

> We currently handle this via a third "Cash" file, but I'm personally
> interested in learning more on Many to Many (get rid of the 3rd file?)
> without creating the obvious probable disasters.  The 3rd file can cause
> lots of pain when displaying the 3-Up browse of Customer, Invoices,
> Payments. No doubt a direct Many to Many will have it's own problems also,
> but one needs to know and compare the merits/problems.

> Any publication would be appreciated

> Thanks

> Ron M.

> Australia



Mon, 22 Mar 2004 06:52:02 GMT  
 Articles on Many to Many
Thanks Steve


Quote:
> Tom Ruby in Clarion mag.

> --

> Steve Parker

> ====================================
>   kb and download center at: www.par2.com
> ====================================



> > Anyone know if there are any articles on a Many to Many relationship?

> > I have books on design but there is never enough (for me anyway) about
> Many
> > to Many.

> > Scenario:

> > If you receive payments from a customer against an invoice, it could be
> many
> > payments to one (large $'s) Invoice and that's simple enough; Invoice
> <-->>
> > Payments

> > However, if there are many small invoices and the customer makes one
> payment
> > for many Invoices we have a simple straight forward many Invoices to one
> > Payment;  Invoice <<--> Payment.

> > We currently handle this via a third "Cash" file, but I'm personally
> > interested in learning more on Many to Many (get rid of the 3rd file?)
> > without creating the obvious probable disasters.  The 3rd file can cause
> > lots of pain when displaying the 3-Up browse of Customer, Invoices,
> > Payments. No doubt a direct Many to Many will have it's own problems
also,
> > but one needs to know and compare the merits/problems.

> > Any publication would be appreciated

> > Thanks

> > Ron M.

> > Australia



Mon, 22 Mar 2004 06:54:15 GMT  
 Articles on Many to Many

Quote:
> We currently handle this via a third "Cash" file, but I'm personally
> interested in learning more on Many to Many (get rid of the 3rd file?)

Unless you break some important rule of database design, any many-many
relationship requires a third file.

Steve
--
Steven C. Gallafent - The Computer Guy



Mon, 22 Mar 2004 07:19:17 GMT  
 Articles on Many to Many
In summary it looks like you're saying "If it ain't broke don't fix it"
I found the articles Steve Parker pointed me to were worth reading, but it
looks like I was looking for non-existent pixie dust and you are correct.

thanks Steve

Ron M



Quote:


> > We currently handle this via a third "Cash" file, but I'm personally
> > interested in learning more on Many to Many (get rid of the 3rd file?)

> Unless you break some important rule of database design, any many-many
> relationship requires a third file.

> Steve
> --
> Steven C. Gallafent - The Computer Guy




Mon, 22 Mar 2004 09:04:44 GMT  
 Articles on Many to Many
Ron,
   I break the rule on this one.
In my payment file, I have a string field, you may need a memo depending on
the number of  invoices the payments are being applied to.
   I loop thru the invoices being paid in my tagging procedure and stuff the
following into the field:
    Rpay:RefNoPaid=
a

   I use the '|' as my end of record mark.

   Then when I want to view the invoices that were paid, I use a Queue

PayQ                     QUEUE,PRE()
PInvoice                   STRING(10)
PDate                      STRING(10)
Amount                     DECIMAL(9,2)
                         END

      I build the queue using this not so elegant code:
  Loop i# = 1 to Len(Clip(Rpay:RefNoPaid))
    if Rpay:RefNoPaid[i#] = ','
       Ct# += 1
       !S# = i#
       N# = 1
    End
    if Rpay:RefNoPaid[i#] = '|'
       Ct# = 0
       PayQ.Amount = Sub(Rpay:RefNoPaid,S#+1,(i#-1-S#))
       Add(PayQ)
       S# = i#
       N# = 0
    End
    if Ct# = 1 and N# = 1
      if Records(PayQ) = 0
         PayQ.PInvoice = Sub(Rpay:RefNoPaid,1,i#-1)
          Else
         PayQ.PInvoice = Sub(Rpay:RefNoPaid,S#+1,(i#-1-S#))
      End
       E# = i#
       N# = 0
    End
    if Ct# = 2 and N# = 1
       PayQ.PDate = Sub(Rpay:RefNoPaid,E#+1,(i#-1-E#))
       S# = i#
       N# = 0
    End
  End

  HTH

  Bill Rollins


Quote:
> Anyone know if there are any articles on a Many to Many relationship?

> I have books on design but there is never enough (for me anyway) about
Many
> to Many.

> Scenario:

> If you receive payments from a customer against an invoice, it could be
many
> payments to one (large $'s) Invoice and that's simple enough; Invoice
<-->>
> Payments

> However, if there are many small invoices and the customer makes one
payment
> for many Invoices we have a simple straight forward many Invoices to one
> Payment;  Invoice <<--> Payment.

> We currently handle this via a third "Cash" file, but I'm personally
> interested in learning more on Many to Many (get rid of the 3rd file?)
> without creating the obvious probable disasters.  The 3rd file can cause
> lots of pain when displaying the 3-Up browse of Customer, Invoices,
> Payments. No doubt a direct Many to Many will have it's own problems also,
> but one needs to know and compare the merits/problems.

> Any publication would be appreciated

> Thanks

> Ron M.

> Australia



Mon, 22 Mar 2004 14:58:32 GMT  
 Articles on Many to Many
Ron,

Quote:
> I have books on design but there is never enough (for me anyway) about Many
> to Many.

http://www.clarionmag.com/cmag/search.frm?formID=true&query=%2Btitle%...
2Btitle%3Arelationships (URL may wrap, subscription required)

Dave

Dave Harms

In-depth Clarion articles, news, tips & tricks
Plus the Clarion Online Archives!
Clarion Magazine: http://www.clarionmag.com
Subscribe Now! http://www.clarionmag.com/cmag/subscribe.html



Mon, 22 Mar 2004 18:09:20 GMT  
 Articles on Many to Many
Thanks Bill

Ron M.


Quote:
> Ron,
>    I break the rule on this one.
> In my payment file, I have a string field, you may need a memo depending
on
> the number of  invoices the payments are being applied to.
>    I loop thru the invoices being paid in my tagging procedure and stuff
the
> following into the field:
>     Rpay:RefNoPaid=

a
Quote:

>    I use the '|' as my end of record mark.

>    Then when I want to view the invoices that were paid, I use a Queue

> PayQ                     QUEUE,PRE()
> PInvoice                   STRING(10)
> PDate                      STRING(10)
> Amount                     DECIMAL(9,2)
>                          END

>       I build the queue using this not so elegant code:
>   Loop i# = 1 to Len(Clip(Rpay:RefNoPaid))
>     if Rpay:RefNoPaid[i#] = ','
>        Ct# += 1
>        !S# = i#
>        N# = 1
>     End
>     if Rpay:RefNoPaid[i#] = '|'
>        Ct# = 0
>        PayQ.Amount = Sub(Rpay:RefNoPaid,S#+1,(i#-1-S#))
>        Add(PayQ)
>        S# = i#
>        N# = 0
>     End
>     if Ct# = 1 and N# = 1
>       if Records(PayQ) = 0
>          PayQ.PInvoice = Sub(Rpay:RefNoPaid,1,i#-1)
>           Else
>          PayQ.PInvoice = Sub(Rpay:RefNoPaid,S#+1,(i#-1-S#))
>       End
>        E# = i#
>        N# = 0
>     End
>     if Ct# = 2 and N# = 1
>        PayQ.PDate = Sub(Rpay:RefNoPaid,E#+1,(i#-1-E#))
>        S# = i#
>        N# = 0
>     End
>   End

>   HTH

>   Bill Rollins



> > Anyone know if there are any articles on a Many to Many relationship?

> > I have books on design but there is never enough (for me anyway) about
> Many
> > to Many.

> > Scenario:

> > If you receive payments from a customer against an invoice, it could be
> many
> > payments to one (large $'s) Invoice and that's simple enough; Invoice
> <-->>
> > Payments

> > However, if there are many small invoices and the customer makes one
> payment
> > for many Invoices we have a simple straight forward many Invoices to one
> > Payment;  Invoice <<--> Payment.

> > We currently handle this via a third "Cash" file, but I'm personally
> > interested in learning more on Many to Many (get rid of the 3rd file?)
> > without creating the obvious probable disasters.  The 3rd file can cause
> > lots of pain when displaying the 3-Up browse of Customer, Invoices,
> > Payments. No doubt a direct Many to Many will have it's own problems
also,
> > but one needs to know and compare the merits/problems.

> > Any publication would be appreciated

> > Thanks

> > Ron M.

> > Australia



Tue, 23 Mar 2004 14:48:30 GMT  
 
 [ 8 post ] 

 Relevant Pages 

1. Silly Articles (Articles or misplaced ones).

2. simple file i/o (Article 4882 in comp.lang. (Article 4885 in comp.lang.oberon)

3. APL2/2 article in OS/2 Developer

4. Java Articles

5. Smalltalk article in the current InformationWeek issue.

6. APL QuoteQuad - Call for Articles

7. Call for Articles

8. did my last MacAPL article get through?

9. MCM-70 Article

10. Smalltalk Article

11. BYTE Magazine APL Article

 

 
Powered by phpBB® Forum Software