AGB  ·  Datenschutz  ·  Impressum  







Anmelden
Nützliche Links
Registrieren
Zurück Delphi-PRAXiS Programmierung allgemein Programmieren allgemein Kauf- und Kontenverwaltung - Datenbank notwendig?

Kauf- und Kontenverwaltung - Datenbank notwendig?

Ein Thema von Asura · begonnen am 2. Dez 2017 · letzter Beitrag vom 14. Jan 2018
Antwort Antwort
Seite 9 von 9   « Erste     789
jobo

Registriert seit: 29. Nov 2010
3.072 Beiträge
 
Delphi 2010 Enterprise
 
#81

AW: Kauf- und Kontenverwaltung - Datenbank notwendig?

  Alt 13. Jan 2018, 18:04
Bezüglich Datenbank Allgemein:

Dann liegt das noch an einem Grundverständnis bei mir:
Ich bin bei der Variante mit Access über die Komponente ADOQuery gegangen, wenn ich nun ein anderes System nutze, wie zum Beispiel SQL Express, oder Firebird oder MySQL, dann würde sich das doch ändern? Aber dann genügt es doch nicht mehr einfach nur den "ConnectionString" bzw. die Adressierung der Datenbank zu ändern, sondern ich müsste komplett die Komponente wechseln und somit sehr viel im Programmcode ändern?
Du kannst mit ADO verschiedene Systeme ansprechen. Mit etwas "Glück" kannst Du ohne große Probleme wechseln. Access ist im SQL Bereich leider nicht so kompatibel, wie man es sich wünschen würde. Das macht sich aber erst bemerkbar, wenn Du in der Anwendung native SQL Statements absetzt. Das Thema "Logik" schrumpft ja im Falle der Client seitigen Implementierung auf Datenmodell Logik. Da bist Du ja dran. Solange Du keine Code Module auf Datenbankseite verwendest, ist ein Wechsel der Systeme nicht dramatisch (aufwendig).
Es gibt ein paar Dinge, auf die man grundsätzlich achten sollte, um weitgehende Kompatibilität zu erhalten. In Deinem Fall aber vielleicht nicht ganz so interessant, wenn Du das Programm nur als Hobby betreibst.
- die Handhabung von ID Werten bzw deren Generierung
- die Verarbeitung von BLOB Typen
- generell die Typ Besonderheiten des RDBMS (Verwendung exotische Typen bindet vielleicht ungewollt doch an ein System)
- Handhabung von Schema, User, Privilege Konzepten
- Sperrverhalten und Multiuserbetrieb (Rowlevel Locking, ... -heutzutage können es eigentlich alle nennenswerten Systeme recht filigran)

Diese spontane Liste ist vielleicht nicht vollständig, muss aber auch nichts heißen.
Gruß, Jo
  Mit Zitat antworten Zitat
jobo

Registriert seit: 29. Nov 2010
3.072 Beiträge
 
Delphi 2010 Enterprise
 
#82

AW: Kauf- und Kontenverwaltung - Datenbank notwendig?

  Alt 13. Jan 2018, 18:17
Logik in der Datenbank: Es ist egal, was für ein Client genutzt wird. Die Logik zieht immer.
Heißt aber auch: Immer die gleiche Datenbank und nicht bei einem Kunden diese und beim nächsten Kunden jene und dann könnten wir auch noch "sonne oder solche" Datenbanken nehmen ...
Übertrieben formuliert. Logik in der Datenbank: andere Datenbank -> neue Implementierung.

Die Logik liegt in der Applikation: Dann nur diese Applikation und sonst niemand.
Naja, es gibt da recht kompatible Systeme. Oracle zu Postrges geht in vielen Bereichen recht gut (bzw umgekehrt). Idealerweise berücksichtigt man das, wenn möglich/nötig. Es gibt allerdings auch hier z.B. wirkliche Brüche.
Grundvoraussetzung ist für die Implementierung natürlich ein RDBMS mit mehr als passablen Programmierfähigkeiten. Das sind nicht so viele.

Wenn man das Spielchen so weit treibt, dass eine Anwendung per SQL bedienbar ist, ist das natürlich ganz was anderes als ein RDBMS, das nur als Datencontainer verwendet wird. Prinzip bedingt, gibt es aber m.E. nichts Schnelleres als DB Server Business Logik.
Das könnte dann auch ein Argument für Kunden sein, nicht auf das gewohnte "Haus" DB System zu setzen. Ist das RDBMS dann noch kostenlos, hat man eigentlich ganz gute Argumente. Nein, ist das RDBMS sogar OpenSource, dann hat man ganz gute Argumente für eine sehr spezifische Lösung.

Wieauchimmer, gehört wohl nicht ganz hier her.
Gruß, Jo
  Mit Zitat antworten Zitat
Benutzerbild von p80286
p80286

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

AW: Kauf- und Kontenverwaltung - Datenbank notwendig?

  Alt 13. Jan 2018, 23:25
Mir scheint das wichtigste für eine Buchung fehlt noch, die KontoNummer!?

Was die DB-Zugriffskomponenten angeht
a) Ihre Syntax ist weitestgehend Kompatibel
b) Jede Komponente unterstützt mehrere Datenbanken

Auch wenn ADO nicht dieee Schnittstelle ist, um einen Prototypen zu erstellen ist sie wohl gut genug. Später kann man dann noch, falls notwendig eine optimale Komponente verwenden.

Auch wenn es ein nicht kommerzielles Projekt ist, zumindest das, was nichts kostet darf durchaus professionellen Ansprüchen genügen. Mann könnte auch sagen mach es ordentlich oder laß es.

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
2.400 Beiträge
 
Delphi 7 Professional
 
#84

AW: Kauf- und Kontenverwaltung - Datenbank notwendig?

  Alt 14. Jan 2018, 17:02
Prinzip bedingt, gibt es aber m.E. nichts Schnelleres als DB Server Business Logik.
Niemand kann schneller und besser mit den Daten in einer Datenbank umgehen, als die Datenbank, in der sich die Daten befinden.
Bisher konnte ich noch jedem im Kollegenkreis, der etwas anderes behauptete, das Gegenteil beweisen.

Man muss sich halt nur einmal die Mühe machen SQL zu lernen und sich in die Programmiersprache der jeweiligen Datenbank einarbeiten. (PL/SQL, T-SQL, PL/pgSQL ...)
Das ist kein Hokus-Pokus, sondern genauso leicht oder schwer erlernbar, wie jede andere Programmiersprache auch.
Und gerade bei großen Datenmengen spart man eine Menge an Datentransfer zwischen DB und Software. Und bei der Reportgenerierung, Summierungen, Aggregierung, Abrechnungen ... und was weiß der Geier noch, aus welchen Gründen Abhängigkeiten, Zusammenhängen ... großer Datenmengen untereinander ermittelt werden müssen, Datenbanken sind doch genau dafür da und in dem Bereich unschlagbar schnell.
  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 · Datenschutz · Nach oben
Alle Zeitangaben in WEZ +1. Es ist jetzt 10:37 Uhr.
Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz