Grundlegendes Datenbankdesign

[af0815]

Mal hier die Diskussion über Design führen. Ist eine Fortsetzung des Diskussion von 'MySQL Einträge ändern'.

ralli hat folgendes geschrieben:
Das Problem ist oft das Gleiche, die Benutzer kennen Ihr Anforderungsprofil zu wenig, und richten sich dann nach dem, was sie von anderen mal gehört haben. Meisten setzen sie dann ein Datenbanksystem ein, was völlig überdimensioniert ist. Und wechseln von einem Sql System auf ein anderes mit der dazugehörigen Migration, dürdfte heute auch kein Problem mehr darstellen. Weil der Grundvorrat an SQL Befehlen ja auch sowieso standardisiert ist. Und Oracle dürfte wohl von der Ivestitionsseite für niemanden ernsthaft in Frage kommen. Ansonsten ist der Markt für Datenbanken erheblich geschrumpft und eher übersichtlich...
ralli


Das eher Philisophische daran ist, das es leider immer wieder vorkommt, da Leute gute Programme auf Desktopdatenbanken (DBase, Access,...) entwickelt haben und dann diese Anwendungen auf einen Server portieren. Und dann gehts am Anfang gut, bis die Datenmengen größer werden und dann herumgebastelt wird, damit das halbwegs funktioniert. Auch bei Schulabgänmgern und Proktikanten beobachtet. Keiner hat bei seinen kleinen Projekten sich je mit Datenmengen auseinandergesetzt. Und wunder sich, wenn bei einem 'Sel_ect * from table' plötzlich 200.000 Datensätze kommen und das ganze 1 Minute dauert Smile

Desktop Datenbanken sind gut und performant wenn richtig eingesetzt, aber man darf beim Design nicht wirklich aus den Augen verlieren, was kann als Datenmenge kommen und vor allen wie funktioniert die Wartung/Backup. Das Kapitel wird von den meisten gar nicht berücksichtigt.
Beispiel eine BDE Erfassung bei einem Schnellläufer (Maschine mit hohen Output) kann schon mal 100.000 bis 1.000.000 Buchungen am Tag bedeuten. Die täglich verdichtet werden. Da wird ein bereinigen der obsoleten Datensätze, ein Kompress im laufen, Auswertungen etc. zur Herausforderung und sogar 'poor Man' Server können da schon schnell in die Knie gehen, von Desktopdatenbanken ganz zu schweigen.
Das Problem ist, es macht sich keiner die Mühe, in seine Datenbank soviele Datensätze einzufüllen, das er in die Nähe der Projektierten Grenze kommt. Und wenn es 1000 Datensätz bei einer einfachen Adressverwaltung sind. Da kann es dann ganz schöne 'AHA' Erlebnisse geben. Gar nicht zu reden wenn es auf mehreren Arbeitsplätzen zugleich laufen soll.

Deshalb meine Meinung, man sollte das Design entsprechend auslegen, dort auch die Entwicklung hineinlegen (auch bei kleinen Projekten) denn dann ist die halbe Arbeit getan und der Rest ist Tippsen und Optik Smile

Das Problem ist oft das Gleiche, die Benutzer kennen Ihr Anforderungsprofil zu wenig, und richten sich dann nach dem, was sie von anderen mal gehört haben. Meisten setzen sie dann ein Datenbanksystem ein, was völlig überdimensioniert ist. Und wechseln von einem Sql System auf ein anderes mit der dazugehörigen Migration, dürdfte heute auch kein Problem mehr darstellen. Weil der Grundvorrat an SQL Befehlen ja auch sowieso standardisiert ist. Und Oracle dürfte wohl von der Ivestitionsseite für niemanden ernsthaft in Frage kommen. Ansonsten ist der Markt für Datenbanken erheblich geschrumpft und eher übersichtlich... ralli

Das eher Philisophische daran ist, das es leider immer wieder vorkommt, da Leute gute Programme auf Desktopdatenbanken (DBase, Access,...) entwickelt haben und dann diese Anwendungen auf einen Server portieren. Und dann gehts am Anfang gut, bis die Datenmengen größer werden und dann herumgebastelt wird, damit das halbwegs funktioniert. Auch bei Schulabgänmgern und Proktikanten beobachtet. Keiner hat bei seinen kleinen Projekten sich je mit Datenmengen auseinandergesetzt. Und wunder sich, wenn bei einem 'Sel_ect * from table' plötzlich 200.000 Datensätze kommen und das ganze 1 Minute dauert Desktop Datenbanken sind gut und performant wenn richtig eingesetzt, aber man darf beim Design nicht wirklich aus den Augen verlieren, was kann als Datenmenge kommen und vor allen wie funktioniert die Wartung/Backup. Das Kapitel wird von den meisten gar nicht berücksichtigt. Beispiel eine BDE Erfassung bei einem Schnellläufer (Maschine mit hohen Output) kann schon mal 100.000 bis 1.000.000 Buchungen am Tag bedeuten. Die täglich verdichtet werden. Da wird ein bereinigen der obsoleten Datensätze, ein Kompress im laufen, Auswertungen etc. zur Herausforderung und sogar 'poor Man' Server können da schon schnell in die Knie gehen, von Desktopdatenbanken ganz zu schweigen. Das Problem ist, es macht sich keiner die Mühe, in seine Datenbank soviele Datensätze einzufüllen, das er in die Nähe der Projektierten Grenze kommt. Und wenn es 1000 Datensätz bei einer einfachen Adressverwaltung sind. Da kann es dann ganz schöne 'AHA' Erlebnisse geben. Gar nicht zu reden wenn es auf mehreren Arbeitsplätzen zugleich laufen soll. Deshalb meine Meinung, man sollte das Design entsprechend auslegen, dort auch die Entwicklung hineinlegen (auch bei kleinen Projekten) denn dann ist die halbe Arbeit getan und der Rest ist Tippsen und Optik

Das Problem ist oft das Gleiche, die Benutzer kennen Ihr Anforderungsprofil zu wenig, und richten sich dann nach dem, was sie von anderen mal gehört haben. Meisten setzen sie dann ein Datenbanksystem ein, was völlig überdimensioniert ist. Und wechseln von einem Sql System auf ein anderes mit der dazugehörigen Migration, dürdfte heute auch kein Problem mehr darstellen. Weil der Grundvorrat an SQL Befehlen ja auch sowieso standardisiert ist. Und Oracle dürfte wohl von der Ivestitionsseite für niemanden ernsthaft in Frage kommen. Ansonsten ist der Markt für Datenbanken erheblich geschrumpft und eher übersichtlich... ralli

Das eher Philisophische daran ist, das es leider immer wieder vorkommt, da Leute gute Programme auf Desktopdatenbanken (DBase, Access,...) entwickelt haben und dann diese Anwendungen auf einen Server portieren. Und dann gehts am Anfang gut, bis die Datenmengen größer werden und dann herumgebastelt wird, damit das halbwegs funktioniert. Auch bei Schulabgänmgern und Proktikanten beobachtet. Keiner hat bei seinen kleinen Projekten sich je mit Datenmengen auseinandergesetzt. Und wunder sich, wenn bei einem 'Sel_ect * from table' plötzlich 200.000 Datensätze kommen und das ganze 1 Minute dauert Desktop Datenbanken sind gut und performant wenn richtig eingesetzt, aber man darf beim Design nicht wirklich aus den Augen verlieren, was kann als Datenmenge kommen und vor allen wie funktioniert die Wartung/Backup. Das Kapitel wird von den meisten gar nicht berücksichtigt. Beispiel eine BDE Erfassung bei einem Schnellläufer (Maschine mit hohen Output) kann schon mal 100.000 bis 1.000.000 Buchungen am Tag bedeuten. Die täglich verdichtet werden. Da wird ein bereinigen der obsoleten Datensätze, ein Kompress im laufen, Auswertungen etc. zur Herausforderung und sogar 'poor Man' Server können da schon schnell in die Knie gehen, von Desktopdatenbanken ganz zu schweigen. Das Problem ist, es macht sich keiner die Mühe, in seine Datenbank soviele Datensätze einzufüllen, das er in die Nähe der Projektierten Grenze kommt. Und wenn es 1000 Datensätz bei einer einfachen Adressverwaltung sind. Da kann es dann ganz schöne 'AHA' Erlebnisse geben. Gar nicht zu reden wenn es auf mehreren Arbeitsplätzen zugleich laufen soll. Deshalb meine Meinung, man sollte das Design entsprechend auslegen, dort auch die Entwicklung hineinlegen (auch bei kleinen Projekten) denn dann ist die halbe Arbeit getan und der Rest ist Tippsen und Optik
Zum vollen Editor wechseln

@af0815, da stimme ich Dir voll und ganz zu, die zu erwartende Datenmenge plus Puffer sind ein sehr wichtiges Entscheidungskriterium, vielleicht das WICHTIGSTE. Obwohl bei einem Freiberufler ja eher nicht solche Datenmengen anfallen.

Also zum Test habe ich in (fast allen Datenbankformaten) kleinere Datenbestände mehrerer Städte mit Telefonbucheinträgen bis zu der Stadt Hamburg, die ca 700000 Datensätze umfasst. Es ist erstaunlich, das ich auch bei meinem dbmaker mit der tdbf Komponente bei einer normalen Abfrage zu einer erträglichen Antwortzeit kommt.

ralli

[af0815]

Das heißt:

*) Man muß sich Gedanken darüber machen, wie groß die Datenbank nach 1 bis 10 Jahre sein könnte.

*) Wie erzeuge ich dann für Versuche die Testdaten in erforderlicher Qualität und Quantität.

*) Einzelplatz oder Mehrplatzsystem. Sprich habe ich mit geänderten Daten während einer bearbeitung zu rechnen oder nicht.

*) Big Server oder Big Client design ?

[knight]

*) Man muß sich Gedanken darüber machen, wie groß die Datenbank nach 1 bis 10 Jahre sein könnte.

Wobei sich auch die Frage stellt, ob es die bevorzugte Datenbank in 10 Jahren überhaupt noch gibt bzw. ob sie weiterentwickelt wird. In unserer schnelllebigen Zeit kann man da nie sicher sein.

knight

[ralli]

Und die Sicherheit spielt ja auch keine untergeordnete Rolle. Bei der Desktop Datenbank oder bei der Verwendung von TMemDataset wird es schon kritisch, ersten ist wird die Dateigrösse schon duch den Arbeitsspeicher begrenzt, und zweitens wird der gesamte Datenbestand immer im RAM gehalten, was ich für ein erhebliches Sicherheitsrisko halte.

10 Jahre halte ich zwar für nicht mehr überschaubar, aber vielleicht 3 bis 5 Jahre und wie schnell ein Untenehmen wächst, ist ja auch nicht einfach einzuschätzen. Verantwortungsbewusst handelt jedoch derjenige, welcher entsprechend Puffer mit berücksichtig.

Und bei Testläufen besteht die Qualitätssicherung ja auch darin, auch die richtigen und komplexen Abfragen auszuführen. Auch dafür muss Du das genaue Anforderungsprofil der zu erwartenden Antworten oder Auswertungen kennen. Das kennen die Benutzer auch nicht immer von Anfang an, die Anforderungen wachsen und die Ansprüche auch mit der Zeit erheblich. Vorgesetzte können bei Statistiken ganz schön erfinderisch sein ..

Da wir es ja heute mit einer vernetzten Infrastruktur zu tun haben, wird dann der Schwerpunkt sicherlich auch auf dem Mehrbenutzerbetrieb liegen.

ralli

[pluto]

ein Interessantes Thema was ihr da angefangen habt.
Ich habe mir schon oft die gleiche Frage(n) gestellt.

Bis her hatte ich wenig mit Daten Banken zu tuen, erst vor kurzem habe ich damit angefangen.

Ich habe ein kleines Test Projekt mit Hilfe der VST Komponenten geschrieben.
das Problem: ich nutze im Moment die Speicher und Lade Funktionen von der VST. Beim Laden wird leider alles sofort geladen und nicht Stückenweise. das gleiche beim Speicher.

z.z. Spiele ich mit SQLite herum. und der VST.
ich habe es beispielweise schon Geschaft ein Baum in einer DB unterzubringen und ihn nach und nach zu laden.

Die Eigentliche Frage ist ja: welche DB wird es noch nach 10 Jahren überhaupt geben ? SQL ? MYSql ? oder oder ?

Würde sich der Aufwand lohnen einen eigene Konzept dafür zu entwickeln ?
Dann währe man doch auf der sicheren seite. oder nicht ?

Das Problem ist immer wider beim schreiben von Daten. Das lesen ist ja sehr einfach..... In eine DB sollten ja nur die geänderten Daten rein. und die Datei sollte nicht jedesmal Komplet neu erstellt werden.

Wie wird das eigentlich bei den "richtigen" DB'S gemacht ?

[af0815]

Wie wird das eigentlich bei den "richtigen" DB'S gemacht ?

Lies mal bei SQL-Befehlen nach. Hinweis: Google mit 'SQL Befehle' hilft.

Wenn Du dann verstanden hast, was man mit SEL_ECT, INS_ERT, UPD_ATE, DEL_ETE macht, dann weißt Du wie es bei 'richtigen DBs' gemacht wird. Denn viel mehr Befehle brauchst Du ja nicht können. Die vier Befehle reichen normalerweise aus. Ein paar Sachen für die Verwaltung gibts noch (CRE_ATE, AL_TER,..), die sind aber nach dem Begreifen des Selectbefehles auch kein Problem.

Übrigends dient der Unterstrich im Wort nur dazu, das ich es überhaupt posten kann.

[theo]

Übrigends dient der Unterstrich im Wort nur dazu, das ich es überhaupt posten kann.

Das ginge alles, siehe hier:
http://www.lazarusforum.de/viewtopic.php?p=10638#10638" onclick="window.open(this.href);return false;

Nur SEL_ECT * FROM geht nicht auf einer Zeile

@Pluto und Knight: MySQL wird es ganz sicher in 10 Jahren noch geben.
Bei der Verbreitung ist es kaum denkbar, dass das in diesem Zeitraum verschwindet.

[pluto]

@af0815
ich weiß wohl was die befehle machen aber die frage ist ja: wie wird geschrieben ? wird die Datei einfach neu erstellt ?

[af0815]

@af0815
ich weiß wohl was die befehle machen aber die frage ist ja: wie wird geschrieben ? wird die Datei einfach neu erstellt ?

Es geht hier um Datenbankmanagmentsysteme und Datenbanken. Was interessiert mich - wie und was die Datenbank am physikalischen Layer macht. Dazu ist das System ja da, das ich mir darum nicht unbedingt große Gedanken machen muß, ausser den Rechten und den Platz.

[knight]

MySQL wird es ganz sicher in 10 Jahren noch geben.

Wärst du bereit, Geld darauf zu verwetten - ich nicht. Wer hätte sich z.B. vor einigen Jahren vorstellen können, daß Lotus 1-2-3 nicht die führende Tabellenkalkulation bleibt. Heute kennen nur noch diejenigen das Programm, die früher mal damit gearbeitet haben.

knight

[theo]

MySQL wird es ganz sicher in 10 Jahren noch geben.

Wärst du bereit, Geld darauf zu verwetten
knight

Ja, das wäre ich.
Erstens ist es Opensource und geht dadurch schon mal nicht aus finanziellen Gründen hops, und zweitens ist es gerade im Web-Bereich so weit verbreitet, dass es einfach unvernünftig wäre sein Verschwinden in absehbarer Zeit anzunhemen.
Ausserdem sind 10 Jahre auch nicht eine so lange Zeit. Es ist ja bereits mehr als zehn Jahre alt.
Ich sehe jetzt auch nicht, dass etwas revolutionär besseres im Anmarsch wäre.

Ich fahr auch immer noch mein olles Win2k (10 Jahre seit Beta1) und ich finde es macht sich prächtig auf neuen bzw. virtuellen Maschinen.
Fühlt sich an wie ein "leichtgewicht OS".

[af0815]

Nomenklatura innerhalb der Datenbank:

Wenn man ein großes Projekt angeht (oder auch ein kleines) solte man sich auch eine Art Struktur überlegen, wie man mit Tabellennamen, Spaltennamen, Indizes umgeht. Dabei kommt ins Spiel das es verschiedene Arten von Datentabellen in einer Datenbank gibt. Einmal Stammdaten, das sind Daten die normalerweise zwar gepflegt werden müssen, sich aber im normalen Geschäftsleben kaum ändern und Bewegungsdaten, das sind die Daten die laufend geändert werden. Ein kleines Beispiel wäre ein Bankkonto - die Daten der Personen werden sich nicht so häufig ändern, die Kontobewegungen sind dann die Bewegungsdaten.

Ich unterscheide bei meinen Projekten eigentlich vier verschiedene Klassen:Stammdaten, Referenzen, MN-Regerenzen und Buchungsdaten. Ensprechend dessen verwende ich einen Tabellenpräfix dafür (ST_, R_, MN_ und B_). Dann bekommt die Tabelle einen kurzen, einprägsamen Namen. Somit heisst die Personendatentabelle bei mir ST_PersData.

Damit ergibt sich für mich auch automatisch der Name für den Primary Key: STPersData. DIeser Name wird Überall verwendet, somit weis ich immer ob es der Primary Key ist (Tabellenname = Spaltenname) oder ein Foreign Key (Tabellename Spaltenname). Ausserdem weis ich sofort von welcher Tabelle es der Foreign Key ist.

Ob man jetzt auch Präfix für die Spalten nimmt, die besagen von welchen Typ der Inhalt ist, so ist das Geschmackssache. Ich mache es zumindest nicht.

Somit kann man eine einfache Tabelle für Personen ganz schön kompliziert machen

Ich verwende mal das übliche:

Vorname, Nachname, Adresse, Telefonnummer,....

doch moment, wenn man das ganze jetzt sich mal ansieht, so kann man folgende Überlegungen machen:

-> Umlaute/Sonderzeichen im Namen (ä, ß, â, ....) ?
-> Wie gehe ich mit Standesänderung um ? Mädchenname Hehe - ich habe auch einen LOL
-> Was ist mit verschiedenen Wohnorten ? Umzug ?
-> Telefonnummer: Welche Privat, Handyprivat, Firma, Firmenhandy, 2.tes Handy ?

Na ja, schon mal Sachen, die man VORHER bewerten sollte.

Zumindest der erst Punkt schaut ja nicht schlecht aus. Kann aber auf einem DBMS zu Problemen führen. Denn eine 'Passschraube' ist nicht gleich einer 'Paszschraube' bzw. einer 'Paßschraube'. Besonders beim Suchen kann es da später zu 'AHA'-Effekten kommen.

Der zwite Punkt hat damit zu tun, das Informationen zum Namen verloren gehen, wenn wir ganz einfach nur den Name ausbessern. Was ist, wenn dann etwas Auftaucht, das auf den alten Namen gelautet hat. Beispiel eine Reklamation, das ist dann plötzlich eine andere Person.

Drittens haben schon genügend Leute mehr als einen Wohnsitz (und wenns der Knast ist SCNR). Da ist oft auch die Information nötig, ob es einen gibt, bzw. wo der ist (Inland/Ausland).

Der vierten Punkt ist selbsterklärend

Jetzt die Frage an den, der es beim Lesen bis hierher geschafft hat - Was einfaches kann doch ganz schön kompliziert werden.

Ich beschäftige mich übrigend auch ein wenig mit der Erstellung von Lasten/Pflichtenheften für Maschinen und Software

@ralli
Schon mal was mit Mandantenfähigkeit gemacht ? Wenn ja, wie ist dort der Ansatz ?

[ralli]

Die Namensgebung der verwendeten Tabellen, Indizes, Variablen und Konstanten sind ein wichtiges Kriterium. Bei der Programmierung sowieso. Und beim Datenbankdesign ebenfalls. Sie erst erzeugt die nötige Transparenz, um auch ein Programm nach einiger Zeit noch selbst lesen und verstehen zu können, ohne sich tagelang erneut einzuarbeiten. Und eine solide Infrastuktur, ohne das nichts vernünftig läuft.

Aber Kinners, ich bin kein Experte, habe kein Hochschulstudium absolviert, sondern nur den Hauptschulabschluss. Dafür, so wird von Anderen behauptet, ein begnadeter Autodidakt, was zum Teil auch stimmt.

Wenn ich Beispielcode von Berufsprogrammierern sichte und durcharbeite, erfasst mich oft das Grauen. Wie oft habe ich das komplett neu gemacht, um es überhaupt verstehen zu können. Diese sogenannten "Experten" machen alles kompliziert. Und nicht wenige benutzen eine eher kryptische Namensgebung, was meineserachten im IT Bereich eine Todsünde ist.

Es reicht eben nicht nur das Fachwissen aus, auch eine Portion gesunder Menschenverstand mit dem Gespür für das Richtige ist durchaus hilfreich.

Ganz früher habe ich PAP gemacht.

Unter Mandantenfähigkeit fällt mir spontan ein Steuerberater ein, der ja mandantenfähige Software einsetzen muss, um seine Kunden damit zentral zu verwalten. Mandantenfähige Software spart ja auch Lizenzkosten. Ein weiterer Vorteil sind die zentrale Installation und die geringen Wartungskosten. Eine echte mandantenfähige Software bietet jedem Mandanten die Möglichkeit, natürlich unabhängig und isoliert von anderen Mandanten, Datenhaltung, Präsentation und Konfiguration selbst zu gestalten und darauf Einfluss zu nehmen. Damit ist der Mandant datentechnisch die oberste Ordnungsinstanz und bewegt sich in einer organisatorisch abgeschlossenen Einheit des Systems. Also um mandantenfähige Software zu erstellen, erfordert das sicherlich jahrelange Erfahrung und gebündeltest Know How.

Lasten und Pflichtenhefte sind bei grösseren Aufträgen unumgänglich. Wer das unterlässt, handelt nicht nur nachlässig, sondern auch fahrlässig und den bestraft das Leben oder irgendwann der Auftraggeber.

ralli

[af0815]

Aber Kinners, ich bin kein Experte, habe kein Hochschulstudium absolviert, sondern nur den Hauptschulabschluss. Dafür, so wird von Anderen behauptet, ein begnadeter Autodidakt, was zum Teil auch stimmt.

Wenn ich Beispielcode von Berufsprogrammierern sichte und durcharbeite, erfasst mich oft das Grauen. Wie oft habe ich das komplett neu gemacht, um es überhaupt verstehen zu können. Diese sogenannten "Experten" machen alles kompliziert. Und nicht wenige benutzen eine eher kryptische Namensgebung, was meineserachten im IT Bereich eine Todsünde ist.

Meiner Erfahrung nach, gibt es 3 Ansätze. Der erste ist , der, das von einem Designer eine Struktur ezeugt wird und die Namensgebung in der DB ist darauf abgestimmt. Das kann soweit gehen, das man echt mit Übersetzungslisten Arbeiten muß. Denn man kann auch Tabellen und Spalten einfach durchnummerieren. Der zweite ist ein ANsatz ähnlich dem vorgestellten, also mit Struktur. Und der dritte kommt oft von Personen die der Chaostheorie verhaftet sind.
Warum ist auch klar, bei kleinen 'One Man' Projekten kommt man ohne Struktur am Anfang meistens aus. Das Ändert sich erst wenn das Projekt erwachsen wird. Man glaubt sich am Anfang aber Arbeit zu ersparen, das ist meistens ein gewaltiger Irrtum. Ich würde aus Erfahrung das Verhältnis 10:1 bis 100:1 schätzen, was man später verliert.


Auch ich bin Autodidakt, habe aber mittlerweile meinen Meister in IT+Kommunikationtechnik in A gemacht & Unternehmerprüfung zusätzlich. Ausserdem beschäftige ich mich seit Jahren Hobbymäßig mit Programmierung (Seit CP/M Zeiten) zusätzlich beruflich mit SPS Programmierung und BDE Programmierung (Applikation & Datenbanken).

Andi

[ralli]

Ja, ja, Andi, das gute alte CP/M. Stell Dir mal vor, unter einem Schneider cpc 6128 hatte ich noch dbase II unter CP/M laufen.

ralli