Wieviele Datenbankverbindungen

[Bernie110]

Hallo Zusammen,

ich hab mal 4 grundsätzliche Fragen wie ihr das macht.

1.Frage :
Ich habe meine Daten auf einem MySQL Server.
Derzeit benutze ich eine Verbindung.
Wenn ich mehrere Fenster geöffnet habe und neue Daten mit Z.b ....

Code: Alles auswählen

          frm_Hauptmenu.SQLQuery1.close;
          frm_Hauptmenu.SQLQuery1.SQL.Clear;
          frm_Hauptmenu.SQLQuery1.SQL.Add('INSERT INTO STAMM BLABLABA);
 
          frm_Hauptmenu.SQLQuery1.ParamByName blablabla................................
          Frm_Hauptmenu.SQLQuery1.ExecSQL;
          frm_Hauptmenu.SQLTransaction1.Commit; 

anlege, dann verschwinden alle meine DBGrid Befüllungen in allen anderen Fenster.
Jetzt kam mir der Gedanke , vll noch 2 Verbindungen anzulegen. Eine nur zum wegschreiben, und 2 zum Filtern.
Keine Ahnung ob man das so macht.
Wie mach Ihr das ?

2.Frage
Wie macht ihr das mit den Datenbankverküpfungsdaten ?
Die stehen beim Erststart ja nicht zur Verfügung.
Momentan habe ich alle erforderlichen Verbindungsdaten
in die MySQL57Connection1 geschrieben.
Ich würde das jetzt so lösen, dass man beim ProgrammStart- Also beim ersten Mal - eine Mandanten - Karte ausfüllen muss und diese Verbindungsdaten
dort eingibt. Ein Button soll zum Test der Verbindung dienen. Gibt es eine Verbindung, dann lege ich die Verbindungsdaten auf dem SQl-ab.
Wie mach Ihr das ?

3. Frage
Stichwort Mandanten... So wirklich verstanden habe ich noch nicht, wie ein "mehr - Mandaten- fähiges" Programm aufgebaut sein sollte.
Also den Sinn hab ich schon begriffen... aber wie man das macht....und wann es eigentlich sinnvoll ist...nicht
Legt man da für jeden einzelnen Datensatz dann die jeweilige Mandanten ID ab ? Scheint mir nicht sinnvoll zusein.
Oder legt man auf dem SQL eine eigne Datenbank an und wechselt dann nur die Verbindung ? Macht mir aber auch irgend wie keinen Sinn

4.Frage
Stichwort units... Wenn ich so weiter programmiere und teste, dann bekomme ich in den nächsten 6 Monaten über 3000 Units zusammen.
Gibts da Grenzen ?
Da werden jetzt bestimmt einige sagen, ich muss mein Konzept überdenken...vorab.. deshalb frag ich ja

Im Voraus vielen Dank für eure Antworten.
Lg Bernie

[sstvmaster]

Zu Frage 3.

3. Frage
Stichwort Mandanten... So wirklich verstanden habe ich noch nicht, wie ein "mehr - Mandaten- fähiges" Programm aufgebaut sein sollte.
Also den Sinn hab ich schon begriffen... aber wie man das macht....und wann es eigentlich sinnvoll ist...nicht
Legt man da für jeden einzelnen Datensatz dann die jeweilige Mandanten ID ab ? Scheint mir nicht sinnvoll zusein.
Oder legt man auf dem SQL eine eigne Datenbank an und wechselt dann nur die Verbindung ? Macht mir aber auch irgend wie keinen Sinn

Also zb. Lexware oder Sage legen eine neue Datenbank für jeden neuen Mandant an.
Weil jeder Mandant ja auch andere Eigenschaften hat.

Du kannst einen Mandant als eigene Firma annehmen. Ich kenn das von einem Kunden von uns aus der Gastronomiebranche.
Hier sind in der Warenwirtschaft/Lohnbuchhaltung alle einzelnen Restaurants als eigener Mandant angelegt.
Es sind auch eigene Datenbanken je Mandant.

LG Maik

[Warf]

Zu Frage 1:
Mehrere Verbindungen brauchen mehr Speicher und mehr File-Deskriptoren, ich glaub unter Linux kann man maximal 65k (also 16 bit) File-Deskriptoren offen haben, sollte also im grunde kein problem sein. Kommt natürlich auch auf den Datenbank-server an. SQLite mag mehrere verbindungen glaube ich gar nicht, richtige server datenbanken wie MySQL/MariaDB, MSSSQL oder so haben damit aber absolut kein problem.
Ich glaub aber normalerweise sollte man innerhalb eines programms mit verschiedenen Queries und Transaktionen auf der Selben Connection arbeiten, aber du kannst auch problemlos mit mehreren connections arbeiten.

Zu Frage 2:
Meinst du jetzt Datenbank user und Passwort? Schreib das in eine Config datei (z.b. über JsonConfig) und les die am anfang aus. Wenn die daten Fehlen frag den User nach und erstell die Datei. So mach ich das auch immer

Frage 3:
Kommt ganz drauf an, wenn sie grundsätzlich die selben daten haben macht es keinen sinn x mal die selbe Datenbank für jeden Mandanten zu erstellen. Wenn Mandanten unterschiedliche Tabellenstrukturen haben macht eine eigene Datenbank pro Mandant natürlich Sinn.
Wenn du eine Tabelle für alles benutzt, denk dran Foreign Keys zu setzen, um effizienten zugriff und Linken von Daten zu erlauben

Frage 4:
Der FPC ist soweit ich weiß (zumindest unter windows) ein reines 32 bit programm, wenn du also die 3 GB RAM überschreitest, gehts kaputt, da kannst du aber sehr viele Units erstellen für.
Grundsätzlich gilt, lieber mehr units haben als wenige riesen units, aber wenn du 3000 Units zusammen bekommen solltest die 1. keinen code teilen (denn geteilten code kannst du auslagern) und 2. mehr als 100 zeilen lang sind (ansonsten lohnt sich ne eigene unit nicht wirklich), echt respekt. Falls eine der beiden bedingungen erfüllt ist, solltest du eventuell schauen das du entweder code dublikate auslagerst, oder Units die nur wenige daten enthalten zusammen führst.

[MacWomble]

Auch ich habe hier schon verschiedene Ansätze versucht. Ich schreibe hauptsächlich kaufm. Anwendungen. Teilweise hatte ich aber extrem viele offene Tabellen, insbesondere wenn ich mit mehreren datengebundenen Grids arbeitete.
Inzwischen habe ich nur noch eine DB-Verbindung über welche ich immer die benötigten Daten auslese. Die Daten lese ich in Objekte ein und verwalte diese bis zum zurück schreiben (falls geändert/ergänzt) im Speicher. Die Datenbankzugriffe sind so auf ein sehr geringes Maß reduziert und das Programm (vor allem auch das Scrollen in Grids) läuft extrem schnell.
Ergo: eine DbConnection, und eine ZQuery, Tabellen in Klassen abgebildet - mehr braucht es fast nicht.
Wichtig dabei: Keine DB-gebundenen Controls wie DBEdit, DBGrid etc. !

Bsp: Table artgroups

Ich erzeuge eine Instanz der Klasse Artikelgruppen und lese die Daten beim Programmstart (in diesem Fall) ein. Im Programm kann ich diese dann - zunächst unabhängig von der DB - so ansprechen:
Edit1.Text := Artikelgruppe.Nummer
Edit2.Text := Artikelgruppe.Name
...

Jede Insatanz hat ein Property 'IsChanged', welches beim Editieren oder neu Einfügen gesetzt wird. Beim Schreiben in die Datenbank muss ich nur die Datensätze mit IsCanged=True berücksichtigen.

[charlytango]

ad 1 und 2

für meine Datenbankapplikationen benutze ich ein Singleton-Objekt (keine graphischen Elemente und kein Datamodul, denn die machen Probleme wenn man sie vererben will) das alle Funktionen enthält um sich mit einer Datenbank zu verbinden. Diese Objekt ist global im Programm verfügbar.
Das wird automatisiert während des Programmstarts hinter einer Splashscreen versteckt mit etlichen anderen Funktionen gestartet die das Programm benötigt. Alle Prüfungen, Zugriffsmechanismen etc etc. sind in diesem Singleton-Objekt. Auch solche um einfach von einer Datenbank auf eine ander umschalten zu können. Auch solche unterschiedlichen Typs (MSSQL, Mysql, SQlite etc ). Auch das Logging der SQL-Befehle liegt dort.

für die einzelnen Forms die DB-Zugriff brauchen nutze ich zwei Varianten. bei (funktionstechnisch) kleineren Formularen klebt direkt auf dem Formular eine Datenbankzugriffskomponente (SQLQuery) und zur Verbindung mit den DB-sensitiven Controls die dazu gehörende TDatasource. Im OnCreate Event des Formulars wird die Connection zugewiesen.

Code: Alles auswählen

SQLQuery1.Connection:=DB_Singleton.Connection1 

Bei Formularen mit einigen SQLQueries mehr benutze ich pro Formular jeweils formularspezifische Datamodules in die ich die TSQLQueries dann klebe oder organisiere.

Bei den Datenbankeinstellungen (zB am SQL Server) muss nur dafür gesorgt werden dass die nötige Anzahl an gleichzeitigen DB-Verbindungen verfügbar ist.

Die verwendeten Strategien holen immer nur die nötigsten Daten für das Formular und nicht mehr, damit ist das Programm auch übers Internet passabel performant

ad 3

bei Mandanten muss zuerst die Frage geklärt werden ob ein Mandant auch Zugriff zu den Daten eines anderen mandanten haben darf oder soll (z.B. eine gemeinsame Adressdatenbasis, wenn es quasi "virtuelle" Mandanten innerhalb einer Firma sind) . Ist dem so dann muss für jeden Mandanten in jedem Datensatz eine ID mitgeführt werden, ist aber keine Hexerei. Tricky wird es erst wenn der eine Mandant Daten ändern oder löschen will die auch einem anderen gehören.

Je eine DB pro mandanten aufsetzen geht immer. (wenn die DB-Anbindung flexibel genug ist)

ad 4
ich bezweifle dass du so schnell 3000 Units zusammen bringst. Für eine funktional recht umfangreiche Applikation mit Kunden,Adressen, unterschiedlichen Artikeltypen, Fakturierung, Zahlungsystem samt Druck und Versand und noch einigen anderen Gimmicks haben wir etwa 200 Tabellen in der DB verbraten und dazu um die 50 HilfsUnits, 15 für den Druck, 60 Datenmodule und etwa 180 Formulare. Entwicklungsaufwand in etwa 4,5 Mannjahre.

[Bernie110]

Hallo Zusammen, herzlichen Dank für eure Antworten !! Das hilft mir alles schon mal weiter !

Zu Frage1 ok dann bleibe ich bei einer Verbindung. Aber man sieht schon. Macht jeder anders
@ charlytango das muss ich gleich mal ausprobieren Danke

Zu Frage 2
@Warf

Zu Frage 2:
Meinst du jetzt Datenbank user und Passwort? Schreib das in eine Config datei (z.b. über JsonConfig) und les die am anfang aus. Wenn die daten Fehlen frag den User nach und erstell die Datei. So mach ich das auch immer

Interessante Idee.. Kannte ich bis jetzt noch nicht. Wie sieht es da mit der Sicherheit aus ? eine Datei die irgendwo abgelegt wird stell ich mir problematisch vor

Zu Frage 3 Also die ID Variante schliesse ich schon mal für mich aus.. Das wird mir zur aufwendig. Und die Andere Variante scheint mir genau so wenig plausibel zu sein.
Ich kann ja verstehen, dass sich verschiedene Firmen nen gleichen SQL-Server teilen wollen, aber das selbe Programm ? .. Naja wird schon seinen Sinn haben.

Zu Frage 4 .. 3000 Units sind natürlich übertrieben, wollte wissen wie ihr reagiert..

Also realistisch gedacht.. so um die 500 sind locker drin.
Ok, das heisst dann wohl, dass man nicht so unbedingt vorsichtig sein muss oder ?
@ charlytango

Entwicklungsaufwand in etwa 4,5 Mannjahre.

Mindestens
Ich kann so was nicht in Mann-Jahre fassen. Bis Jahres -Ende hatte ich mir vorgenommen eine zu 80% funktionierende Version fertig zustellen.
Und dem Ziel stelle ich mich Letztendlich ist doch eine Software niemals fertig und dank Corona hab ich sowieso viel mehr Zeit hehe

Danke @ all + Lg Bernie

[Warf]

Interessante Idee.. Kannte ich bis jetzt noch nicht. Wie sieht es da mit der Sicherheit aus ? eine Datei die irgendwo abgelegt wird stell ich mir problematisch vor

Gibt 2 möglichkeiten, entweder der User gibt daten ein oder die werden Irgendwo gespeichert. Die passwörter in deinem Programm Quelltext zu speichern ist auch nicht sicherer, man kann problemlos alle strings aus einem Programm auslesen

Zu Frage 3 Also die ID Variante schliesse ich schon mal für mich aus.. Das wird mir zur aufwendig. Und die Andere Variante scheint mir genau so wenig plausibel zu sein.
Ich kann ja verstehen, dass sich verschiedene Firmen nen gleichen SQL-Server teilen wollen, aber das selbe Programm ? .. Naja wird schon seinen Sinn haben.

Wie gesagt, kommt auf die struktur an. Wenn alle die selben Daten brauchen macht es schon sinn für alle die selbe Tabelle und eventuell sogar programm zu benutzen. Wenn die daten aber unterschiedlich sind dann natürlich nicht.

Beispiel der Service spotify hat extrem viele Künstler, Alben und Songs. Aber die sind ja grundsätzlich alle nicht unterschiedlich, ein Künstler account bei spotify braucht weder ein anderes UI noch andere daten als ein anderer Künstler account.
Auf der anderen seite ein Unternehmen wie DHL das Subunternehmen für Flüge, Laster und Schiffsverkehr hat macht es wahrscheinlich keinen Sinn alle zusammen zu fassen. Alles eine frage wie Heterogen die daten sind

Zu Frage 4 .. 3000 Units sind natürlich übertrieben, wollte wissen wie ihr reagiert..

Also realistisch gedacht.. so um die 500 sind locker drin.
Ok, das heisst dann wohl, dass man nicht so unbedingt vorsichtig sein muss oder ?

Es kommt immer drauf an, wenn du jetzt sagen wir mal 10 forms hast die alle die selben Controls haben und sich nur in so 10% der funktionalität unterscheiden, da machts natürlich sinn die zusammen zu fassen. Oder wenn du die selbe funktion in 10 Units hast, einfach eine Utility Unit anlegen und da die Funktionen rein schmeissen. Auch immer nett ist die verwendung zum Frames für einzelne Teile einer Form auszulagern.

Aber solang du in dem Datei-Wirrwarr zurecht kommst, sollte das kein problem sein. Ich kann dir nur empfehlen sauber unterordner anzulegen. Aber grundsätzlich, lieber 500 dateien a 100 zeilen als 5 dateien mit 10k zeilen