Hi Leo,
vorab ganz was anderes:
wenn du in deiner Datenbank nach Nummern suchst, Streichst du ja von der
Telefonnummer solange hinten Stellen weg, bis du die Nummer findest.
Idee: W�re es nicht �berlegenswert, das von der anderen Seite her
anzugehen? ich eine, von vorne solange Nummern dazuzugeben, bis du
_nichts_ findest, der letzte erfolgreiche Suchvorgang ist dann dein
Ergebnis?
z.B. Nummer* +4917212345
A:-Tag: +49
altes System:
+4917212345
+491721234
+49172123
+4917212
+491721
+4917
+491
+49 -> Treffer!
neues System:
+4 -> Treffer
+49 -> Treffer
+491 -> daneben
8 Suchvorg�nge gegen 3 Suchvorg�nge!
Es kommt nat�rlich darauf an, wie lange die durchschnittlichen A:-Tags
bzw. die Telefonnummern sind. Aber dr�ber nachdenken sollte man auf
jeden Fall!
So, und jetzt zu deiner Mail:
> > Gehen wir die Design-Frage mal von hinten her an: Die rate.cc.dat
> > entsteht aus verschiedenen Dateien, f�r jeden Provider eine
> (zumindest
> > f�r Deutschland). In welcher Datei stehen dann die Services?
>
> Zentral in rate-CC.dat
Kann ja nicht, weil die rate-de.dat erst _entsteht_.
> > Ich sage: in der services.dat, diese Datei wird aber _nur_ vom
> > Preprozessor gelesen, und dann alle S:-Tags bei den providern auf
> > �bereinstimmung mit den Eintr�gen aus services.dat gepr�ft. Mich
> (also
> > rate.c) interessiert dann die globale S:-Tabelle nicht mehr, weil
> ich
> > mir diese aus den provider-Eintr�gen selbst zusammenbauen kann.
>
> Ist latuernich auch eine Moeglichkeit. Bedeutet aber einen neuen
> Config-Eintrag, wieder eine Datei / Konfiguration, die der User nicht
> hat (s. auch SuSE 6.1 und 6.2 ??)
nein nein nein nein. Diese Datei wird _nur_ vom Preprozessor gelesen,
und der �berpr�ft dann, ob die S:-Eintr�ge bei den Providern bekannt
sind (bzw. ob Tippfehler drinnen sind). In der Bin�rfassung existiert
diese Datei nicht mehr (so wie die countries.dat).
> > Implementierung: es gibt kein struct SERVICE, sondern nur das
> bestehende
> > struct ZONE, mit einem zus�tzlichen Flag "ich bin ein Service". Die
> > Service-Tabelle selbst (so ich sie brauche) ist eine Liste von
> Zeigern
> > auf struct ZONE's.
>
> Nicht ganz, besser gesagt gar nicht, naemlich e.g.:
>
> S:EMS
> N:02290414
>
> S:Diverse Ortstarife
> N:02290*
>
> ...
> P:01,1
> Z:1
> A:...02290
>
> Also die Service matchen per Wildcard _viele_ Nummern oder auch eine
> Nummer exakt in verschiedenen Service-Arten, beim Provider steht genau
> die Nummer, die der Provider hat.
> Daher ist die Definition einer Servicenummer nur dann ident, mit dem
> A:Tag beim Provider, wenn diese Nummer exakt so beim Provider steht.
> (Was in obigen Beispiel nicht stimmt)
> Jetzt kannst du natuerlich das Umdrehen, und beim Provider jedes
> einzelne Service definieren, aber sinnig ist das IMHO nicht, ich habe
> keine Zeit dazu.
Ich verstehe das jetzt nicht wirklich. hast du ein besseres Beispiel?
bye, Michi
--
netWorks Vox: +43 316 692396
Michael Reinelt Fax: +43 316 692343
Geisslergasse 4 GSM: +43 676 3079941
A-8045 Graz, Austria e-mail: [EMAIL PROTECTED]
_______________________________________________
Rates4linux-devel mailing list
[EMAIL PROTECTED]
http://lists.SourceForge.net/mailman/listinfo/rates4linux-devel
