MySql Adressstamm

[Bernie110]

Hallo Zusammen,

ich bin langsam so weit, dass man sich Gedanken über die Datenbankstruktur macht.
Wäre für ein paar Tips wirklich dankbar.

Jetzt geht es erst einmal um verschiedene Adressen und deren Haltung in der Datenbank.

Hier mal die Adressen die es gilt zu verwalten :
Auftraggeber
Rechnungsempfänger
Absender
Empfänger
Dienstleister usw.

In meinem letzten Projekt (Access-Frontend & SQL Server) , hatte ich alle Adresse in eine Tabelle geschmissen und über diese Kriterien bestimmt für was genau die Adresse steht.
War eigentlich gar nicht so unperformant bei ca 80.000 Adressen.
Vorteil war, dass man eben nur in einer Tabelle suchen musste.
Nachteil war, dass halt eben auch Adressleichen entstanden.

Jetzt wäre die Überlegung vll für alle Arten jeweils eine eigne Tabelle anzulegen.
Hätte halt den Nachteil, dass man immer alle einzeln durchsuchen muss. Muss ehrlich gestehen...keine Ahnung
Wie macht ihr das ? Was wäre eure Meinung hierzu ?
Wäre für ein paar Tips echt dankbar.
Lg Bernie

[fliegermichl]

Naja die Adressen selbst kann man in eine Tabelle schreiben. Falls es eindeutig ist, reicht ein Feld AdressArt in dem steht, worum es sich bei der Adresse handelt. Wenn eine Adresse mehreren Adressarten zugeordnet werden kann/soll so benötigst du eine weitere Tabelle in der die Adressarten zu den Adressen in Beziehung gestellt werden.

[Bernie110]

Naja die Adressen selbst kann man in eine Tabelle schreiben. Falls es eindeutig ist, reicht ein Feld AdressArt in dem steht, worum es sich bei der Adresse handelt. Wenn eine Adresse mehreren Adressarten zugeordnet werden kann/soll so benötigst du eine weitere Tabelle in der die Adressarten zu den Adressen in Beziehung gestellt werden.

Hi, Danke für deine Antwort. Genau so hatte ich das mal gemacht.
Also du meinst, man kann das auch bei mehr als 80.000 DS so beibehalten ? Stösst es nicht irgendwann an Grenzen ? Wenn ja wo würde liegen ?
Lg Bernie

[fliegermichl]

Naja die Adressen selbst kann man in eine Tabelle schreiben. Falls es eindeutig ist, reicht ein Feld AdressArt in dem steht, worum es sich bei der Adresse handelt. Wenn eine Adresse mehreren Adressarten zugeordnet werden kann/soll so benötigst du eine weitere Tabelle in der die Adressarten zu den Adressen in Beziehung gestellt werden.

Hi, Danke für deine Antwort. Genau so hatte ich das mal gemacht.
Also du meinst, man kann das auch bei mehr als 80.000 DS so beibehalten ? Stösst es nicht irgendwann an Grenzen ? Wenn ja wo würde liegen ?
Lg Bernie

Genau kann ich es nicht sagen, da müsste man die Dokumentation der SQL Datenbank zu Rate ziehen. Aber 80.000 ist Pipifax. Bei mehreren hundert Millionen kann das vielleicht irgendwann problematisch werden.
Das ganze ist ja auch abhängig von der Größe der einzelnen Datensätze und dem darunterliegenden Dateisystem.

[Bernie110]

Naja die Adressen selbst kann man in eine Tabelle schreiben. Falls es eindeutig ist, reicht ein Feld AdressArt in dem steht, worum es sich bei der Adresse handelt. Wenn eine Adresse mehreren Adressarten zugeordnet werden kann/soll so benötigst du eine weitere Tabelle in der die Adressarten zu den Adressen in Beziehung gestellt werden.

Hi, Danke für deine Antwort. Genau so hatte ich das mal gemacht.
Also du meinst, man kann das auch bei mehr als 80.000 DS so beibehalten ? Stösst es nicht irgendwann an Grenzen ? Wenn ja wo würde liegen ?
Lg Bernie

Genau kann ich es nicht sagen, da müsste man die Dokumentation der SQL Datenbank zu Rate ziehen. Aber 80.000 ist Pipifax. Bei mehreren hundert Millionen kann das vielleicht irgendwann problematisch werden.
Das ganze ist ja auch abhängig von der Größe der einzelnen Datensätze und dem darunterliegenden Dateisystem.

Naja man könnte dieser Tabelle mehrere Kriterien geben und gleich beim Suchen ausschliessen. Zb. über ein Land / Bundesland oder eben auch die PLZ.
Müsste man wohl einige Sichten am SQL anlegen und beim suchen die entsprechende ansprechen oder ?
Dann könnte man das Pferd vielleicht ganz gut reiten Nur so eine Idee..

[af0815]

Als Beispiel, der MSSql Server kann entsprechend skaliert werden, da spielen millionen von Datensätzen keine Rolle. Die entsprechenden Indizies dann schon

Generell mal ein Design zu überlegen und sich mit normalisierung zu beschäftigen. Siehe auch Lazinfos und dort das über normalisierung. Das gibt einen guten Guide für die Aufteilung.

Zuätzlich beim MsSql server auch die Tools für den executionplan verwenden. Gerade dort kann man sich ansehen was der Server vorhat.

BTW: Ich rede deshalb über MSSql Server weil Access und Server im ersten Post erwähnt werden.

[Winni]

Hi!

Finger weg von Access! Nix als Ärger! Des Öfteren Reorganisation der Datensätze. Stillstand des Win-Clients und andere Scherze.

Winni

[Bernie110]

BTW: Ich rede deshalb über MSSql Server weil Access und Server im ersten Post erwähnt werden.

Finger weg von Access! Nix als Ärger! Des Öfteren Reorganisation der Datensätze. Stillstand des Win-Clients und andere Scherze

Warum sind immer alle so geschockt wenn der Name Access fällt
Kommt halt drauf an was man damit macht Wenn ich Probleme mit Access hatte, dann nur weil ein Server Admin pennte
Aber ihr habt schon recht... es hat viele Schwächen wenn man weiter entwickeln möchte... Internet und Access... kein Vergnügen.
Aber genau deshalb versuch ich gerade auch auf Lazerus zu wechseln.
In manchen Bereichen vermisse ich Access .. aber vielleicht kommt mir das nur so vor, weil man in Lazerus kaum etwas vorkonfiguriert bekommt.
Vll eine reine Gewöhnungssache ..werden wir sehen

Generell mal ein Design zu überlegen und sich mit Normalisierung zu beschäftigen. Siehe auch Lazinfos und dort das über normalisierung. Das gibt einen guten Guide für die Aufteilung.

Jep ich weiss was Normalisierung ist.
Naja dann heisst es mal ...los und schauen was draus wird
Herzlichen Dank für eure Tips !!! Klasse Forum hier ! *log*
Lg Bernie

[af0815]

Access ist ok, wenn es im Rahmen seiner Möglichkeit als Desktopdatenbank betrieben wird. Kein Thema. Das heißt aber auch ein Benutzer und nur ein PC auf der Datenbank zur selben Zeit. Und wenn die Version zur aktuellen Betriebssystemumgebung passt.

Absolut abzulehnen ist Access wenn irgendwelche 'Gurus' auf die Idee kommen, das als Multiuser, MultiPC System zu verwenden udn auch noch VBA als über drüber empfinden. Dann kann man nur noch eine Access Allergie bekommen. Und die besteht für den Rest des Lebens. BTW: Diese Gurus sind dann meist so esotherisch wie die ordnungsgemäße Funktions des Programmes - nie gesehen.

Ich oute mich hier mit einer bestehenden Access und Excel Allergie

[charlytango]

Access hat mir einiges an Qual und unnötiger Stunden eingebrockt.
Ist schon vor langer Zeit zugunsten von MySQL, MariaDB und MSSQL (je nach Umgebung und Anforderungen) rausgeflogen.
Als Frontends dazu dann immer ObjectPascal (also Delphi oder nun mehr nur Lazarus).
Und ich komme noch aus einer Zeit als ich 2,5 Mio Records in einer DBX Tabelle verwalten musste ggg

Wo ich Access noch einsetze ist als Abfragewerkzeug und Reportgenerator für Enduser.
Mit einem winzigen Frontend vordefinierter Abfragen das im Laufe der zeit alle wichtigen Abfragen des Kunden ansammelt.
Der Zugriff auf die Datenbank ist dabei immer nur auf Leserechte (bzw auch nur einzelne Tabellen bzw Queries eingeschränkt) dann können auch die dümmsten User nix kaputt machen.

[Bernie110]

Access hat mir einiges an Qual und unnötiger Stunden eingebrockt.
Ist schon vor langer Zeit zugunsten von MySQL, MariaDB und MSSQL (je nach Umgebung und Anforderungen) rausgeflogen.
Als Frontends dazu dann immer ObjectPascal (also Delphi oder nun mehr nur Lazarus).
Und ich komme noch aus einer Zeit als ich 2,5 Mio Records in einer DBX Tabelle verwalten musste ggg

Wo ich Access noch einsetze ist als Abfragewerkzeug und Reportgenerator für Enduser.
Mit einem winzigen Frontend vordefinierter Abfragen das im Laufe der zeit alle wichtigen Abfragen des Kunden ansammelt.
Der Zugriff auf die Datenbank ist dabei immer nur auf Leserechte (bzw auch nur einzelne Tabellen bzw Queries eingeschränkt) dann können auch die dümmsten User nix kaputt machen.

Hi,

naja die Diskussion, was eigentlich besser ist, bekommt man auch ab, wenn man Lazerus oder Delphi benutzt.
Pascal oder C++ ...Java oder was auch immer.
Habe schon hunderte Beiträge im Netz gelesen, wo sich Pascal Freunde mit C++ Jungs gegenseitig auf die Mütze hauen.
Ergo... da kann man wohl dann auch nichts richtig machen

Ich halte solche Diskussionen für reine Zeitverschwendung. Letztendlich kann man in allen Bereichen Mist abliefern.
Nichts für Ungut Lg Bernie

[af0815]

Ich halte solche Diskussionen für reine Zeitverschwendung. Letztendlich kann man in allen Bereichen Mist abliefern.
Nichts für Ungut Lg Bernie

Ja und nein. Ich sehe das pragramitscher. Mittlerweile ist es so, das M$ Access zugunsten des MS-SQL Servers zurückgeschraubt hat. Den gibt es übrigends in einer kleinen Variante für mehr oder weniger Free. Auch für Linux !! wenn es Ubuntu 16.x LTS ist, für dort wird er garantiert.

Übrigends wurde im ersten Post eine sehr genau Beschreibung des Umfeldes erklärt: Access-Frontend & SQL Server und 80.000 DS

Noch ein Hinweis warum es mit dem MS SQL-Server nicht schlecht zum arbeiten ist. Alle Features sind grundlegend vorhanden. Damit kann man in der Entwicklungsumgebung sich die Executionplans anzeigen lassen und nachsehen, wie der Optimierer des Servers arbeitet und dann kann man sich Schritte überlegen. Dann kann man testen, warum manchmal die 3te Normalform gar nicht so günstig ist. Joins, die schlecht gesetzt sind können eine Abfrage gewaltig verlangsamen. Ich habe damit Erfahrung gemacht bei einer weltweiten Betriebsdatenerfassung, wo 15-20 Mio. Datensätze in einer Tabelle vorhanden waren. Dort den falschen Join und ein falsches Design und du wartest Minuten auf eine Abfrage Das und ein paar Kurse bei M$ zum optimieren von DB-Servern haben da Spuren in mir hinterlassen.

Das beste ist, wenn man nicht genau weis wie man es angeht - DemoDB und mit automatisch generierten Testdaten soweit wie möglich füllen. Dann hat man eine Spielwiese für Performancetest. Das hilft bei der Entscheidung

Ich weis, im Header steht MySQL. Dort habe ich aber noch keine Tools für die tiefere Analyse gefunden wie beim MS-Sql. Viele Optimierer arbeiten aber ähnlich bei den DB-Systemen.

Gute Erfahrung kommt von schlechter Erfahrung

[Bernie110]

Gute Erfahrung kommt von schlechter Erfahrung

So siehts aus