hi Stefan, > > Das Problem entsteht durch einen Verstoß gegen Regeln der > Normalformenlehre > (http://de.wikipedia.org/wiki/Normalisierung_(Datenbank)). Man kann > das in diesem konkreten Fall zwar lösen, wie von Edgar gezeigt. Im > Allgemeinen aber bezahlt man fehlende Normalisierung mit einem höheren > Aufwand bei einer späteren Weiterentwicklung und mit geringerer > Robustheit gegen fehlerhafte Eingaben. der ursprungsgedanke des admins beim thema "wir brauchen JETZT ne adressdantebank :)
nur wie erklaerst admin dem kunden dass so eine daten bank aus mehreren tabellen bestehen MUSS, besonders wenn so schnick schnack gewuenscht ist . ;) ist er ja frueher oda spaeter sowiso immer, sagt bruederchen erfahrung ... > > Wie würdest Du beispielsweise die Aufgabe lösen, wenn die Anzahl der > Projekte jedes Delinquenten gesucht ist? Wie verhinderst Du ungültige > Angaben im Feld ProjektNr, die durch banale Tippfehler entstehen > können? Wie stellst Du sicher, dass nur tatsächlich existierende > Projektnummern eingetragen werden? Und so weiter. > jau danke fuer die schoene formulierung ;) > Du hast zwischen Projekten und Delinquenten eine n-zu-m-Beziehung, die > Du IMO besser durch drei in Relation stehende Tabellen mit > referenzieller Integrität abbilden solltest. > so will ich es auch letztendlich bauen .... leider ist die datenbank schon "im betrieb" und die user basteln schon fleissig abfragen und berichte ... deswegen wirds erstmal edgars loesung sein ... irgentwann giebts dann einen neuen release :) > Gruß > > Stefan > :-) > gruesse und danke alexander --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
