nicht angemeldet
Moin moin,
So langsam verstehe ich, wo dein Problem liegt. .... Es braucht ja nur ein Eintrag hinzuzukommen, der laut Sortierung eigentlich auf der derzeitigen Seite angezeigt werden müßte. Das kann man wirklich nur durch Einzelblätterung vermeiden.
Nein, das kann man auch nicht durch Einzelschritte vermeiden. Es ist nicht ausgeschlossen, dass Du gerade einen Filterbereich verlassen ahst und jemand fügt sozusagen hinter deinem Rücken zwanzig neue Sätze ein. Aber dafür gibt es ja TimeStamp. Ich bin sowieso ein Metadaten-Fanatiker: Wann erstmalig angelegt, von wem, von wo (IP), wann letzmalig verändert, von wem, von wo (IP), Wem gehört der Datensatz (Owner, Gruppenliste -- Sieht aus wie Unix, gell?) usw..
Ein Zeiger ist etwas, was zeigt. In diesem Fall auf den ersten Datensatz der auszugebenden Liste, basierend auf den Daten zum Zeitpunkt der Abfrage. :) Etwas, was auf Datensätze zeigt, ist ein Datensatzzeiger. :) Das Problem ist nicht der Zeiger, sondern was man in der Zukunft damit macht.
Das interessiert mich auch nochmal. Ist das resultset unter MySQL ein Dynaset oder ist es ein Snapshot?
Wenn ich das richtig verstanden habe, dann liegen im Resultset keinesfalls die Daten, sondern nur die Zeiger auf die angeforderten Felder der gefundenen Datensätze. Demnach müßte also eine Änderung an einem Datensatz, die nach meiner Abfrage, aber vor meiner Bearbeitung des Satzes liegt noch bis zu mir durchschlagen.
Durch die Verarbeitsroutine der DBE rauschen alle Sätze durch und werden auf Erfüllung des Kriteriums untersucht.
Wobei anzumerken ist: Wenn du nach meiner Methode in der gesamten Datenmenge blättern willst, brauchst du gar kein Kriterium anzugeben.
Ein Kriterium (match) hast Du ja angegeben (&such%). Mein Kriterium ist die Übereinstimmug eines Suchbegriffes mit dem ANFANG eines indizierten Feldes (Name) und dem absoluten Wert eines zweiten indizierten Feldes (ID). Das sit für eine mäßig gute DBE per Indes auflösbar.
Damit muß meine Lösung nicht die gesamte Datenmenge durchsuchen sondern erst ab der Stelle, an der Teilkriterium 1 (Anfang des Namen = Index auf Name) gilt.
Das nennt man den Aufsetzpunkt.
Ich vermute, der Unterschied zwischen meinem Ansatz, alle Datensätze zu sortieren und nur einen Ausschnitt zu holen, und deinem Ansatz, nur die nachfolgenden/vorhergehenden Datensätze abzufragen, zu sortieren und einen Ausschnitt zu holen, dürften annähernd identisch performen.
Ich hoffe nicht. Deine Lösung wird man für Deinen Fall nicht besser machen können. Du suchst nach einem Match mitten im Feldinhalt. Das lässt sich nur durch sehr komplizierte Hashtables erreichen und das Verfahren ist patentiert. Das kann sich eine GNU-Software niemals leisten. Du kannst deshalb keinen Indes verwenden und musst ALLE Datensätze durchlesen. Ich fange bei meiner Problemstellung erst ab Aufsetzpunkt an zu lesen.
Dein Ansatz hat den Vorteil, daß die zu sortierende Menge kleiner sein kann (durchschnittlich nur 50% meiner Datenmenge), aber den Nachteil, daß ein Kriteriums verglichen werden muß.
Die Menge IST kleiner, und ein Kriterium muss bei der SUCHE immer verglichen werden. Beim HOLEN von Daten sit das nicht notwendig, denn da weiß man, wo sie stehen. Soweit zur Begriffsbestimmung auf Deutsch. Ist vielleicht mein Problem, dass ich Deutsch rede. Da nimmt mich keiner Ernst ;-)
b. brauchen der Auswahlprozedur keine Sätze zugeführt zu werden, die überhaupt nicht passen
Wenn man alle Datensätze haben will, kommt man nicht drum herum, alle Datensätze anzugucken. :)
Ich will ja nicht alle Datensätze haben, sondern z.B. nur den Bereich MA.... bis MZ... (Dynamsiche Sachbearbietertrennung). Und weil ich einen Index auf das relavanteste Feld lege, muss ich kir auch nicht alle Sätze angucken.
c. wird erkannt, wann der zu untersuchende Bereich der Tabelle garantiert beendet ist, nämlich wenn des nächste Index-Item größer ist, als das Suchkriterium (Das geht bei Dir batürlich nicht, da Du %bla% suchst, also es kein "Größer" gibt.)
Ähm???
Ja, Du suchst nach einem "Match", also nach der Übereinstimmung einer kurzen Schablone mit einem langen Datensatz. Die könnte sogar mehrfach in Deinem Satz vorkommen. Da muss man lesen, lesen, lesen
Ich denke, es gibt für unsere beiden Ansätze ein ganz grundlegendes Problem: Die gedachte komplette Liste der Datensätze kann sich mittendrin ändern.
Genau das isses!
Das bedeutet, daß ein "Blättern" natürlich nicht mehr so möglich ist, daß man alle Datensätze erhält. Dies ließe sich nur dadurch vermeiden, daß die eindeutige, bei jedem Datensatz incrementierte ID als einziges Sortierkriterium herangezogen wird - nur dann sind vorhergehender und folgender Datensatz eindeutig definiert: Es ist der nächste existierende Datensatz, dessen ID kleiner oder größer als die derzeitige ID ist. Neue Datensätze werden am Ende der Liste angefügt. Man könnte also solange den nächsten Datensatz anfordern, bis keiner mehr kommt. Und nach einer Wartezeit wäre vielleicht wieder einer da.
So ungefähr könnte man die Organiation betreiben. Als Tagesabschluß müssten dann immer noch die Nachträge bearbeitet werden, um tagesaktuell zu sein.
Diesen letzten Absatz möchte ich noch in der Diskussion halten. Hier ist noch Überlegungsbedarf und die Chance auf Pfiffige Lösungen.
Basierend auf dieser Überlegung dürfte klar sein: Ein Blättern in einer Namensliste ist so unmöglich hinzukriegen, da es immer doppelte Namen geben wird.
Doppelte Namen sind durch die Verbindung mit der ID überhaupt kein Problem mehr.
Und auch wenn du basierend auf dem Namen und der ID ein eindeutiges Sortierkriterium generierst, hast du immer noch das unlösbare Problem, daß neue Datensätze, wenn sie in der gewünschten Sortierung eingeordnet werden sollen, urplötzlich mitten in der Liste auftauchen.
Viel schlimmer: lange vor Beginn der Liste. Dafür braucht man dann wirklich einen separaten Bearbeitungsschritt.
Ja, die Gleichzeitigkeit ist ein Problem. Die Frage ist doch: Was soll per Blättern geschehen? Einen Datensatz bearbeiten? Das ist total unabhängig von anderen Datensätzen. Einem "Datensatz" eine Rechnung schicken? Auch kein Problem, wenn diese Aktion anderweitig ausgelöst wird, beispielsweise durch Vorliegen von Papier (Außendienstservicemeldung). Allen Datensätzen die Mitgliedsbeiträge abbuchen? Das wäre dann eher keine Aktion, die man per "Durchblättern" erledigen könnte.
Die einzige mir einleuchtende Lösung für solche Bearbeitungsschritte, die für alle Datensätze erledigt werden müssen, aber aus irgendwelchen Gründen nicht gleichzeitig erledigt werden können, wäre, daß man eine weitere Tabelle (oder Spalte - aber das könnte problematisch werden, weil zu starr) mit Statusmeldungen anlegt, in der genau verzeichnet wird, was mit welchen Datensätzen geschehen ist. Auf diese Weise findet man schnell heraus, welche Datensätze noch zu bearbeiten sind.
Ja, das wird ein Teil der Lösung werden.
Tja, dein Leben ist schwer, und eine richtige Lösung ist garnicht machbar - die Welt ist ungerecht.
Aber ich trink jetzt erst mal ein Schöööönes Hefeweizen - prost
Bleibt das oben erwähnte Problem: Was ist, wenn ein Datensatz, der auf diese Seite gehören würde, hinzukommt? ;)
Kann man nicht lösen mit HTML. Sollte man auch bei Echtzeit-dialogfähigen Systemen nciht versuchen. Da kann kein Mensch mehr mit arbeiten. Immer Serialisierung der Arbeitsschritte betreiben.
So Sven! Nun bin sich mit der Betrachtung durch Deine Hilfe schon wieder ein Stück weitergekommen. Wir sind da schon ganz schön tief eingestiegen. Habe auch schon einige Meldungen erhalten, dass es Andere auch interessiert, sie aber nicht mehr mitkommen. Vielleicht sollten wie diese beiden Fälle hinterher mal als Beispiele Aufbereiten. Das wär mir die Mühe wert.
Liebe Grüße
Tom