[Asterisk-biz] Call termination database 0.2

[Alistair Cunningham]

Michael,

Considered this, rejected it as it's easy just to do multiple offerings, 
and am now considering it again as it's "the right thing to do", fits 
what you and Kevin are asking for, allows for sub pattern matches, and 
is probably less load on the database server than regular expressions.

It'll mean a code and interface redesign, but I'm not too opposed to 
that, as I really want to get the question of exactly what services 
people want to offer sorted out, and that may mean a redesign anyway.

In the meantime, I've done the code to allow vendors to specify a URL 
that the system hits once a day to get offerings. I'm not going to 
upload it to the production machine, however, until we get these 
questions sorted out.

Alistair Cunningham,
Integrics Ltd,
Telephony, Database, Unix consulting worldwide
+44 (0)7870 699 479
http://integrics.com/


Michael Welter wrote:
> Not trying to horn in on the design, but what if you uncoupled the rate 
> information from the "destinstion pattern"?  Each rate entry would be 
> identified by plan_id.  Each plan_id would have a one-to-many 
> relationship with destination_pattern.  So the Destination table would 
> contain "destination_pattern" and "rate_id" fields, while the Rate table 
> would have "rate_id" as the primary key, and all the other fields we've 
> talked about.
> 
> Then I could just point 1303, 1720, and 1646 to one rate_id entry.
> 
> Just my 2¢.
> 
> 
> _______________________________________________
> Asterisk-Biz mailing list
> Asterisk-Biz at lists.digium.com
> http://lists.digium.com/mailman/listinfo/asterisk-biz
> 
>