AGB  ·  Impressum  







Anmelden
Nützliche Links
Registrieren

Datenbankmodellierung

Ein Thema von Asura · begonnen am 12. Apr 2018 · letzter Beitrag vom 16. Apr 2018
Antwort Antwort
Seite 6 von 6   « Erste     456
Asura

Registriert seit: 10. Jun 2013
83 Beiträge
 
#51

AW: Datenbankmodellierung

  Alt 15. Apr 2018, 18:31
Eine Kategorisierung und eine Bewertung wären durch einen separaten Prozess und Datenspeicher zu bewerkstelligen.
Ist das Problem klar, kann man natürlich hergehen und beides parallel Speichern, Fakten und (subjektive Kategorie. So läuft man jedenfalls nicht Gefahr, eine sagen wir verkürzte Interpretation von Fakten zu speichern, deren Ursprung einem irgendwann (z.B. bei der Neukategorisierung) fehlt. Fakten sind im übrigen viel leichter einzutragen. Nicht im Sinne von Verfügbarkeit (auf der Lastschrift vom Supermarkt findet man natürlich nicht alle Artikel, die man gekauft hat), aber Sinne der Abwägung (Grundbedarf oder Luxus). Das ist sehr subjektiv, schwankt wahrscheinlich mit der Zeit und führt zu einer eher mäßigen Kategorisierungsqualität.
Ich hoffe ich habe das richtig verstanden:

Man stellt also die Kategorien raus und weißt diese nur der Buchung zu.
Also kann eine Buchung mehrere Kategorien besitzen, die im gleichen Level (Hauptkategorie vs. Nebenkategorie) sich befindet. Damit aber später das Programm nach einer Neukategorisierung weiß, welchen Zuweisung nun wirklich die neue ist, nimmt er praktisch den neuesten Eintrag (Also anhand der Eintragungszeit) der Kategorisierung einer Buchung.
So bin ich flexibel, was die Kategoriezuweisung angeht.
  Mit Zitat antworten Zitat
Benutzerbild von p80286
p80286

Registriert seit: 28. Apr 2008
Ort: Stolberg (Rhl)
5.849 Beiträge
 
Delphi 7 Personal
 
#52

AW: Datenbankmodellierung

  Alt 15. Apr 2018, 20:39
Fakt ist aber, das Joins eine DB (bzw. den Server) stark belassten (hinsichtlich Performance und Systemresource). Mit steigernder Nutzerzahl wird das sicher relevant.
Das ist mir etwas zu pauschal (z.B. steigende Nutzerzahl ist per se eine höhere Belastung für jedes Sytem). Für mich gehören JOINS einfach dazu. Aber man muss auch nicht alles zerreden.
Eine Datenbank ist dafür gemacht, mit Joins umzugehen. Wenn sie die Aufgabe für die sie gemacht ist, nicht bewältigen kann, ist sie schlicht untauglich.

Gruß
K-H
Programme gehorchen nicht Deinen Absichten sondern Deinen Anweisungen
R.E.D retired error detector
  Mit Zitat antworten Zitat
Delphi.Narium

Registriert seit: 27. Nov 2017
328 Beiträge
 
Delphi 7 Professional
 
#53

AW: Datenbankmodellierung

  Alt 15. Apr 2018, 21:19
Darf ich das mal etwas "dreister" formulieren:

Wenn eine Datenbank mit Joins nicht zurecht kommt, hat der Entwickler was falsch gemacht.

Ein normalisiertes Datenmodell ohne Joins ist (meiner Meinung nach) nicht sinnvoll einsetzbar.

Ok, habe auch schon Systeme gesehen, bei denen gezielt denormalisiert wurde, weil es mit den Joins ... nicht mehr so recht funktionierte und mehrere CPUs und etliche GB Speicher auch nicht ausreichten. Aber das waren Systeme mit mehreren 100 Mio. Datensätzen in dutzenden Tabellen. (Also "geringfügig" komplexer, als das hier besprochene System.)
  Mit Zitat antworten Zitat
jobo

Registriert seit: 29. Nov 2010
2.125 Beiträge
 
Delphi 2010 Enterprise
 
#54

AW: Datenbankmodellierung

  Alt 15. Apr 2018, 21:34
"..Man stellt also die Kategorien raus.."
Da weiß ich jetzt nicht, was Du damit meinst.
Ich habe da eigentlich nicht von einem konkreten Datenmodell gesprochen, sondern von Vor- und Nachteilen eines Kategorisierungsverfahrens. Damit habe ich mich auf Deine Pläne zur Analyse bezogen.

Mein Gedanke war eigentlich nur folgender:
Statt (evtl. fragwürdige) Kategorisierungen eines Datensatz zu erdenken und zu speichern, einfach nur Fakten abzuspeichern.
Du kaufst Dir ein Auto, ein MB S Klasse Coupé. Wie kategorisierst Du das?
Auto>Coupe (Luxus)?
Wie würde eine Änderung der Kategorisierung irgendwann ausfallen?
Bei diesem Beispiel wirst Du sicher auch nach vielen Jahren noch wissen, was Du tatsächlich gekauft hast und sei die Kategorie, unter der Du das gespeichert hast, noch so schräg.

Also nicht Kategorie Auto, Coupé speichern sondern MB S Klasse Coupé.

Das kannst Du wann und wie auch immer analysieren und kategorisieren.
Wenn es gefällt, kannst Du das auch parallel machen (konkreten Artikel und eine akute Kategorisierung speichern) und später neue und alte (originale) vergleichen.

Und was das Modell angeht, vielleicht macht man das dann in einer separaten Tabelle.
Gruß, Jo
  Mit Zitat antworten Zitat
TigerLilly

Registriert seit: 24. Mai 2017
Ort: Wien, Österreich
256 Beiträge
 
Delphi 10.2 Tokyo Enterprise
 
#55

AW: Datenbankmodellierung

  Alt 16. Apr 2018, 08:01
1. Die Normalform ist zwar schön und gut, und sollte durchaus auch angestrebt werden. Aber in der Praxis gibts
Situationen und Anforderungen, die Redundazen nicht nur angenehm sonder sogar notwendig machen.
Redundanzen sind nie "angenehm". Der Rest stimmt nur, wenn man mit dBase oder Paradox arbeitet. Für moderne DB-Systeme gilt das zu 99,999% nicht. Redundanzen mögen beim lesenden Zugriff hilfreich sein, dafür hat man beim Schreiben höheren Aufwand. Die Diskussion über die Normalformen ist wie die um Patterns: Sinnvoll. Berücksichtigen. Immer. Muss man abweichen, hat man was nicht verstanden.

2. Joins...sie sind angenehm für den Programmierer. Aber sie erzeugen auch u.U. sehr hohe Lasten auf der DB (und ggf. auf dem Rechner für die DB). Deshalb versuch ich sie grundsäzlich zu vermeiden.
Siehe oben - gilt für mySql, MSSQL, Oracle, FireBird, etc nicht. Ein Join über mehrere Tabellen mit brauchbaren Indices belastet den Rechner für die DB gar nicht. Siehe immer auch Execution Plan.

3. Die Strukturen immer so einfach wie möglich halten. Je einfacher das Datenmodell desto leichter ist es,
sie in einem Programm zu handhaben (xtCommerce ist da nicht gerade Vorreiter).
Naja, aber was heißt schon "einfach"? Es gibt effiziente und elegante Lösungen, die weniger "einfach" sind und scheinbar einfache Lösungen, die rasch sehr ineffizient werden. Aber wenn man sich an die drei Normalformen hält, ist man eh schon sehr gut bedient.
  Mit Zitat antworten Zitat
rokli

Registriert seit: 21. Mär 2009
Ort: Rödinghausen
145 Beiträge
 
Delphi 10 Seattle Professional
 
#56

AW: Datenbankmodellierung

  Alt 16. Apr 2018, 10:28

Siehe oben - gilt für mySql, MSSQL, Oracle, FireBird, etc nicht. Ein Join über mehrere Tabellen mit brauchbaren Indices belastet den Rechner für die DB gar nicht. Siehe immer auch Execution Plan.
Das ist, denke ich der wesentliche Punkt: "Ein Join über mehrere Tabellen mit brauchbaren Indices belastet den Rechner für die DB gar nicht."

Sonst würde so manche Software gar nicht arbeiten können.
Rolf
wenn nicht anders angegeben, schreibe ich zu D7, XE2 und MS SQL - ansonsten fragen Sie ihren Administrator oder einen Operator. Und seid heute auch Delphi 10 Seattle
  Mit Zitat antworten Zitat
Themen-Optionen Thema durchsuchen
Thema durchsuchen:

Erweiterte Suche
Ansicht

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 · Nach oben
Alle Zeitangaben in WEZ +1. Es ist jetzt 19:17 Uhr.
Powered by vBulletin® Copyright ©2000 - 2018, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2018 by Daniel R. Wolf