Hallo! > K�nnte das jemand mal in ein paar einfachen Worten zusammenfassen, was > denn nun der cleverste Ansatz ist um doppelte rauszuwerfen?
Es gibt keinen K�nigsweg. > Was ich auch nicht gesehen habe: wie macht man denn am geschicktesten > die Entscheidung welcher von zwei Datens�tzen rausfliegt, wenn man nur > weiss das die Telefonnummer gleich ist. Genau das ist die entscheidende Frage: Welcher Datensatz fliegt und welcher darf bleiben? Die Antwort darauf hat in der Regel nichts mit Datenbanktechnologie zu tun. > Habt ihr da auch einen Ansatz diskutiert, wie man die verschiedensten > Schreibweisen von Telefonnummern abf�ngt. Eine ganzheitliche L�sung kann nur �ber eine strenge, eindeutige Datenbanklogik erfolgen. Man stelle sich vor, dass einerseits Telefonnummern �ber das Web in die Datenbank gelangen, zus�tzlich welche aus der Kundenverwaltung und zum Schluss noch eine ganze Menge Telefonnummern aus einer anderen Datenquelle importiert werden. Also gibt es drei Applikationen (IIS/ASP, Client/Server und DTS), die jeweils Daten in die Datenbank hineinschieben. Sp�testens jetzt wird klar, dass die Datenlogik getrennt von der Gesch�fts- und Pr�sentationslogik zentral in der Datenbank abgehandelt werden muss. Dazu reicht es aus, die Telefonnummer auf Ziffern zu reduzieren und als UNIQUE-Index zu deklarieren und schon bleibt die Datenbank sauber. F�r die Darstellung der Daten am Bildschirm oder Drucker kann man dann die Ziffernfolge wieder mit "+"-Zeichen oder Klammern oder Bindestrichen erg�nzen. Tats�chlich werden Telefonnummern aber als Text gespeichert, wobei es dem Anwender freigestellt wird, ob er Klammern, Bindestriche, Leerzeichen oder "+"-Zeichen einsetzt. Dabei kann man in SQL-Server die Telefonnummer als 64-Bit-Integer ablegen und �ber eine Benutzerdefinierte Funktion die Zeichenkette einheitlich mit Klammern erzeugen. Allerdings sind dabei dann Hilfstabellen mit Vorwahlnummern erforderlich, es sei denn, die Telefonnummer wird von vornherein auf 4 Felder aufgeteilt. Genau das gleiche Chaos findet man bei Adressdatenbanken. Kaum eine Tabelle gliedert den Namen richtig in Rufname, Sonstige Vornamen, Stammname, Namenspr�fix und Namenssuffix. So gibt es immer Probleme bei der Dublettensuche, bei der Zusammenfassung von Familien oder bei der Sortierung von Namen. F�r das Bereinigen von Adressdatenbanken werden im Einzelfall sogar Millionenbetr�ge gezahlt. Dabei k�nnte man heute sehr viel im Hinblick auf eine saubere Datenlogik tun. Freundliche Gr��e Joachim van de Bruck PS: Der Name "van de Bruck" wird unter "B" einsortiert (erstes gro� geschriebenes Wort im Namen) und nicht unter "V". Auch werden "van" und "de" klein geschrieben. Der Vorname lautet "Joachim" und nicht "Joachim van de". ;-) | [aspdedatabase] als [email protected] subscribed | http://www.aspgerman.com/archiv/aspdedatabase/ = Listenarchiv | Sie k�nnen sich unter folgender URL an- und abmelden: | http://www.aspgerman.com/aspgerman/listen/anmelden/aspdedatabase.asp
