Vorgehensweise bei Unique Index
Moderator: Moderatoren
- Jan
- Marvin
- Beiträge: 14662
- Registriert: Fr, 23. Sep 2005 18:23
- Wohnort: 49328 Melle
- Hat sich bedankt: 21 Mal
- Danksagung erhalten: 88 Mal
- Kontaktdaten:
Re: Vorgehensweise bei Unique Index
Dann sollten wir das auf der DevCon machen. Der Chat im April fällt aus, weil wir da ja gerade erst aus Isernhagen zurück sind. Das wird dann etwas viel für den Monat.
Jan
Jan
Mitglied der XUG Osnabrück
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.
- Markus Walter
- Programmier-Gott
- Beiträge: 1018
- Registriert: Di, 24. Jan 2006 10:22
- Wohnort: Saarland
Re: Vorgehensweise bei Unique Index
Hi Tom,
Deine Ausführungen sind durchaus verständlich. Ich glaube aber nicht, dass Alaska da was ändern wird. Dazu müsste ja wirklich in bestimmten Situationen (nämlich wenn ein Datensatz aus dem Unique-Index fliegt) eine komplette Sichtung der Daten in der DBF erfolgen, um festzustellen, ob es einen weiteren Kandidaten gibt, der nun "nachrücken" könnte. Das ist Laufzeittechnisch sicher mehr als problematisch. Oder es müssten gleich alle Datensätze im Unique-Index enthalten sein und nur durch die "Navigation" das unique generiert werden (ähnlich wie beim Scope).
PS: Ich habe es einfach. Ich verwende Unique-Indexe nur temporär (durchaus für von Dir genannte Beispiele).
Deine Ausführungen sind durchaus verständlich. Ich glaube aber nicht, dass Alaska da was ändern wird. Dazu müsste ja wirklich in bestimmten Situationen (nämlich wenn ein Datensatz aus dem Unique-Index fliegt) eine komplette Sichtung der Daten in der DBF erfolgen, um festzustellen, ob es einen weiteren Kandidaten gibt, der nun "nachrücken" könnte. Das ist Laufzeittechnisch sicher mehr als problematisch. Oder es müssten gleich alle Datensätze im Unique-Index enthalten sein und nur durch die "Navigation" das unique generiert werden (ähnlich wie beim Scope).
PS: Ich habe es einfach. Ich verwende Unique-Indexe nur temporär (durchaus für von Dir genannte Beispiele).
Gruß
Markus
Mitglied der XUG Saarland-Pfalz
Markus
Mitglied der XUG Saarland-Pfalz
- Tom
- Der Entwickler von "Deep Thought"
- Beiträge: 9394
- Registriert: Do, 22. Sep 2005 23:11
- Wohnort: Berlin
- Hat sich bedankt: 104 Mal
- Danksagung erhalten: 364 Mal
- Kontaktdaten:
Re: Vorgehensweise bei Unique Index
Hallo, Markus.
Das Problem sehe ich ebenfalls, wie ich ja auch mehrfach erwähnt habe. Georg hat es veranschaulicht: Der Unique-Index "sieht" eben nur einen Teil der Datensätze. Bei Änderungen oder Ergänzungen ist das unproblematisch, aber bei Löschungen müsste eben die komplette Datenquelle gesichtet werden, was bei einigen tausend Datensätzen ziemlich haarsträubend werden könnte. Implizite Mechanismen (der Index enthält doch alle Datensätze, aber die Engine überspringt sie) wären keine Lösung, denn dann wäre ja nicht mehr der Index selbst "unique".
Ich kann aber mit diesem - nunmehr bekannten - Fehlverhalten umgehen. Dank an Jan dafür, dass er das Problem entdeckt hat! =D>
Das Problem sehe ich ebenfalls, wie ich ja auch mehrfach erwähnt habe. Georg hat es veranschaulicht: Der Unique-Index "sieht" eben nur einen Teil der Datensätze. Bei Änderungen oder Ergänzungen ist das unproblematisch, aber bei Löschungen müsste eben die komplette Datenquelle gesichtet werden, was bei einigen tausend Datensätzen ziemlich haarsträubend werden könnte. Implizite Mechanismen (der Index enthält doch alle Datensätze, aber die Engine überspringt sie) wären keine Lösung, denn dann wäre ja nicht mehr der Index selbst "unique".
Ich kann aber mit diesem - nunmehr bekannten - Fehlverhalten umgehen. Dank an Jan dafür, dass er das Problem entdeckt hat! =D>
Herzlich,
Tom
Tom
- brandelh
- Foren-Moderator
- Beiträge: 15706
- Registriert: Mo, 23. Jan 2006 20:54
- Wohnort: Germersheim
- Hat sich bedankt: 70 Mal
- Danksagung erhalten: 34 Mal
- Kontaktdaten:
Re: Vorgehensweise bei Unique Index
Am Besten wäre eine Erweiterung durch ein Flag, mit dem ein normaler Index die doppelten Sätze automatisch überspringt.
So könnte man sich einen Index sparen, alle Probleme wären beseitigt und dennoch würden die alten Programme genauso weiterlaufen wie sie sind
So könnte man sich einen Index sparen, alle Probleme wären beseitigt und dennoch würden die alten Programme genauso weiterlaufen wie sie sind
Gruß
Hubert
Hubert
- Manfred
- Foren-Administrator
- Beiträge: 21224
- Registriert: Di, 29. Nov 2005 16:58
- Wohnort: Kreis Wesel
- Hat sich bedankt: 210 Mal
- Danksagung erhalten: 67 Mal
Re: Vorgehensweise bei Unique Index
Hm,
wäre es bei einem Flag nicht so, dass die doppelten übersprungen werden müßten? Das käme doch einem Filter gleich, oder? Das frisst doch Zeit? In einem Unique ist ja immer nur max. 1 Satz vorhanden, da muß nicht gesprungen werden.
wäre es bei einem Flag nicht so, dass die doppelten übersprungen werden müßten? Das käme doch einem Filter gleich, oder? Das frisst doch Zeit? In einem Unique ist ja immer nur max. 1 Satz vorhanden, da muß nicht gesprungen werden.
Gruß Manfred
Mitglied der XUG Osnabrück
Schatzmeister des Deutschsprachige Xbase-Entwickler e.V.
großer Fan des Xbaseentwicklerwiki https://wiki.xbaseentwickler.de/index.p ... Hauptseite
Doof kann man sein, man muß sich nur zu helfen wissen!!
Mitglied der XUG Osnabrück
Schatzmeister des Deutschsprachige Xbase-Entwickler e.V.
großer Fan des Xbaseentwicklerwiki https://wiki.xbaseentwickler.de/index.p ... Hauptseite
Doof kann man sein, man muß sich nur zu helfen wissen!!
- brandelh
- Foren-Moderator
- Beiträge: 15706
- Registriert: Mo, 23. Jan 2006 20:54
- Wohnort: Germersheim
- Hat sich bedankt: 70 Mal
- Danksagung erhalten: 34 Mal
- Kontaktdaten:
Re: Vorgehensweise bei Unique Index
Hallo Manfred,
ein Filter ist nicht automatisch langsam !
Langsam ist er nur, wenn er sehr viele Datensätze ohne Treffer überspringen muss.
Ich nutze gerne einen Hauptindex der die Daten begrenzt (auch mit scope) und dann darin einen Filter für komplexere Aufgaben.
Wie wäre es bei dem geschilderten Problem ?
Wahrscheinlich ist es eher selten, dass viele Datensätze den gleichen Indexkey haben, diese liegen auch sortiert hintereinander UND
die DBE könnte nach dem ersten Treffer einen dbseek() auf den Datensatz mit einem höheren Indexbegriff vornehmen.
Die Performance wäre in den allermeisten Fällen genauso schnell wie bisher, wenn man die Verwaltung eines extra Index sparen kann,
könnte es sogar schneller werden.
ein Filter ist nicht automatisch langsam !
Langsam ist er nur, wenn er sehr viele Datensätze ohne Treffer überspringen muss.
Ich nutze gerne einen Hauptindex der die Daten begrenzt (auch mit scope) und dann darin einen Filter für komplexere Aufgaben.
Wie wäre es bei dem geschilderten Problem ?
Wahrscheinlich ist es eher selten, dass viele Datensätze den gleichen Indexkey haben, diese liegen auch sortiert hintereinander UND
die DBE könnte nach dem ersten Treffer einen dbseek() auf den Datensatz mit einem höheren Indexbegriff vornehmen.
Die Performance wäre in den allermeisten Fällen genauso schnell wie bisher, wenn man die Verwaltung eines extra Index sparen kann,
könnte es sogar schneller werden.
Gruß
Hubert
Hubert
- Manfred
- Foren-Administrator
- Beiträge: 21224
- Registriert: Di, 29. Nov 2005 16:58
- Wohnort: Kreis Wesel
- Hat sich bedankt: 210 Mal
- Danksagung erhalten: 67 Mal
Re: Vorgehensweise bei Unique Index
Ich stehe jetzt aiuch vor dem Problem. Wäre es dann wirklich eine bessere Lösung das mit einem CANDIDATE Index zu lösen?
Gruß Manfred
Mitglied der XUG Osnabrück
Schatzmeister des Deutschsprachige Xbase-Entwickler e.V.
großer Fan des Xbaseentwicklerwiki https://wiki.xbaseentwickler.de/index.p ... Hauptseite
Doof kann man sein, man muß sich nur zu helfen wissen!!
Mitglied der XUG Osnabrück
Schatzmeister des Deutschsprachige Xbase-Entwickler e.V.
großer Fan des Xbaseentwicklerwiki https://wiki.xbaseentwickler.de/index.p ... Hauptseite
Doof kann man sein, man muß sich nur zu helfen wissen!!