Woerterbuch optimieren

[Bjoern_96ed05]

Hallo,

ich habe ein kleines Wörterbuch in einer Access-Datenbank. Ganz simpel: in einer Spalte das englische Wort, in der anderen Spalte das deutsche Wort.

Laeuft auch, allerdings ziemlich langsam. Da der Inhalt jetzt erweitert werden soll muesste man schon auf eine schnellere Loesung kommen.

Ich habe mir einfaeltigerweise folgendes ueberlegt:

zwei Datenbanken mit je 27 Tabellen. Jede Tabelle enthaelt nur die Woerter mit gleichen Anfangsbuchstaben und eine eben Zahlen. Klar?
Da aber die deutschen Woerter dann falsch stehen, muesste die Datenbank nochmal abgelegt werden, jetzt aber nach den deutschen Woetern sortiert.

Dann koennte man bei der Abfrage eines Wortes schnell den ersten Buchstaben abspalten und in der Tabelle nachschauen. Allerdings wird bei der Pflege ein wenig mehr Sorgfalt und Arbeit benoetigt. Ausserdem verdoppelt sich der benoetigte Speicherplatz.

Gibt es noch andere Ideen, wie man so etwas handhaben kann?

Ciao und Danke! Bjoern

[erichsz]

Warum einfach wenn es auch kompliziert geht? Du hast mir mit Deiner Phantasie mächtig imponiert! Spass beiseite:
Ich würde die zweispaltige Tabelle behalten, diese aber in eine Paradox-DB umwandeln und dann die Sache mit DELPHI verwursten. Ein Witz davon ist, dass Du dann INDEXieren kannst, also je einen Index auf deutsch und englisch anlegen. Du wirst staunen, wie rasch die Suche geht.
Das Programm ist in 1-2 Stunden geschrieben. Wichtig ist, dass Du die Operationen „Hinzufügen/Löschen/Ändern“ einbaust. Das geht auch sehr einfach, wenn Du die Sache nicht unnötig aufspaltest.
Alles klar?
Erich

[Bei dieser Antwort wurde das Vollzitat nachträglich automatisiert entfernt]

[wortfuchs]

Hallo Bjoern,

ich kann mir nicht vorstellen, dass Access zu langsam ist. Statt auf 27 Tabellen aufzuteilen, würde ich mir eher einmal Gedanken machen, warum es so langsam ist:

• Ist die Tabelle richtig indiziert?
• Ist die SQL-Abfrage suboptimal?
• Erfolgt der Zugriff über ein Netzwerk oder eine lokale Platte?
• Ist dein Datenbestand so groß, dass Access generell Probleme bekommt?
• Wieviele Einträge haben deine Tabellen?
• …

Wenn du mir deine DB postest, werfe ich gerne mal einen Blick darauf!

Gruß Markus

[michael_f7f5bc]

stimme zu!
die „lösung“ mit 27 tabellen ist sicherlich keine praktikable

[Bei dieser Antwort wurde das Vollzitat nachträglich automatisiert entfernt]

[Bjoern_96ed05]

Hallo Bjoern,

ich kann mir nicht vorstellen, dass Access zu langsam ist.
Statt auf 27 Tabellen aufzuteilen, würde ich mir eher einmal
Gedanken machen, warum es so langsam ist:

• Ist die Tabelle richtig indiziert?

Die Tabelle enthaelt 420.000 Zeilen und drei Spalten: Primaerschluessel, Englisches Wort, deutsche Uebersetzung

• Ist die SQL-Abfrage suboptimal?

Der Zugriff erfolgt ueber Visual Basic mittels ADO und dem SQL Statement „SELECT * FROM LANG WHERE LANG.ENG LIKE ‚text%‘“

In der Abfragemaske soll man naemlich einen Buchstaben eingeben und das Programm zeigt automatisch alle Eintraege an, die mit diesem Buchstaben beginnen. Das selbe natuerlich auch, wenn man den zweiten Buchstaben eingibt etc…

• Erfolgt der Zugriff über ein Netzwerk oder eine lokale
  Platte?

Naja, ist noch nicht ganz klar. Das Ganze ist aus einem hausinternen Projekt gewachsen. Erst diente diese kleine Datenbank nur uns fuer unsere taegliche Arbeit und enthielt nur Fachbegriffe aus der Flugzeugtechnik die wir selber eingetragen haben. Jetzt haben wir uns aber drangesetzt und eine Sprachdatenbank eingebunden und moechten das Programm jetzt martreif machen. Wahrscheinlich erfolgt ein lokaler Zugriff

• Ist dein Datenbestand so groß, dass Access generell Probleme
  bekommt?

Nein, die Groesse der Datenbank liegt bei ca. 26MB, also noch weit weg von 2GB

• Wieviele Einträge haben deine Tabellen?

ca. 420.000

Wenn du mir deine DB postest, werfe ich gerne mal einen Blick
darauf!

Wuerd ich gern, geht aber leider nicht =:wink:

Kann dir nur die o.g. Angaben machen. Es kommt uebrigens kein Eintrag zweimal vor. Sortiert ist die Datenbank alphabetisch nach den englischen Begriffen.

Ciao! Bjoern

[wortfuchs]

Hallo Bjoern,

ich kann mir nicht vorstellen, dass Access zu langsam ist.
Statt auf 27 Tabellen aufzuteilen, würde ich mir eher einmal
Gedanken machen, warum es so langsam ist:

• Ist die Tabelle richtig indiziert?

Die Tabelle enthaelt 420.000 Zeilen und drei Spalten:
Primaerschluessel, Englisches Wort, deutsche Uebersetzung

Liegt der Primärschlüssel auf der Spalte LANG.ENG und ist eindeutig?
Wie sieht es mit LANG.GER (oder wie heisst die Spalte für deutsche Wörter?) aus?
Der Index ist für den Zugriff enorm wichtig!

• Ist die SQL-Abfrage suboptimal?

Der Zugriff erfolgt ueber Visual Basic mittels ADO und dem SQL
Statement „SELECT * FROM LANG WHERE LANG.ENG LIKE ‚text%‘“

Nachdem zu den Index geprüft hast und sich keine Verbesserung einstellt, kannst du das SQL-Statement umformen: … WHERE LANG.ENG >= ‚text‘
So kannst du in jedem Fall den Index ausnutzen.

• Erfolgt der Zugriff über ein Netzwerk oder eine lokale
  Platte?

Naja, ist noch nicht ganz klar. Das Ganze ist aus einem
hausinternen Projekt gewachsen. Erst diente diese kleine
Datenbank nur uns fuer unsere taegliche Arbeit und enthielt
nur Fachbegriffe aus der Flugzeugtechnik die wir selber
eingetragen haben. Jetzt haben wir uns aber drangesetzt und
eine Sprachdatenbank eingebunden und moechten das Programm
jetzt martreif machen. Wahrscheinlich erfolgt ein lokaler
Zugriff

Du musst dir klar machen, das Access immer direkt auf der Datenbasis arbeitet. Alle für die Abfrage benötigten Daten werden temporär auf den Client-Rechner kopiert, ausgewertet und dann wieder verworfen. Wenn der Index ausgenutzt werden kann, dürfte das auch im Netz kein Problem sein. Deine LIKE Abfrage durchsucht aber große Teile des Datenbestands, im Netz dürfte das kritisch werden.

Kann dir nur die o.g. Angaben machen. Es kommt uebrigens kein
Eintrag zweimal vor. Sortiert ist die Datenbank alphabetisch
nach den englischen Begriffen.

Klarer Fall für einen unique key …

Zudem kannst du für das SQL-Statement eine Abfrage im Access anlegen und abschliessend unter Extras/Analyse/Leistung von Access weitere Optimierungsmaßnahmen identifizieren lassen.

Gruß Markus

[Bjoern_96ed05]

Hallo Markus,

Liegt der Primärschlüssel auf der Spalte LANG.ENG und ist
eindeutig?
Wie sieht es mit LANG.GER (oder wie heisst die Spalte für
deutsche Wörter?) aus?
Der Index ist für den Zugriff enorm wichtig!

Ich verstehe jetzt nicht, was du meinst.

Der Primaerschluessel liegt in einer eigenen Spalte und ist somit an LANG.ENG und LANG.DE (so heisst die Spalte fuer deutsche Woerter) gebunden. Ja, er ist eindeutig.
Der Index ist in Spalte 2, also LANG.ENG definiert. Kann ich einen Index auch auf zwei Spalten derselben Tabelle definieren? Wie funktioniert das dann genau?

Nachdem zu den Index geprüft hast und sich keine Verbesserung
einstellt, kannst du das SQL-Statement umformen: … WHERE
LANG.ENG >= ‚text‘
So kannst du in jedem Fall den Index ausnutzen.

Das geht bei der Suche nach englischen Woertern. Was aber bei der suche nach deutschen Woertern? Ich glaube, ich braeuchte mal ein umfangreiches Dokument ueber Indizierung =:wink:

Du musst dir klar machen, das Access immer direkt auf der
Datenbasis arbeitet. Alle für die Abfrage benötigten Daten
werden temporär auf den Client-Rechner kopiert, ausgewertet
und dann wieder verworfen. Wenn der Index ausgenutzt werden
kann, dürfte das auch im Netz kein Problem sein. Deine LIKE
Abfrage durchsucht aber große Teile des Datenbestands, im Netz
dürfte das kritisch werden.

Die LIKE-Abfrage war damals schnell gemacht. Bisher bestand die Datenbank ja auch aus ca. 1.000 Eimtraegen.

Ciao! Bjoern

[wortfuchs]

Hallo Markus,

Liegt der Primärschlüssel auf der Spalte LANG.ENG und ist
eindeutig?
Wie sieht es mit LANG.GER (oder wie heisst die Spalte für
deutsche Wörter?) aus?
Der Index ist für den Zugriff enorm wichtig!

Ich verstehe jetzt nicht, was du meinst.

Der Primaerschluessel liegt in einer eigenen Spalte und ist
somit an LANG.ENG und LANG.DE (so heisst die Spalte fuer
deutsche Woerter) gebunden. Ja, er ist eindeutig.
Der Index ist in Spalte 2, also LANG.ENG definiert. Kann ich
einen Index auch auf zwei Spalten derselben Tabelle
definieren? Wie funktioniert das dann genau?

Der Primärschlüssel ist ein bestimmer Schlüssel der Tabelle, er sollte stets eindeutig sein. Meisst verwendet man ihn als ID-Wert einer AutoNumber-Spalte.
Darüber hinaus kannst du in der Tabelle weitere Indizes erstellen, die aus ein oder mehr Feldern bestehen dürfen. Wenn du die Tabelle im Editiermodus öffnest, erscheint in der Toolbar neben dem Symbol für den Primary key ein weiteres Symbol, hier kannst du die Indezes bearbeiten.

Nachdem zu den Index geprüft hast und sich keine Verbesserung
einstellt, kannst du das SQL-Statement umformen: … WHERE
LANG.ENG >= ‚text‘
So kannst du in jedem Fall den Index ausnutzen.

Das geht bei der Suche nach englischen Woertern. Was aber bei
der suche nach deutschen Woertern? Ich glaube, ich braeuchte
mal ein umfangreiches Dokument ueber Indizierung =:wink:

Bevor du das SQL umstellst, solltest du den Index prüfen. Wahrscheinlich ist dann alles viel schneller :o)

Die LIKE-Abfrage war damals schnell gemacht. Bisher bestand
die Datenbank ja auch aus ca. 1.000 Eimtraegen.

Theoretisch sollte Access bei der LIKE Abfrage den Index (sofern vorhanden) nutzen können. Stände das Wildcard am Anfang, so würde jedes mal die komplette Datenbank durchsucht …

Gruß Markus

[erichsz]

Nachtrag:
Hast Du auch schon LEO versucht oder ist Dein Wörterbuch sehr speziell?
http://dict.leo.org/
Erich

[Bei dieser Antwort wurde das Vollzitat nachträglich automatisiert entfernt]

[Bjoern_96ed05]

Hallo,

Nachtrag:
Hast Du auch schon LEO versucht oder ist Dein Wörterbuch sehr
speziell?
http://dict.leo.org/
Erich

Nun ja, Leo hat mehr Eintraege und sehr viel mehr Komfort und Funktionen, aber es gibt etwas ganz spezielles an meinem Woerterbuch: es ist offline =:wink:

Und es enthaelt sehr viele Fachbegriffe aus der Luftfahrt

Aber nochmal Danke an alle hier, die mir geholfen haben!

Ciao! Bjoern

[Bjoern_96ed05]

Hallo Markus,

Theoretisch sollte Access bei der LIKE Abfrage den Index
(sofern vorhanden) nutzen können. Stände das Wildcard am
Anfang, so würde jedes mal die komplette Datenbank durchsucht

Wie sieht eine solche Indizierung eigentlich aus? Wenn ich das Programm weitergebe ist ja nicht gesagt, dass auf den Zielrechnern auch Access installiert ist, funktioniert dann ueber den Zugriff per ADO auch noch die Indizierung?

Und, um mal zu was neuem zu kommen: wie sieht es mit der MSDE aus? Wenn ich keine lokale Datenbank im Access-Format nehme, sondern per MSDE auf eine zugreife, wie sieht die Installationsweise aus? Kann ich mit meinem Programm automatisch die MSDE installieren und auch gleichzeitig meine fertgie Datenbank einbinden?

Fragen ueber Fragen… =:wink:

Ciao! Bjoern

[wortfuchs]

Wie sieht eine solche Indizierung eigentlich aus? Wenn ich das
Programm weitergebe ist ja nicht gesagt, dass auf den
Zielrechnern auch Access installiert ist, funktioniert dann
ueber den Zugriff per ADO auch noch die Indizierung?

Für den Zugriff auf eine mdb-Datei benötigst du in jedem Fall eine Runtime. In deinem Fall ist das die Runtime für ADO, welche dir den Zugriff auf die Tabellen und Views erlaubt.
Schreibst du eine ganze Anwendung innerhalb von Access, also Formulare und Bericht, so benötigst du die Access-Runtime.

Zur Indizierung: SQL Datenbanken (auch Access) verwenden einen Optimierer, der sämtliche Abfragen an die vorhandenen Zugriffspfade (=Index) anpasst. Ob der Index existiert oder nicht, merkst du nicht am SQL. Bei deinem Übersetzer hast du nicht darauf achten müssen, existiert kein passender Index so durchsucht Access die komplette Tabelle nach dem gesuchten Key. Ist ein Index vorhanden, so kann Access sofort erkennen, ob der gesuchte Eintrag existiert. Der Unterschied: im ersten Fall vergleicht Access jeden Eintrag der Tabelle (=full table scan) während im zweiten Fall ein sortierter Index in deutlich weniger Schritten direkt zum Ziel führt.

Stell dir einen Karteikasten mit Adressen vor, die Karten liegen unsortiert vor. Bei der suche nach einer bestimmten Adresse fängst du beim ersten Blatt an und vergleichst die gesucht Adresse, bis du irgenwann das richtige Blatt findest. Im Mittel wirst du die Hälfte der Karten durchsuchen müsssen um einen Treffer zu erlangen.
Jetzt stell dir vor die Karten sind mit einem Karteireiter alphabetisch sortiert, hier kommst du doch wesentlich schneller zum Ziel. Alles klar?

Und, um mal zu was neuem zu kommen: wie sieht es mit der MSDE
aus? Wenn ich keine lokale Datenbank im Access-Format nehme,
sondern per MSDE auf eine zugreife, wie sieht die
Installationsweise aus? Kann ich mit meinem Programm
automatisch die MSDE installieren und auch gleichzeitig meine
fertgie Datenbank einbinden?

Zur MSDE kann ich dir nicht viel sagen. Du wirst sie zusammen mit deinem Programm installieren müssen.

Gruß Markus

[erichsz]

Hallo Björn
Wenn ich alle die guten Ratschläge lese, die mit ACCESS arbeiten wächst meine Ueberzeugung, dass es sich für Dich lohnt, einmal auf DELPHI zu schielen. Indexe = kein Problem. Installation aller notwendigen Elemente der Database Engine und der Datenbank mit einer mitgelieferten Installationsroutine kinderleicht(wie ein Windows-Programm). Wenn Du mir ein Stück Deiner Datenbank sendest, werde ich Dir ein DELPHI-Grundkonzept als Anschauungsunterricht schreiben (nur so als Hobby, ich verkaufe nichts).
Erich

[Bei dieser Antwort wurde das Vollzitat nachträglich automatisiert entfernt]

[wortfuchs]

Hallo Björn
Wenn ich alle die guten Ratschläge lese, die mit ACCESS
arbeiten wächst meine Ueberzeugung, dass es sich für Dich
lohnt, einmal auf DELPHI zu schielen. Indexe = kein Problem.
Installation aller notwendigen Elemente der Database Engine
und der Datenbank mit einer mitgelieferten
Installationsroutine kinderleicht(wie ein Windows-Programm).
Wenn Du mir ein Stück Deiner Datenbank sendest, werde ich Dir
ein DELPHI-Grundkonzept als Anschauungsunterricht schreiben
(nur so als Hobby, ich verkaufe nichts).

Vermutlich verweist du auf die Borland Database Engine. Aber auch hier musst du dir die gleichen Gedanken machen, Indezes anlegen und optimieren. Sogesehen ist die BDE eine alternative Datenbank. Am Datenbankdesign ändert das nichts.
Access hat da eher noch den Vorteil, mit nur einer Datei auszukommen. Per Doppelklick kannst du diese Datenbank auf jedem Rechner mit Access-Runtime öffnen und ändern.

Gruß Markus

[erichsz]

Ja, DELPHI + Borland Database Engine. Aber: Nur eine Datei bei Access ist hier kein Vorteil, es gibt sowieso nur EINE Tabelle, da es sich ja nicht um eine „richtige“ Datenbank handelt. Mit DELPHI ist die Installation auf beliebigen andern PCs sehr simpel und DELPHI ist eine sehr mächtige Sprache, nicht zu vergleichen mit den „Bordmitteln“ von ACCESS.
Aber: „Jedem Tierchen sein Pläsierchen“.
Gruss
Erich

[Bei dieser Antwort wurde das Vollzitat nachträglich automatisiert entfernt]