Gegen Datenredundanz vorbeugen..

[Bine]

HI,
hat jemand eine Routine die gegen eine Eingabe doppelter Datensätze schützt?

Danke Sabine :-)

[Bernhard Berger]

Ich würde das auf Datenbankebene lösen, indem ich einen Index setzen würde, in dem die Feldwerte eindeutig sein müssen

[Bine]

Hi Bernhard,
wie mache ich das?

ich habe einen sekundärindex angelegt, der eindeutig ist.
Oder bin ich da auf dem falschen Weg?

Was ist wenn ich eine Überprüfung machen will, ob doppelte Datensätze vorhanden sind?

Bitte um Hilfe
BINE :_

[Bine]

Query1.Locate('feldname', edit1.Text, [loPartialKey]);
soo? vielleicht?

Wie geben ich das in eine Abfrage?
Wer kann mir helfen

[Bine]

if Query1.Locate('feldname', edit1.Text, [loPartialKey]):= true then
begin
..
end;

???so?

Wenn ja dann schreibt er mir folgende Meldung beim Compilieren:

"record, objekt oder klassentyp erforderlich"

[Andreas Kosch]

Hallo,

in meinem Buch <i>Client/Server Datenbankentwicklung mit Delphi</i> ist ein Beispielprojekt, das eine "unscharfe Suche" nach doppelten Datensätzen über den <b>Soundex</b>-Algorithmus implementiert. Dabei werden auch Eingabefehler bzw. unterschiedliche Schreibweisen mit relativ hoher Trefferquote gefunden. Die Suche in der Datenbank findet über einen zweiten Thread in einer zweiten Session statt, so dass die Suche im Hintergrund läuft, während der Bearbeiter die restlichen Daten ausfüllt. Immer dann, wenn ähnliche Schreibweisen gefunden werden, erhält der Bearbeiter eine Information und kann sich alle Fundstellen anzeigen lassen bzw. eine Fundstelle auswählen.

Der Vorteil der Hintergrundsuche in einem zweiten Thread liegt darin, dass das eigene Programm (d.h. die Datenerfassung) von der Suche nicht betroffen ist.

Für den Fall, dass unterschiedliche Schreibweisen oder Tippfehler nicht vorkommen können, würde ich einen <b>eindeutigen Index</b> auf diese Tabellenspalte legen (so wie bereits vorgeschlagen wurde). Beim Posten des neuen Datensatzes legt dann die Datenbank (bzw. die BDE/VCL) durch das Auslösen einer Exception ein Veto ein, so dass der doppelte Datensatz niemals in der Tabelle gespeichert werden kann. Man muss also nicht vorher prüfen, ob der Datensatz bereits vorhanden ist, sondern nur die Exception beim Speichern abfangen/auswerten. Auch dafür sind Beispiel in dem o.g. Buch zu finden

[markus lemcke]

tag andreas,

nichts gegen deine bücher, aber sabine ist noch reichlich unerfahren in datenbankprogrammierung und da <br>
sind deine bücher etwas "harte" kost!!!!

ich muß zugeben, wenn ich einen mainindex, auf ein feld lege was nachher bearbeitet werden soll, <br>
hatte ich immer die fehlermeldung "index schreibgeschützt"! was macht man da verkehrt???

bei mir sind mainindexe immer vom typ zähler!!!!!

mfg

marku

[Andreas Kosch]

Hallo,

ein Feld vom Typ AUTOINC sollte man auch niemals in eigener Regie updaten, wobei es sogar so weit geht, das ein Primärschlüsselwert (Mainindex alias PRIMARY KEY) niemals geändert werden sollte. Immer dann, wenn im Primärschlüsselwert eine programmspezifische Information steckt, würde ich das Datenmodell ändern und zu einem neutralen INTEGER für den Primärschlüssel greifen. Die eigentliche Information wird in einer separaten Spalte gespeichert, die einen eindeutigen Index (UNIQUE INDEX) erhält. Und der darf beliebig geändert werden, solange das Ergebnis eindeutig bleibt.

P.S: Was das Buch angeht magst Du im ersten Moment Recht haben, aber in der Praxis sind die einfachen Anwendungen sehr selten, so dass einfache Beispiel nur einen begrenzten Nutzen haben. Der Sinn der Beispiel-Projekte besteht ja darin, dass man sich in die Implementierung "hineinwühlen" kann, um diese später als Vorlage für eigene Projekte zu nehmen.
&#10

[markus lemcke]

tag andreas,

wenn ich dich richtig verstanden habe, soll mein also keine spalte zum mainindex erklären, die vom anwender<br>
geändert werden kann, oder??

zum Buch:
ich habe halt festgestellt, daß die bücher wo du früher für den franzis-verlag geschrieben hast, <br>
für anfänger besser geeignet sind, wie die bücher die du jetzt schreibst!! ich habe 4 bücher von dir<br>
vom franzisverlag, weil die waren echt genial!!!<br>
deine neuen bücher sind mir stellenweise zu "hoch", aber wahrscheinlich liegt es daran, daß ich ein <br>
<b>schlechter</b> programmierer bin!!!

mfg

marku

[Andreas Kosch]

Hallo Markus,

zur Frage 1: Ja.

In den "guten alten Zeiten" war die Situation auch anders - zum einen stellte Delphi 1, 2 oder 3 im Vergleich zu heute nur eine deutlich bescheidenere Funktionalität zur Verfügung. Und zum anderen war das Umfeld (Internet, Betriebssystem, Anforderungen der Auftraggeber) auch einfacher und schlichter. Damals hinkte die Hardware (CPU, Festplatte und RAM) der Software hinterher, so dass es ein "natürliches Hardware-Limit" gab. Heute ist es umgekehrt - die Software kann die Hardware nicht mehr vollständig ausnutzen, was jedoch dazu führt, dass die vom Auftraggeber an die Software gestellten Forderungen steil noch oben gehen :-(

Dieser gesteigerten Komplexität tragen die Bücher Rechnung, wobei sich jedes nur mit einem speziellen Gebiet befasst. Wenn ich mir jetzt die demnächst erscheinende neue Fassung von <i>COM/DCOM mit Delphi</i> anschaue, sind innerhalb von 15 Monaten aus 471 Seiten bereits über 1100 Seiten geworden (COM/DCOM --> COM+). Leider wird sich dieses Innovations-Tempo in unserer Branche in Zukunft noch erhöhen, so dass die "guten alten Zeiten" wohl endgültig vorbei sind.
&#10

[markus lemcke]

zur frage 1. <br>
wenn der mainindex vom typ zähler ist, wie gelingt es mir dann zu verhindern, daß in einer<br>
adressdatenbank z. b. kein name <b>doppelt</b> eingegeben werden kann!!<br>

ja, die ganze programmierei ist ziemlich komplex geworden!!!!<br>
ich will mich gerade in die homepageprogrammierung einarbeiten und weiß nicht wo anfangen!<br>
habe jetzt grundkenntnisse in html jetzt wurde mir aber offenbart, daß ich noch php, java,javscript,<br>
pearl, xml und dhtml können sollte!!!!<br>
na, das nächste halbe jahr habe ich zu tun <b>mindestens</b>!!!!!!!!!!

mfg

marku