JavaScript-Dauproblem...

JavaScript-Dauproblem... (49 Beiträge, 339 Mal gelesen)

Du bist nicht angemeldet. [ Login/Registrieren ]

Hi !

Bin wieder mal am Rumprimitiveln - diesmal wird's ein HTML/JS-Teil.
Ich versuche mal, das Problem zu reduzieren:

Gegeben sei eine Datenbank, in der es pro Guppe bis zu 100 Kundennamen gibt.

Ein Mitarbeiter soll jetzt in einem HTML-Formular nach Auswahl der Gruppe einen Kunden in eine Inputbox eingeben - wobei er implizit gleich neue Anlegen können soll.

Bisher hatte er eine freie Inputbox zur Verfügung, wobei natürlich das Problem entsteht, daß 3 Buchende denselben Kunden verschieden schreiben - und dadurch mehrere Einträge in der DB entstehen.

Mein Lösungsansatz wäre grob jetzt folgender:

Nach Auswahl der Gruppe wird ein XMLHttpRequest zum Server geschickt, der eine Liste der bekannten Kunden in der Gruppe holt.
Die Kunden werden dem Eingebenden in einem DIV oder so präsentiert. Wenn er auf einen klickt, soll der automatisch eingetragen werden
ansonsten kann er weiter frei eingeben

Folgende Probleme erwarte ich dabei:
1.) Das dauernde Requesten der bekannten Kunden macht ja wohl nur Sinn, wenn man es mit Caching am Client verheiratet. Der Client könnte sich also in einem Array merken, daß es in Gruppe "GRUPPE_1" zb die Kunden "Müller","Meier",... gibt.
Mir ist jetzt völlig unklar, wie ich eine Obergrenze des Cachings implementieren soll...

Wie erkenne ich, wann ich zuviele gecacht habe und wieder welche nach LRU wegwerfen soll ?
Bekomme ich aus JS meine Speicherauslastung raus ?
Oder soll ich eine willkürliche Grenze ziehen mit zB 1000 Kunden und danach die ältesten rauswerfen ?

Dann werden sowohl die Benutzer mit sehr alten als auch die mit sehr neuen Rechnern unglücklich sein ... Wie löst man sowas richtig ?

2.) Wenn parallel eingebucht wird, soll es möglich sein, daß

zB Benutzer A einen neuen Kunden in GRUPPE2 anlegt und
Benutzer B den automatisch auch in seiner Vorschlagsliste sieht, wenn er einen in Gruppe2 anlegen will.

Das bedeutet also, daß es eine Möglichkeit geben muß, daß Benutzer A den Cache von Benutzer B invalidiert. Wie löst man das ?
Mein billigster Lösungsansatz wäre,

daß Benutzer A einen eigenen Request an den Server schickt, wenn er einen neuen Kunden anlegt.
Der Server könnte eine SerialNumber/Sequence (ähnlich wie bei DNS) pro Gruppe haben, die er dann hochzählt.
Jeder Benutzer würde dann pro Buchung die SerialNumber der gerade aktuellen Gruppe am Server holen müssen -
und könnte so feststellen, wann er den eigenen Gruppencache invalidieren muß.

Kommt mir einfach aber beshissen vor.
Ein anderen Fall wäre, daß sich der Server merkt, welcher Client welche Stände kennt - und nur die Differenzen/neuen an den Client mitschickt. Kommt mir aber stressig und umständlich vor... Lösungsansätze ?

Ach ja, Gruppen gibt es rund 7000 - also es ist ausgeschlossen, daß man alles (Gruppen+Kunden) an den Client überträgt, vor allem, weil es dann mit der Adresse weitergeht

13.04.2006, 13:05 Uhr - Editiert von gepeinigter_aon_neukunde, alte Version: hier

Na Bui, als Dau-Problem würde ich das nicht sehen.
Darf ich hinterfragen wozu du cachen willst?

greetz
Walter

Weil die Listen Lange sind.

Meine Top-Liste bei einer Gruppe hat rund 4KB.
Das würde bedeuten, daß es bei ISDN als unterster Grenze 1/2 Sekunde dauern würde, bis die XML-Datei übertragen ist.

Zusätzlich dauert die Query der Datenbank rund 300-400ms - Also der User müßte pro Vorschlagsliste fast eine Sekunde warten. Das würde noch verschärft werden, weil nach der Kundenliste zusätzlich die Anschriftenlisten des Kunden in der jeweiligen Gruppe geholt werden müßte... Und es werden pro Benutzer bis zu 800 Vorgänge pro Tag gebucht.

Ohne Cachen wäre die Akzeptanz wohl [auch zurecht] unter aller Sau.

Hmmm, wie stellst du dir das Caching eigentlich vor?

greetz
Walter

Naja, ungefähr wie folgt [seeeehr pseudo]:

/*
  kundenliste-Beispiele:
  kundenliste[12]="Müller,Meier,Bubu,Franz";
*/
function check_kundenliste(gruppe)
{
  /* TODO: Check auf neuere Daten vom Server */
    if (kundenliste[gruppe])
        return;
    fetch_kundenliste(gruppe):
}

function befuelle_div_mit_kunden()
{
   foreach ($x in split(/,/,kundenliste[gruppe]) {
    tabelle.insertrow(...)
  }
}

function Benutzer_hat_Gruppe_gewählt(gruppe)
{
   check_kundenliste(gruppe);
   befulle_div_mit_kunden(gruppe);
}

EDIT:
Jedes fetch_kundenliste würde natürlich an den Kundenlisten-Cache anfügen.
Da der aber nicht unendlich wachsen darf, muß ich wohl ein LRU implementieren...

13.04.2006, 13:43 Uhr - Editiert von gepeinigter_aon_neukunde, alte Version: hier

Das liegt also in einem statischen Header/Frame/Whatever der permanent verfügbar ist?!?

Dir ist schon klar, wenn das zugehörige Browserfenster geschlossen wird oder mal eben kurz das Geizhals-Forum angesurft wird, der "Cache" leer ist? Ich kenn jetzt natürlich keine Details, aber was schätz du wie oft in einer "Session" der Cache Verwendung (reuse) findet?

greetz
Walter

Wieso statiscser Header/Frame/... ? Ich hole mir alles dynamisch via XMLHttpRequest. Die Seite verläßt der Bucher also nie....

Dieser Cache ist mit Aufruf eines neuen Fensters natürlich leer... Wobei ich als Rache für die ganzen IE-optimierten Seiten beinhart wahlweise Safari, Mozilla, Konqueror oder FF als Client fordere - damit haben's tabbed browsing und es sollte klappen

Auf den Browser-Cache muß ich leider verzichten... Denn ich will ja dynamisch meinen Cache invalidieren können (wenn in Phase 2 ein anderer Benutzer einen Neukunden anlegt)... Außer ich kann das aus JS triggern, das wäre auch nett... Idee dazu ?

ad 1) daraus ergibt sich für mich eine "quasi"-statische Oberfläche nach der Anmeldung/...
Aber das passt schon, war eh nur für mich fürs Verständnis.

ad 3) genau das überlege ich gerade.

greetz
Walter

ad 3) die Cache-Invalidierung könnte man genau so machen, wie in deinem Eröffnungsposting steht, in einem 2-Schritt Verfahren. Wenn sich die Gruppen-Id/Seq./... verändert hat, dann muss man den HTTP-Request für die Daten um diese ID/Seq. erweitern.
Damit dann nicht zu viele invalide Versionen einer Gruppe im Cache ewig herumkugeln, könnte man dem Daten-File ein Ablaufdatum umhängen.

greetz
Walter

Yup, das dachte ich mir auch schon...
Ein 10-minütliches timer-Script, das einen Request nach der "SerialNo" absetzt - und in einer globalen Variable speichert. Alle Requests könnten die dann mir "&SerNo=..." abschicken..

Einziger Shice ist dann noch, daß jedesmal sinnlos der XML-Stream geparst werden muß...

Werde es wohl so lösen.

Bleibt nur noch mein letztes Problem:
Wie stelle ich die 70 Kunden übersichtlich dar

Anyways, vielen Dank für's Ideen beisteuern!

Wie wär's, wenn du den Browser File-Cache nutzt?!?
Innerhalb des DIVs könntest du einen IFrame machen in dem das spezielle "Gruppen-File" angefordert wird. Vorausgesetzt der HTTP-Request ist für eine Gruppe immer gleich, sollte das funktionieren. Ich muss aber gleich vorwegschicken ich hab sowas noch nicht ausprobiert.

EDIT:
Was dabei allerdings noch fehlt, ist ein reload wenn ein neuer Eintrag vorhanden ist. Da werde ich noch etwas hirnschmalz reinlegen müssen

.

greetz
Walter

13.04.2006, 14:06 Uhr - Editiert von Sir Hondo, alte Version: hier

Hmm... Wozu brauche ich da den IFrame ? Habe in meinem Leben noch keinen Verwendet und wüßte gach den Vorteil in diesem Falle nicht... Was verpasse ich ???

Dieser Beitrag bezieht sich auf eine ältere Version des beantworteten Postings!

IFrame deswegen, weil der entsprechende HTTP-Request ein File liefert, das der Browser cachet. Ich behaupte jetzt mal unwissenderweise, dass ein XMLHttpRequest vom Browser nicht gecacht wird?!?

greetz
Walter

Der XMLHttpRequest liefert kein File sondern dynamisch Daten... Eigentlich ein Object... Und man kann sich das Cachen aussuchen (rennt über die "standard"-Schiene vom Browser)

Na dann wenn das eh gecacht wird, dann fehlt ja "nur" mehr, das invalidieren, müsste aber genauso wie da http://forum.geizhals.at/t412361,3337003.html#3337003 funktionieren.

greetz
Walter

Doch, wird er vom IE normalerweise schon. Hat sich in den vergangenen Tagen bei einem Projekt als ziemlich ärgerlich herausgestellt.
--
DiTech postete:
Sie haben offensichtlich 7mal mit dem Goldadler positive Erfahrung gemacht. Bei dieser Menge an Glück sollten Sie Lotto spielen.

GHF Watcher 1.2 - Firefox Erweiterung für Geizhals User

Prinzipielle Frage: Warum überhaupt AJAX? (gibts zu Du willst nur damit rumspielen!):
weil wenn der Kunde zuerst die Gruppe auswählen muß, dann werden eh max. 100 angezeigt und die kannst locker in seiner (Server) Session cachen und per "messagebroker" invalidieren lassen, wenn ein anderer die Gruppe in der Zwischenzeit upgedatet hat. D.h. ich würd die ganze Verarbeitung am Server lassen (außer es ist die zwingende Vorgabe, den Server zu entlasten)

Ablauf: User muß vor _jedem_ Anlegen suchen gehen -> suche am Server nach Kölner Phonetik (einfach gsagt, aber da gibts vielleicht schon irgendeine OSS lib dazu) -> dann Ergebnisanzeige -> erst dann Neuanlage.

Wennst html/js basteln willst, bist mit Deinem ajax ansatz eh schon am richtigen weg.
Aber aufpassen beim IE mit seinen js-memory leaks könntest unter Umständen (bei größeren Datenmengen) nicht wirklich glücklich werden (oder Du zwingst den User nach einer bestimmten Zeit in der Appl den Browser zu restarten

)

Sag halt, was für eine Lösung Du dann im Endeffekt implementierst, ist eine sehr intressante Aufgabe.
-
lesen, denken, googlen, nochmals denken, posten
google knows everything

Serverseitiges Cachen wäre auch meine erste Idee gewesen, allerdings dürfte er Bedenken bei der Datenübertragung haben (siehe http://forum.geizhals.at/t412361,3336805.html#3336805 ).

Dürfte wohl ein sehr anspruchsvoller Kunde sein. Antwortzeitverhalten bei einer ISDN-Verbindung unter 1 Sec.

greetz
Walter

Nun, ich muß auch selber drauf hackeln... Und ich habe im Haus nur ISDN

Und ja, als Kunde erwarte ich mir schnellste Performance........

gzip compression am apache (bzw. als filter - sehr elegant - in der J2ee Appl) aufdrehen,
soll wunder bewirken (filesize auf 1/8).

da mach ich mir dann keinen kopf mehr über ISDN&co - (zumindest bei 100 List-Einträgen/Gruppe) - bei den aktuellen Client-CPUs > 1GHz merkst es fast nicht
-
lesen, denken, googlen, nochmals denken, posten
google knows everything

Ahem...

Letztes mal staunte ich nicht schlecht, als die Teile meines Systems beinhart auch mit einem Pentium1-Rechner und Win2k drauf betrieben haben... Das Teil hatte aber eh 128MB Ram

Wenn dem nicht so wäre, hätte ich ja überhaupt keine Cache-Sorgen und würde einfach den Client alles mitmerken lassen, was er inzwischen bekommen hat - aber genau aus dem Eck entstanden ja erst meine "Wie ermittel ich die Auslastung in JS"-Überlegungen.

Bei etwas einfacherem (Einer Partie mit Kundennummern) wurde es so gelöst, daß ein JS-Sourcefile generiert wurde a la

PLZ[1]=1200;Name[1]='Bubu';Adresse[1]='Otto'
.....

(Wobei 1 die Kundennummer wäre).

Das Problem mit den 100 Kunden pro Gruppe wäre, daß er eben die 100 bei jeder Eingabe abrufen muß... Und danach die passenden Adressen, ...

Im Endeffekt will ich das ganze mit einer "Auto-Completion" in den Eingabefeldern verheiraten - dann wird's echt supi... Und da komm ich dann eh nicht dran vorbei.

Nachdem für mich AJAX-Gefriemel zeitaufwändig ist (weil neu für mich und ich JS /hasse/) - will ich das lieber gleich komplett machen anstatt nachher was drüberpflanzen zu müssen, was immer stressig ist. Außerdem bin ich grade dabei, meine PHP-Bibliotheken so anzupassen, daß ich in Zukunft einfachst AJAX-Bauteile zusammenstöpseln kann (so wie jetzt die "normalen" HTML/PHP/JS-Teile) - und gerade beim Framework bauen sollte man ja schon wissen, was man später wie lösen will...

Und natürlich will ich rumspielen

- außerdem geht's mir wie wohl jedem Ajax-Coder: Ich werde nach Stunden bezahlt

EDIT:
Diese Kundennummer-JS-Gschicht war schweinelangsam beim ersten Öffnen... Da macht AJAX schon Sinn (bis zu 12k Kundennummern)

EDIT²:
Ich bin ja absolut kein Webdesigner... Aber nach dem, was ich so mitbekommen habe Thema Behaviour Layer und so macht so eine Implementierung ja absolut Sinn via AJAX, oder ?

13.04.2006, 15:20 Uhr - Editiert von gepeinigter_aon_neukunde, alte Version: hier

Moment eiso mit AutoCompletion schaut die Sache gleich ganz anders aus.
Du kennst aber eh google suggestions oder?
http://www.google.com/webhp?complete=1&hl=en

Jetzt komma langsam hin:
-> User klopft 2, 3 Buchstaben ein, und Suche (innerhalb der Gruppe) geht los
-> Innerhalb der Gruppe können maximal 100 ergebnisse sein, welche ala google suggestions eingeblendet werden (da hab ich einen sauberes .js dazu)

-> willst das jetzt ernsthaft cachen? oder sinds 1.000e User die gleichzeitig auf dem Server rumhämmern? -> überlas das Caching der letzten "Instanz" in der Kette der DB - die weiß schon was sie tut (mehr oder weniger - und wenn das dann doch zu langsam wird denk ma nochmal drüber nach

bzw. zahlen einen teuren DBA, damit der doch die lahme DB schneller macht)

-> wennst wirklich caching basteln willst dann serverseitig, überhaupt wenn Du Dir auch noch Gedanken über langsame client-hardware machen mußt (und damit sparst Dir dann auch die Gedanken über client-cache-invalidation)

oder hab ich da jetzt was falsch verstanden
-
lesen, denken, googlen, nochmals denken, posten
google knows everything

Eher letzteres... Und ja, es soll so ähnlich wie bei google suggestions enden (plus zusätzlich eben der Vorschlagsliste)

Also gehen wir's mal durch, wie ich es mir dachte:
Gruppen sind sowieso am Client gespeichert.

Wenn die Gruppe "27" ausgewählt wurde (es werden immer viele Buchungen in derselben Gruppe erfolgen) - dann sollen eben nur die Kunden von Gruppe27 kommen. Wenn er sie beim ersten mal via AJAX holt, könnte er sie sich in einen Array wegspeichern. (Das werde ich nun wohl doch über den Page-Cache lösen).

Der Witz ist eben, daß meist wenige Gruppen Benutzt werden - da macht Cachen schon Sinn (insbesondere da es nur maximal 100 Elemente pro Gruppe sind)...

Ziel ist
- Reduktion des NW-Verkehrs (die XML-Antwort der größten Gruppe sind immerhin 4K) - und im Endausbau werden ca. 50 User drauf arbeiten.
- schnelleres Arbeiten beim Bucher (bis zu 800 Buchungen pro Tag und Bucher)
- Serverentlastung (der Server ist ja jetzt schon mit seinem bisherigen sehr beschäftigt).
- Ergänzung unseres PHP-Frameworks um einfache Methoden um andere Teile zu AJAXifizieren

- Umstellungen vieler bestehender "normaler" POST-Formulare um den Server weiter zu entlasten, wenn wir alles davor im griff haben.

NW-Anbindung ist /traurigerweise/ echt Thema... Ich habe bisher auch noch nie irgendwelche kommerziellen Kunden gesehen, die einen 400MB-pro-Monat-Tarif hatten (und jetzt kenne ich solche) - und glaub mir, ich habe es /ehrlich/ versucht, die zu einem Wechsel - wurscht wohin - zu bewegen.

Ad DBA:
Die Kompetenz des DBA dort ist praktisch nur durch sein überdimensioniertes männliches Sexualorgan sowie seine traumhafte Erscheinung erreichbar - das bin ich

. Nöö, aus DB-Sicht paßt's schon.

EDIT:
Das saubere js-Teil wäre nett... Würde mich freuen (wenn es frei ist)

13.04.2006, 16:23 Uhr - Editiert von gepeinigter_aon_neukunde, alte Version: hier

Also ich würd am Client und Server cachen.

Ich weiß nciht in was du codest aber ich würd in einer Ajax.net Methode am Server die "kunden" holen implementieren (anhand Gruppe) und in den page.cache legen. (sql dependency)

Am Client selbst hätte ich mir ein Array gemacht in dem ich bereits die Gruppen vorgegeben habe. (die brauchst du ja für die Auswahl wenn ich das richtig verstanden habe) und ein leres item (also 2 Dimensional)

Wenn die Gruppe ausgewählt ist schauen ob das Item nothing ist . Wenn nothing dann die ajax.net routine aufrufen die mir ein datatable mit den items retour gibt. Wenn nicht nothing dann die .net routine aufrufen mit anzahl der kunden im vorhanden datatable im array und in der .net routine checken ob der cache verfallen ist. In dem Fall die Daten neu aus der DB holen und an den Client schicken.

Selbst 7000 Kunden (jeweils nur name) die da auf einmal geladen werden haben ja nur ein paar kB. Am client selber ist das total wurscht.

Hi !

Also das mit dem Cachen am Server muß so oder so her - ich dachte allerdings an eine Materialized View (vielleicht ist das eh dasselbe - dein dauerndes ".Net" verwirrte mich etwas

).

Das mit den "paar KB"... Nun ja, wenn das so wurscht wäre, täte ich mir das net an.

Das mit den Kunden hast falsch verstanden - oder ich schlecht formuliert.
Es sind ca. 7000 Gruppen mit je bis zu 100 Kunden... Das ist in Summe schon etwas. Durchschnittlicher Kundennamen wohl 20 Bytes, dazu kommen dann noch (im nächsten Schritt) die bekannten Anschriften pro Kunde - im Schnitt wohl 2-3 pro Gruppe/Kunde...

Aber Serverseitiges Cachen ist - genau wie du schreibst - absolut entscheidend, keine Frage,.

Naja ich entwickle (nur) in ASP.net bzw. .net allgemein. Daher keine Ahnung wie die Dinger in PHP oder wo auch immer heißen.

Also fakt ist ja jetzt du musst mal alle Gruppen auf den Client laden. Um dort eine Auswahl zu treffen.
Richtig oder? Diese Gruppen würd ich gleich am Anfang gleich mal via AJAX auf den Client holen in ein Array (bespreiben wir es mal so) mit eben 7000 Zeilen und 2 Spalten.

Erste Spalte enthält eben den Gruppennamen und die zweite Spalte ist eben frei um dort ein object mit den Kundendaten reinzuladen. Wenns nur 100 Kunden pro Gruppe sind werden das wohl gerade 2 kb sein beim Übertragen.

Und dann steht ja dem Server UND Clientseitigen Cachen ja nichts mehr im weg. :D

Stimmt... Die Gruppen selbst müssen so mal runter....

Und dann werde ich es wohl a la
http://forum.geizhals.at/t412361,3337068.html#3337068 lösen...

Ich würds nicht über den Browsercache lösen. Damit kanns ja wieder sein (wenn das Teil xx Minuten gültig ist) dass ein andere den selben Kunden in der Zeit anlegt. Außerdem jedes mal das XML Prasen is ja auch piep ...

Daher SQL Dependency und DataTable am Client. *gg* Damit is es Echtzeit und sicher um nix langsamer.

Undying

Naja, über den BrowserCache so wie hier:
http://forum.geizhals.at/t412361,3337068.html#3337068

Und natürlich ist jedesmal XML Parsen Schrott - allerdings kann ich ja nicht sagen, wie's am Client mit dem Ram aussieht...

Und was bitte ist ne DataTable am Client ? Irgendein Klumpat, daß M$-SW am Client braucht ? Sorry, kenn ich nicht

Ajax.net ist eine implementierung um Objekte die es in .net gibt (DataView, DataTable, usw.) einfach am client verwenden zu können ohne viel extra manuell coden zu müssen. FUnktioniert auch im FireFox.

Schau mal dort hin wenns dich interessiert.
http://www.schwarz-interactive.de/

Undying

Und wie kann man ermitteln, was da so hin-und-her übertragen wird ?
Ist aber eh wurscht - keine Win-Server

Wie meinst ermitteln? Das machst ja am Server.

am client sagst zB

function getCustomerByGroup(intGroupID)
{
//Check ob Kunden schon im Array vorhanden.
//Falls nein boolFirstLoad = true
//Falls ja intClientRow.... = kundenanzahl damit festgestellt weden kann ob bereits kunden hinzugekommen sind.
namespace.class.getCustomerByGroup(intGroupID, intClientCustomerRowsCount, boolFirstLoad, getCustomerByGroup_loadfinished);
}

function getCustomerByGroup_loadfinished(result)
{
if (result.value != 'noNewGroup')
{
arrayGroups[context.intGroupID][2] = result.value;
}
//Kunden geladen, Eventuell aktuallsiert wenn notwendig gewesen
//Mein Div erstellen und mit den Kunden befüllen
// for context.intGroupID][2].rows ...
}

Alles andere macht das Ajax.net Pro Framework für dich. (async aufruf der Daten)
Auf der Serverside brauchst dafür nichtmal 10 zeilen inkl. Chaching.

Und wo ist da jetzt die DataTable ?
Oder ist mit DataTable mehr so eine Methodik gemeint ???

Dann habe ich es falsch verstanden... Ich dachte, daß seien Funktionen.

Ajax.net Pro Framework... Klingt net billig.
Also Serverseitig brauche ich jetzt nur noch 4 PHP-Zeilen für solche Teile... Das Framework-Selbstschreiben dauerte allerdings zugegeben lange

Kostenlos is es das Ajax.net Pro.

Naja ist schwer das einen nicht .netler zu erklären :D Die DataTable ist einfach eine Tabelle (eine Klasse in JS) die gewisse funktionen anbietet und eben eine Tabelle die man normalerweise am Server hat ist am client mit gewisser funktionalität darstellt/anbietet.

Meine paar Zeilen sind ohne Framework und SQL Dependency :D *gg* (sprich der Cache am Server wird automatisch zerstört sobald sich die betroffenen Zeilen der Tabelle ändern

)

Codest du alles in PHP? Oder andere Programmiersprachen auch noch? Interessiert mich ..

Also meine DB ist ne PostgreSQL... Die habe ich in C um einige Funktionen erweitert.
Außer C und (Postgre-)SQL mache ich eigentlich nur viel in PHP und Perl...

Hi !

Habe es jetzt so probiert, wie du es meintest (und ich mir auch dachte) - mit dem Client, der zuerst alle Gruppen holt.
2 Probleme traten auf:
1.) Mein Server hat 1MBit up - und ich habe es von Chello daheim probiert. Das dauert trotzdem schweinelange.... Meine XML-Antwort war ungefähr
[?xml...]
[result rows='6900']
[row nr='1' GruppeID='12345' NAME='ich bin die tolle Kundengruppe']
[row nr='2' ...
[/result]

Die Query für den Teil dauert nun am Server rund 8ms - also das ist nicht der Engpaß. Ich vermute, daß es eher am parsen der XML-Daten am Client liegt.

2.) Ich bin jetzt wieder selbst via ISDN unterwegs... da dauert das extremst lange (allerdings nicht über 100x so lange wie man bei beim Wechsel ISDN-Chello erwarten dürfte). Das spricht für mich auch nach dem Problem des Clients.

Ich werde es also so umbauen, daß beim erstmaligen Versuchen einer neuen Gruppe der Server gefragt wird, ob es sie gibt - und der Client die dann wegcacht. Das müßten als Query weniger als 200 Bytes sein können - und die Antwort ebenfalls. Sollte also auch bei ISDN in weniger als einer zehntel Sekunde da sein... Das ist akzeptabel für einen Check.

Hi!

Deine Methode ist zwar extrem "web2"-like, aber tierisch unergonomisch.
Die Leute wollen reintippen - ohne Hemmungen, Wartezeiten, sich ändernden und meist falschen Auto-Suggests etc., und dann auf Enter hauen. Dieses "zähe" Verhalten beim Tippen weil ständig JS arbeitet, oder der Server wie blöde ackert, bringt genau das Gegenteil von "usability".

Ich mach das so, daß es ein Eingabefeld gibt, in dem der Anwender mehrere Suchbegriffe (mit Wildcards) erfassen kann, und erst nach einem vom Anwender bestimmten Schritt (auf Enter hauen), etwas passiert - dafür dann aber etwas wirklich "gscheites".
Denn dann wird der Suchbegriff am Server zerlegt und die Adressensuche bezieht sich auf fast alle Felder der Adresse. Inklusive Notizfeld. Und phonetisch optimiert.
Z.Bsp.: Meier Wien Antonig* 12
Würde alle "Maier", "Mayer" oder "Meier" in der Antonigasse 12 in Wien bringen.
Der Anwender bekommt dann eine Liste mit Adressen, sortiert nach der Trefferquote, sofern die Quote über einen Mindestwert liegt. Maximal aber 5 Adressen. Der Fokus liegt auf der Adresse mit der höchsten Trefferquote und kann einfach mit Enter übernommen werden.
Andernfalls kann direkt zur Neuanlage gewechselt werden.

Um die notwendige Performance zu erreichen, wird bereits beim Abspeichern einer Adresse, über einen DB-Trigger der Eintrag analysiert und dann die phonetischen Einzelteile indiziert.
So merkt man auch bei 34000 Kunden so gut wie keine Verzögerung, und die Anzahl an Doppeleinträgen hält sich wirklich in Grenzen.

Wir müssen zwischen Such- und Eingabemasken trennen.
Bei Suchmasken gebe ich dir 100%ig recht...
Ist aber ne Eingabemaske, wo der Benutzer schnell Punkte erfassen muß. Trotz aller notwendiger Workarounds klappt das jetzt recht fein...

fyi: Die phonetische Optimierung heißt "Kölner Phonetik" und da haben sich schon einige Leute den Kopf darüber zerbrochen. Im Englischen heißt's "Soundex".
-
lesen, denken, googlen, nochmals denken, posten
google knows everything

Sorry, aber den Soundex-Algo halte ich für sinnlos... Da bevorzuge ich die Levenshtein-Distanz oder Double-Metaphone....

Begründung:
Soundex hängt fix am ersten Buchstaben und hilft nur gut bei Vokalen.. (MAYR/MAIER/...)

http://serversideguy.blogspot.com/2004/12/google-suggest-dissected.html
-
lesen, denken, googlen, nochmals denken, posten
google knows everything

Dieses Forum ist eine frei zugängliche Diskussionsplattform.
Der Betreiber übernimmt keine Verantwortung für den Inhalt der Beiträge und behält sich das Recht vor, Beiträge mit rechtswidrigem oder anstößigem Inhalt zu löschen.
Datenschutzerklärung