AGB  ·  Datenschutz  ·  Impressum  







Anmelden
Nützliche Links
Registrieren
Zurück Delphi-PRAXiS Programmierung allgemein Datenbanken Delphi Einfaches Datenbankmodell
Thema durchsuchen
Ansicht
Themen-Optionen

Einfaches Datenbankmodell

Ein Thema von Delbor · begonnen am 25. Jun 2018 · letzter Beitrag vom 28. Jun 2018
Antwort Antwort
Seite 1 von 2  1 2      
Benutzerbild von p80286
p80286

Registriert seit: 28. Apr 2008
Ort: Stolberg (Rhl)
6.659 Beiträge
 
FreePascal / Lazarus
 
#1

AW: Einfaches Datenbankmodell

  Alt 25. Jun 2018, 22:33
Zunächst, es werden wohl nicht Millionen von Datensätzen werden, daher sind Peformanceüberlegungen eher nebensächlich. Trotzdem spricht nichts gegen ein Datenmodell, das alle Möglichkeiten (oder doch nur 95%,98%..) abdeckt.
@Schokohase
Eine Datenbankanwendung ist die Schnittstelle zwischen Benutzer und den Daten. Nicht mehr und nicht weniger. In dieser Schnittstelle kann man z.B. über Prüfungen sicherstellen, daß nur korrekte Daten in der Datenbank landen. Aber der erste Schritt zu einer solchen Anwendung, ist die Definition der Daten und der Datenhaltung, unabhängig vom später eingesetzten DB-System. Wer hierbei Hausnummern, Postcodes oder Telefonnummern als Zahlen ablegt, legt schon eine fehlerhafte Basis für die spätere Schnittstelle.
Wohin gehört z.B. die Telefonnummer 49211789 ? Ist es 0049211789 oder 049211789 oder doch 49211789 ?
Eine Datenbank ist kein Übel, sondern Mittel zum Zweck und manchmal auch völlig überflüssig und ein paar schlichte Dateien hätten es auch getan.

Natürlich macht man sich Gedanken was für Datenstrukturen die Anwendung benötigt um ihre Aufgabe zu erledigen, aber eben völlig losgelöst von dem eventuell zu verwendenden Datenbank-System.

Hat man diese Strukturen und die Anwendung, dann ist die Datenbank-Anbindung nur noch ein Spaziergang und das Datenbank-System wird austauschbar.
Ich denke da sind wir jetzt einer Meinung

Gruß
K-H
Programme gehorchen nicht Deinen Absichten sondern Deinen Anweisungen
R.E.D retired error detector
  Mit Zitat antworten Zitat
Schokohase
(Gast)

n/a Beiträge
 
#2

AW: Einfaches Datenbankmodell

  Alt 25. Jun 2018, 22:54
Eine Datenbankanwendung ist die Schnittstelle zwischen Benutzer und den Daten.
Also hat eine Anwendung keine Daten?

Und wenn sie doch Daten hat, aber keine Datenbank, ist es dann eine Datenanwendung oder eher eine DatenOhneBankanwendung?

Bei mir ist jede Anwendung eine Schnittstelle zwischen Benutzer und Daten. Und die Daten liegen irgendwo, der Anwendung grundsätzlich egal, denn die bekommt den Zugriff auf die Daten über eine Abstraktion zugeteilt.

Ist es dann eine IrgendwoDatenanwendung?
  Mit Zitat antworten Zitat
Benutzerbild von TigerLilly
TigerLilly

Registriert seit: 24. Mai 2017
Ort: Wien, Österreich
1.251 Beiträge
 
Delphi 12 Athens
 
#3

AW: Einfaches Datenbankmodell

  Alt 26. Jun 2018, 07:31
Vielleicht zurück zum Anliegen des TE. Ergänzend zu noch nicht Gesagtem:

Allgemein:
* Die Tabellen alle mit TBL_ beginnen zu lassen ist überflüssig.
* Ich bevorzuge es, die IDs (=PKs) mit dem Tabellennamen zu benennen. So wie du es bei Tbl_User gemacht hast (Tbl_USer -> UserID), aber bei den anderen nicht (Tbl_Konto -> ID)
* Die IDs einmal mit und einmal ohne _ zu bennen ist nicht gut. Adress_ID und UserID ist eine ziemliche Fehlerquelle.
* Ich würde nicht mit den Standarddatentypen arbeiten, sondern UDDT, also selbst definierte Typen, verwenden + allen Feldern, die gleichen Typ haben, diesen zuordnen. Also statt FLOAT bei Beträgen würde ich einen UDDT "Betrag" vom Typ Float zwischenschalten. Diesen ev. mit Default oder not null etc aufpeppen. Das macht es dann zB leichter alle Telefonnummern zu verlängern, weil du nur einmal den UDDT ändern musst.
* Mach dich über den Unterschied zwischen VARCHAR und NVARCHAR schlau.
* INT INTEGER DEC FLOAT ist ein ziemliches Typgemisch - siehe vorher UDDT.
* "Text" als Feldname ist unglücklich, da a) nichtssagend + b) oft ein reserviertes Wort.
* Tabellennamen sollten einheitlich entweder alle Einzahl oder alle Mehrzahl sein. Jetzt gibt es die Tbl_Firma, aber auch die Tbl_Adressen.


Tbl_Konto
* Wenn Saldo die Differenz/Summe aus Gutschrift und Belastung ist, lass es. Das kannst du als Abfrage ausrechnen. Außer du musst Rundungseffekte berücksichtigen, dann kann das sinnvoll sein.
* Vertrag_ID verweist wohin? Ist das nicht redundant, denn über die Rechnung kommst du ja auch zum Vertrag?

Tbl_Adressen
* Mir fehlt da Land+PLZ+eine zweite Adresszeile
* 45 zeichen für die Straße können knapp werden
* Das Design ist da etwas komisch - es gibt Adressen + User+Firmen bekommen welche zugeordnet?

Tbl_User
* da gibt es drei Verweise in die Tbl_Adressen. Warum?

Ich lass es mal gut sein - da gibt es schon Dinge zum Bessermachen
  Mit Zitat antworten Zitat
Delbor

Registriert seit: 8. Okt 2006
Ort: St.Gallen/Schweiz
1.196 Beiträge
 
Delphi 11 Alexandria
 
#4

AW: Einfaches Datenbankmodell

  Alt 26. Jun 2018, 13:02
Hi TigerLilly
Danke für deine Antwort! Sehr umfassend!
Vielleicht zurück zum Anliegen des TE. Ergänzend zu noch nicht Gesagtem:

Allgemein:
* Die Tabellen alle mit TBL_ beginnen zu lassen ist überflüssig.
* Ich bevorzuge es, die IDs (=PKs) mit dem Tabellennamen zu benennen. So wie du es bei Tbl_User gemacht hast (Tbl_USer -> UserID), aber bei den anderen nicht (Tbl_Konto -> ID)
* Die IDs einmal mit und einmal ohne _ zu bennen ist nicht gut. Adress_ID und UserID ist eine ziemliche Fehlerquelle.
* Ich würde nicht mit den Standarddatentypen arbeiten, sondern UDDT, also selbst definierte Typen, verwenden + allen Feldern, die gleichen Typ haben, diesen zuordnen. Also statt FLOAT bei Beträgen würde ich einen UDDT "Betrag" vom Typ Float zwischenschalten. Diesen ev. mit Default oder not null etc aufpeppen. Das macht es dann zB leichter alle Telefonnummern zu verlängern, weil du nur einmal den UDDT ändern musst.
* Mach dich über den Unterschied zwischen VARCHAR und NVARCHAR schlau.
* INT INTEGER DEC FLOAT ist ein ziemliches Typgemisch - siehe vorher UDDT.
* "Text" als Feldname ist unglücklich, da a) nichtssagend + b) oft ein reserviertes Wort.
* Tabellennamen sollten einheitlich entweder alle Einzahl oder alle Mehrzahl sein. Jetzt gibt es die Tbl_Firma, aber auch die Tbl_Adressen.


Tbl_Konto
* Wenn Saldo die Differenz/Summe aus Gutschrift und Belastung ist, lass es. Das kannst du als Abfrage ausrechnen. Außer du musst Rundungseffekte berücksichtigen, dann kann das sinnvoll sein.
* Vertrag_ID verweist wohin? Ist das nicht redundant, denn über die Rechnung kommst du ja auch zum Vertrag?

Tbl_Adressen
* Mir fehlt da Land+PLZ+eine zweite Adresszeile
* 45 zeichen für die Straße können knapp werden
* Das Design ist da etwas komisch - es gibt Adressen + User+Firmen bekommen welche zugeordnet?

Tbl_User
* da gibt es drei Verweise in die Tbl_Adressen. Warum?

Ich lass es mal gut sein - da gibt es schon Dinge zum Bessermachen
Zu Allgemein:
  1. In der Bilddatenbanh hatte ich ursprüngich Namen wie 'Bildtabelle' oder 'KategorienTabelle verwendert. Workbench generierte daraus im Falle von Interselektionstabellen Feldname wie 'Bildtabelle_to_KategorienTabelle' oder 'BildtabelleFeldname_to_KategorienTabelleFeldname' . Irgendwann hab ich das dann geändert und möglichst kurze Namen verwendet, wobei ich das'Tbl_' einführte - das soll mir vor allem im Code klar aufzeigen, dass ich mit einer Tabelle arbeite.
  2. Das ist sicher übersichtlicher
  3. Werd ich korrigieren
  4. ??
  5. Werd ich korrigieren. Wenn ich das richtig verstehe (was ich im Moment eher bezweifle), ergibt das einen Datentyp, der aus mehren Feldern besteht - wobei: Nur einmal den UDDT ändern zu müssen, klingt schomal gut.. Zu UDDT hab ich bisher dies und das gefunden. Noch nicht viel, wie ich finde.

Das überarbeitete Modell steht soweit, ich muss es allerdings nochmal durchsehen.

Gruss
Delbor
Roger
Man muss und kann nicht alles wissen - man muss nur wissen, wo es steht.
Frei nach Albert Einstein
http://roase.ch
  Mit Zitat antworten Zitat
Benutzerbild von TigerLilly
TigerLilly

Registriert seit: 24. Mai 2017
Ort: Wien, Österreich
1.251 Beiträge
 
Delphi 12 Athens
 
#5

AW: Einfaches Datenbankmodell

  Alt 26. Jun 2018, 15:00
Sorry, ich hab nicht gesehen, dass SQLite dein target ist. UDDTs gehen da gar nicht + VARCHAR/NVARCHAR auch nicht.
  Mit Zitat antworten Zitat
Delbor

Registriert seit: 8. Okt 2006
Ort: St.Gallen/Schweiz
1.196 Beiträge
 
Delphi 11 Alexandria
 
#6

AW: Einfaches Datenbankmodell

  Alt 26. Jun 2018, 16:39
Hi zusammen

@ TigerLilly:
Ich werde wohl noch andere Datentypen von Hand anppassen müssen, wenn es mir nicht gelingt, das Workbench-Plugin für SQLite-Export neu zu installieren. Wobei das wohl alles nuur halb so wild ist, wie es sich anhört: ich habe auch noch das Tool SQLIte Expert auf der Platte - leider nur in der Personal-Edition. Die Professional hätte einen grafischen Designer ála Workbench mit an Board. Leider sehe ich keine Möglichkeit, das Ding Online zu kaufen - preislich würde es sich durchaus in einem vertretbaren Rahmen halten.
Anrerseits liessen sich die Tabellen auch mit der Personal aufgrund des Workbench-Modells erstellen - zwar mehr oder weniger 'von Hand. Egal, irgendwie krieg ich das schon hin.

Inzwischen habe ich das Modell überarbeitet:
17_18_18-PDFOfficerData.jpg

Ich hab auch eine Kontobeschreibungs-Tabelle eingebaut, analog zur Empfehlung von hstreicher, eine Kontokopf-Tabelle einzuführen - ich seh mich schon, wie ich mir an den Kopf greife angesichts einer Bildschirmseite voller gleichlautender Kontonamen...
Beim ersten Entwurf der Tabellen hatte ich die erfordrlichen Fremdschlüssel-Felder mit eingefügt, und als ich die Beziehungen einzeichnete, tat Workbench nochmals dasselbe - ich hoffe nur, ich hab jetzt alle "Bösewichte" erwischt.

Gruss
Delbor
Roger
Man muss und kann nicht alles wissen - man muss nur wissen, wo es steht.
Frei nach Albert Einstein
http://roase.ch
  Mit Zitat antworten Zitat
mkinzler
(Moderator)

Registriert seit: 9. Dez 2005
Ort: Heilbronn
39.880 Beiträge
 
Delphi 11 Alexandria
 
#7

AW: Einfaches Datenbankmodell

  Alt 26. Jun 2018, 17:13
Alternativ die Community Edition von DBeaver

https://dbeaver.io/
Angehängte Grafiken
Dateityp: jpg DBeaver SQlite.jpg (123,8 KB, 20x aufgerufen)
Markus Kinzler
  Mit Zitat antworten Zitat
Delphi.Narium

Registriert seit: 27. Nov 2017
2.598 Beiträge
 
Delphi 7 Professional
 
#8

AW: Einfaches Datenbankmodell

  Alt 26. Jun 2018, 17:15
Schau Dir bitte nochmal die ganzen Fremdschlüssel an, da scheint einiges mehrfach zu sein.

Warum hat TblAdressen einen Fremdschlüssel auf Tbl_User_UserID? Müsste das nicht umgekehrt sein? Ein User verweist auf eine der Adressen und nicht eine Adresse verweist auf einen User?
Was ist denn, wenn zwei User die gleiche Adresse haben? Wird die Adresse dann doppelt abgelegt, weil sie nur auf einen User verweisen kann?
Oder müssten nicht die beiden User auf die gleiche Adresse verweisen, um eine doppelte Speicherung einer Adresse zu vermeiden?

Warum ist die Kontonr vom Typ Int? Gibt es keine Kontonummern mit führenden Nullen?
Warum ist die KontoNr auch als Konto-Nr in der Tbl_Kontobeschreibung enthalten? Sind damit unterschiedliche Kontonummern gemeint?

Warum heißt die Tabelle TblUser TblUser, aber die Fremdschlüssel, die auf sie verweisen, Tbl_User_UserID.

Warum gibt es in der Tabelle TblRechnungen einen Fremdschlüssel Tbl_Vertrag_Tbl_Firma_ID.
'ne Rechnung gehört zu einem Vertrag, ein Vertrag zu einer Firma, aber deshalb muss die Rechnung noch lange keinen Fremdschlüssel auf den Vertrag haben. Das ist eine zusätzlich zu pflegende Redundanz (die man allenfalls bei 'ner (z. B. aus Performanzgründen erforderlichen) Denormalisierung einführen kann.

Ähnliches kommt wiederholt vor.

Geändert von Delphi.Narium (26. Jun 2018 um 17:17 Uhr) Grund: Schreibfehler
  Mit Zitat antworten Zitat
Rollo62

Registriert seit: 15. Mär 2007
4.240 Beiträge
 
Delphi 12 Athens
 
#9

AW: Einfaches Datenbankmodell

  Alt 28. Jun 2018, 07:35
Allgemein:
* Die Tabellen alle mit TBL_ beginnen zu lassen ist überflüssig.
* Ich bevorzuge es, die IDs (=PKs) mit dem Tabellennamen zu benennen. So wie du es bei Tbl_User gemacht hast (Tbl_USer -> UserID), aber bei den anderen nicht (Tbl_Konto -> ID)
* Die IDs einmal mit und einmal ohne _ zu bennen ist nicht gut. Adress_ID und UserID ist eine ziemliche Fehlerquelle.
* Ich würde nicht mit den Standarddatentypen arbeiten, sondern UDDT, also selbst definierte Typen, verwenden + allen Feldern, die gleichen Typ haben, diesen zuordnen. Also statt FLOAT bei Beträgen würde ich einen UDDT "Betrag" vom Typ Float zwischenschalten. Diesen ev. mit Default oder not null etc aufpeppen. Das macht es dann zB leichter alle Telefonnummern zu verlängern, weil du nur einmal den UDDT ändern musst.
* Mach dich über den Unterschied zwischen VARCHAR und NVARCHAR schlau.
* INT INTEGER DEC FLOAT ist ein ziemliches Typgemisch - siehe vorher UDDT.
* "Text" als Feldname ist unglücklich, da a) nichtssagend + b) oft ein reserviertes Wort.
* Tabellennamen sollten einheitlich entweder alle Einzahl oder alle Mehrzahl sein. Jetzt gibt es die Tbl_Firma, aber auch die Tbl_Adressen.
Solche Konventionen finde ich immer sehr gut, ich arbeite zwar nicht mit den komplexesten DBs aber hilfreich ist das immer.
Das kann ich Alles unterstreichen, und weiche davon nur in Sonderfällen ab (OK bei den Datentypen manchmal).

Zitat:
* Ich bevorzuge es, die IDs (=PKs) mit dem Tabellennamen zu benennen.
Ich benutze im Moment zwar möglichst konsequent ID, das sit aber eine gute Idee, werde ich mir mal ansehen.

Was ich als Konvention für mich festgestellt habe ist das bei den meisten Tabellen eine
möglichst gleiche Nomenklatur benutzen sein kann (nicht bei Allen Tabellen wohlgemerkt).
In der Art:
  • ID(_xxxx) - als PK
  • Name - Passt fasst immer, da muss ich nicht XxxxName schreiben, denn der Zusammenhang macht es klar
  • Descr - eine Beschreibung zum Eintrag kann ich auch ziemlich oft dazunehmen
  • ChgFirst - Oft ist es sinnvoll den Ersteller des Records zu protokollieren
  • ChgLast - sowie Wer hat den Record zuletzt geändert
  • ChgTime - und wann war das

Rollo
  Mit Zitat antworten Zitat
Benutzerbild von DeddyH
DeddyH

Registriert seit: 17. Sep 2006
Ort: Barchfeld
27.666 Beiträge
 
Delphi 12 Athens
 
#10

AW: Einfaches Datenbankmodell

  Alt 28. Jun 2018, 07:41
Bei mir heißt der PK immer ID, FKs sind nach dem Muster <RefTable>ID benannt, also z.B.
Code:
 CREATE TABLE Address(
  ID INTEGER NOT NULL PRIMARY KEY,
  PersonID INTEGER,
  CONSTRAINT FK_Person
  FOREIGN KEY(PersonID) REFERENCES Person(ID)
)
Letztendlich ist es aber auch wurscht, wie man das handhabt, wichtiger ist in meinen Augen, dass man das Muster erkennen kann und dieses auch konsequent eingehalten wird.
Detlef
"Ich habe Angst vor dem Tag, an dem die Technologie unsere menschlichen Interaktionen übertrumpft. Die Welt wird eine Generation von Idioten bekommen." (Albert Einstein)
Dieser Tag ist längst gekommen
  Mit Zitat antworten Zitat
Antwort Antwort
Seite 1 von 2  1 2      


Forumregeln

Es ist dir nicht erlaubt, neue Themen zu verfassen.
Es ist dir nicht erlaubt, auf Beiträge zu antworten.
Es ist dir nicht erlaubt, Anhänge hochzuladen.
Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are aus

Gehe zu:

Impressum · AGB · Datenschutz · Nach oben
Alle Zeitangaben in WEZ +1. Es ist jetzt 08:07 Uhr.
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz