Relationales Datenbankmodell - MySQL

[Gevent]

Moin,

ich habe Fragen zu meiner Datenbank, die ich erstellt habe. Zum einen wollte ich gerne wissen, ob es generell zulässig oder empfohlen ist, dass es zwischen zwei Tabellen, zwei Relationen gibt.

In meinem Fall hat es sich so ergeben, dass ich zwei Geräte miteinander verknüpfen möchte, weil zum Beispiel für jede Heizung auch ein Temperatursensor vorhanden sein sollte.

Im Diagramm rot markiert, die Device_IDs sind einzigartig, auch die Namen und die Temp_device_IDs.






Es sei noch erwähnt, dass ich mittels Join die Daten aus den Tabellen, entsprechend korrekt abfragen und auch updaten kann. Da ich aber das Projekt noch erweitern möchte, stellt sich mir die Frage, ob das so passt oder eine gute Praxis ist.

Eine weitere Frage ist, wie würden die Profis unter Euch hier vorgehen, sollten die Tabellen weiter reduziert werden, ich tue mir da etwas schwer?

Die Redundanzen wie "device_group_function" können raus oder?


Über Tipps freue ich mich, danke im Voraus!

 

[Kampfgummibaerlie]

auf die schnelle:
zwischen zwei Tabellen können mehrere Relationen existieren

Beispiel:
Tabelle 1: Bibliotheken
Tabelle 2: Bücher
Tabelle 3: Lagerstand

create table bibliotheken(id integer primary key);
create table bücher(id integer primary key);
create table lagerstand(bibliothek integer references bibliotheken(id), buch integer references bücher(id));

Die Tabelle Lagerstand hat einfach nur pro Buch-ID einen einzelnen eintrag, ergibt massig datensätze in der praxis, möchte nur ein beispiel zeigen

 

[Gevent]

Auf mein Beispiel bezogen, werde ich da leider nicht ganz schlau daraus, weil mir die Abstrahierung noch sehr schwerfällt.



Sorry für die dummen Fragen, aber wie schaffe ich es, die Tabellen zu verkleinern und dennoch zwischen den Devices zu unterscheiden, irgendwie komme ich kognitiv nicht weiter. Die Sache ist die, ich habe das bereits in meiner Application mit den Abfragen so implementiert, dass unabhängig von den HW Adressen eine Zuordnung des Temp_Devices automatisch passiert. Der Schritt beim Design hat mich etwas überfordert, wenn ich ehrlich bin.



Ich poste auch gerne noch ein paar der Tabellen:

(hoffentlich kann man das lesen, ansonsten poste ich es in einem anderen Format)

SET NAMES utf8;
SET time_zone = '+00:00';
SET foreign_key_checks = 0;
SET sql_mode = 'NO_AUTO_VALUE_ON_ZERO';

DROP TABLE IF EXISTS `cooling_states`;
CREATE TABLE `cooling_states` (
  `id` int(64) unsigned NOT NULL AUTO_INCREMENT,
  `device_id` int(64) unsigned NOT NULL,
  `state_name` varchar(64) NOT NULL,
  `state_value` varchar(64) NOT NULL,
  `temp_device_id` int(64) unsigned NOT NULL,
  `cooling_temp` int(64) unsigned NOT NULL,
  `power_rate` int(64) unsigned NOT NULL,
  `device_group_function` varchar(64) NOT NULL,
  PRIMARY KEY (`id`),
  KEY `device_id` (`device_id`),
  KEY `temp_device_id` (`temp_device_id`),
  CONSTRAINT `cooling_states_ibfk_1` FOREIGN KEY (`device_id`) REFERENCES `devices` (`device_id`),
  CONSTRAINT `cooling_states_ibfk_2` FOREIGN KEY (`temp_device_id`) REFERENCES `devices` (`device_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb3;

INSERT INTO `cooling_states` (`id`, `device_id`, `state_name`, `state_value`, `temp_device_id`, `cooling_temp`, `power_rate`, `device_group_function`) VALUES
(1,    12,    'cooling_fan_1',    'true',    7,    0,    321,    'cooling'),
(2,    7,    'cooling_1',    'false',    7,    444,    0,    'cooling');

DROP TABLE IF EXISTS `devices`;
CREATE TABLE `devices` (
  `device_id` int(64) unsigned NOT NULL AUTO_INCREMENT,
  `device_address_name` varchar(64) NOT NULL,
  `address` int(64) unsigned NOT NULL,
  `device_name` varchar(64) NOT NULL,
  `device_type` varchar(64) NOT NULL,
  `device_group_function` varchar(64) NOT NULL,
  PRIMARY KEY (`device_id`),
  UNIQUE KEY `device_name` (`device_name`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb3;

INSERT INTO `devices` (`device_id`, `device_address_name`, `address`, `device_name`, `device_type`, `device_group_function`) VALUES
(1,    'cooling_pump_1_address',    512,    'cooling_pump_1',    'pump',    'cooling'),
(2,    'gas_valve_1_address',    513,    'gas_valve_1',    'valve',    'gas'),
(3,    'feed_pump_1_address',    514,    'feed_pump_1',    'pump',    'feed'),
(4,    'heating_mantle_1_address',    512,    'heating_mantle_1',    'heating_mantle',    'heating'),
(5,    'temp_heating_mantle_1_address',    1,    'temp_heating_mantle_1',    'thermo_element',    'measuring'),
(6,    'temp_pre_heating_1_address',    2,    'temp_pre_heating_1',    'thermo_element',    'measuring'),
(7,    'temp_coolant_1_address',    3,    'temp_coolant_1',    'thermo_element',    'measuring'),
(8,    'pre_heating_mantle_1_address',    525,    'pre_heating_mantle_1',    'heating_mantle',    'heating'),
(9,    'temp_pre_heating_mantle_1_address',    5,    'temp_pre_heating_mantle_1',    'thermo_element',    'measuring'),
(10,    'temp_feed_1_address',    4,    'temp_feed_1',    'thermo_element',    'measuring'),
(11,    'heating_feed_1_address',    560,    'heating_mantle_2',    'heating_mantle',    'heating'),
(12,    'cooling_fan_1_address',    532,    'cooling_fan_1',    'fan',    'cooling'),
(13,    'feed_pressure_1_address',    529,    'pres_feed_1',    'manometer',    'measuring');

DROP TABLE IF EXISTS `heating_states`;
CREATE TABLE `heating_states` (
  `id` int(64) unsigned NOT NULL AUTO_INCREMENT,
  `device_id` int(64) unsigned NOT NULL,
  `state_name` varchar(64) NOT NULL,
  `state_value` varchar(64) NOT NULL,
  `heating_temp` int(64) unsigned NOT NULL,
  `temp_device_id` int(64) unsigned NOT NULL,
  `device_group_function` varchar(64) NOT NULL,
  PRIMARY KEY (`id`),
  UNIQUE KEY `temp_device_id` (`temp_device_id`),
  KEY `device_id` (`device_id`),
  CONSTRAINT `heating_states_ibfk_1` FOREIGN KEY (`device_id`) REFERENCES `devices` (`device_id`),
  CONSTRAINT `heating_states_ibfk_3` FOREIGN KEY (`temp_device_id`) REFERENCES `devices` (`device_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb3;

INSERT INTO `heating_states` (`id`, `device_id`, `state_name`, `state_value`, `heating_temp`, `temp_device_id`, `device_group_function`) VALUES
(1,    4,    'heating_mantle_1',    'false',    100,    5,    'heating'),
(2,    8,    'pre_heating_mantle_1',    'false',    100,    9,    'heating'),
(3,    11,    'heating_feed_1',    'false',    55,    10,    'heating');

 

[Kampfgummibaerlie]

Was verstehst du unter "Die Tabelle verkleinern" ?

Man kann:
1.: Datensätze löschen
2.: Spalten löschen

 

[Gevent]

Was verstehst du unter "Die Tabelle verkleinern" ?

Man kann:
1.: Datensätze löschen
2.: Spalten löschen

Da bin ich leicht überfragt.

Möglicherweise drücke ich mich falsch aus und meine normalisieren. Sollte ich die Temp_Devices auf eine eigene Tabelle legen? Das Problem wäre dann aber, dass ich für jede Device_Gruppe eine eigene Tabelle anlegen müsste, der Punkt verwirrt mich etwas.

Oder passt das so, wie ich es gemacht habe?


Edit:

Das mit den Büchern in deinem Beispiel wäre nicht optimal, weil zu viele Datensätze, aber bezogen auf mein Szenario, mit überschaubaren Datensätzen, kann das gut funktionieren, verstehe ich das richtig?

 

[dabadepdu]

Objekte aus dem echten Leben in einer DB darzustellen kann schon kniffelig sein.
In Deinem Fall wäre ein objektrelationales Modell vielleicht gar nicht verkehrt, theoretisch. Ist wenig verbreitet, gibt es aber.
Realistischer wäre EAV Modellierung oder Dokument basierte Speicherung.
EAV bedeutet leider relativ komplizierte Abfragen, bei Dokument basierten Verfahren ist mySQL glaub ich nicht besonders stark.

Wenn Du mit mySQL arbeiten musst, dann würde ich die Tabellen nicht vollständig normalisieren.
Zuerst: Eine State Tabelle für alle Devices. Dabei den Kernwert vereinheitlichen, cooling_temp, heating_temp, state_value wird alles zu meinetwegen state_value. Also eine Tabelle hat natürlich immer den gleichen Spaltennamen für den Wert. Dazu kannst Du eine Spalte spendieren, die die Einheit liefert, auch eine für Typ , für Gruppe, für Vorzeichen, je nach Bedarf.
Einige der Spalten könntest Du als separate FK anlegen.

Zu dem Doppelproblem (das mit Temp habe ich nicht richtig verstanden), Temporäre Tabellen oder Temperatur Tabellen?
Du hast derzeit eine 1:1 Verknüpfung zwischen individuellen State Tabellen und dem Device.
Die kannst Du ändern auf 1:n. 1 State zeigt per FK auf ein eindeutiges Device. Das geht dann auch für mehrere States.

Normalisierung versus Denormalisierung:
Denormalisierung ist nicht das schlechthinnige Böse. Denormalisierung erfordert aber mehr Aufwand bei der Dateneingabe oder Änderung, das kostet wiederum Zeit, ist fehleranfälliger, .. logisch. Informationen stehen nicht mehr an einer Stelle, können widersprüchlich werden, wenn die Datenpflege nicht überwacht wird.
Sowas macht man per Constraint oder Trigger. Bei Constraint ist mySQL auch nicht besonders berühmt. Bleibt die Anwendung. Die Anwendung muss "hoheitlich" zumindest die kritischen Stellen überwachen. Nach dem Motto, es kann nur einen geben. Damit weicht man letztlich das Client Server Prinzip auf. Der DB Server ist kein Alleinherrscher mehr, sondern eher ein Client. Das Gute daran, er kann es nicht spüren Das Schlechte, es kann trotzdem Ärger geben.

Zukunft
Wenn Du in der Programmierung der Sensoren drin bist, hast Du sicher schon die ein oder andere Schnittstelle zu irgendwelchen Sensoren gesehen und da gibt es m.E. kleine bis mittlere "Katastrophen". Tonnenweise Daten ... häufig ist das XML, JSON, Records, Arrays..
Seit einigen Jahren gibt es immer mehr Sensoren, die wie Du beschreibst, aus mehr als einem Sensor bestehen. Im Prinzip sind es ja eh mittlerweile eigene Rechner. Worauf ich hinaus will:
Wenn Du einen Raumsensor hast, der 30 Bewegungszonen abbildet, die Temperatur und Luftfeuchtigkeit liefert und noch mehr Zeug, möchtest Du vom Modell her eigentlich recht flexibel sein.
Da spricht m.E. viel für Dokument basierte Speicherverfahren, die einfach per JSON alles "schlucken", was kommt. Oft ist die Schnittstelle eh schon json. Also vielleicht mal drüber nachdenken, da mitzugehen und eine geeignete, vielseitige DB zu nehmen.

P.S: Hier kannst Du mal reinschauen, da gibt es eine Umstellung von EAV nach JSON
generelle Vergleich EAV/ JSON

Mehrere Spalten mit einem Schlüssel, anhand von gleichnamigen Spalten filtern

Hallöchen, leider habe ich massive Probleme mit einer MSSQL-Abfrage. Ich habe beispielsweise diese Werte diese Tabelle heist "#rights_table" Will nun anhand der variablen (zur Erklärung: ist ein Token welches dann mehrere Variablen mit unterschiedlichen Inhalt haben kann) und deren Inhalt...

www.datenbankforum.com

dieser und die Folgebeiträge zeigen ein komplettes SQL Beispiel mit JSON Umstellung.

Mehrere Spalten mit einem Schlüssel, anhand von gleichnamigen Spalten filtern

Als kleiner Nachtrag: wie könnte ich das ganze mit einfachen AND´s machen? Versteh die Frage nicht, wenn Du gleichzeitig gültige Kriterien hast, musst Du mit ODER arbeiten.

www.datenbankforum.com

(Hier geht es allerdings weniger um das, was sich innerhalb JSON abspielt, als den Performancegewinn, den die generelle Umstellung bietet. Die Freiheitsgrade mit JSON nimmt man natürlich immer mit.)

 

[Gevent]

Objekte aus dem echten Leben in einer DB darzustellen kann schon kniffelig sein.
In Deinem Fall wäre ein objektrelationales Modell vielleicht gar nicht verkehrt, theoretisch. Ist wenig verbreitet, gibt es aber.
Realistischer wäre EAV Modellierung oder Dokument basierte Speicherung.
EAV bedeutet leider relativ komplizierte Abfragen, bei Dokument basierten Verfahren ist mySQL glaub ich nicht besonders stark.

Wenn Du mit mySQL arbeiten musst, dann würde ich die Tabellen nicht vollständig normalisieren.
Zuerst: Eine State Tabelle für alle Devices. Dabei den Kernwert vereinheitlichen, cooling_temp, heating_temp, state_value wird alles zu meinetwegen state_value. Also eine Tabelle hat natürlich immer den gleichen Spaltennamen für den Wert. Dazu kannst Du eine Spalte spendieren, die die Einheit liefert, auch eine für Typ , für Gruppe, für Vorzeichen, je nach Bedarf.
Einige der Spalten könntest Du als separate FK anlegen.

Zu dem Doppelproblem (das mit Temp habe ich nicht richtig verstanden), Temporäre Tabellen oder Temperatur Tabellen?
Du hast derzeit eine 1:1 Verknüpfung zwischen individuellen State Tabellen und dem Device.
Die kannst Du ändern auf 1:n. 1 State zeigt per FK auf ein eindeutiges Device. Das geht dann auch für mehrere States.

Normalisierung versus Denormalisierung:
Denormalisierung ist nicht das schlechthinnige Böse. Denormalisierung erfordert aber mehr Aufwand bei der Dateneingabe oder Änderung, das kostet wiederum Zeit, ist fehleranfälliger, .. logisch. Informationen stehen nicht mehr an einer Stelle, können widersprüchlich werden, wenn die Datenpflege nicht überwacht wird.
Sowas macht man per Constraint oder Trigger. Bei Constraint ist mySQL auch nicht besonders berühmt. Bleibt die Anwendung. Die Anwendung muss "hoheitlich" zumindest die kritischen Stellen überwachen. Nach dem Motto, es kann nur einen geben. Damit weicht man letztlich das Client Server Prinzip auf. Der DB Server ist kein Alleinherrscher mehr, sondern eher ein Client. Das Gute daran, er kann es nicht spüren Das Schlechte, es kann trotzdem Ärger geben.

Zukunft
Wenn Du in der Programmierung der Sensoren drin bist, hast Du sicher schon die ein oder andere Schnittstelle zu irgendwelchen Sensoren gesehen und da gibt es m.E. kleine bis mittlere "Katastrophen". Tonnenweise Daten ... häufig ist das XML, JSON, Records, Arrays..
Seit einigen Jahren gibt es immer mehr Sensoren, die wie Du beschreibst, aus mehr als einem Sensor bestehen. Im Prinzip sind es ja eh mittlerweile eigene Rechner. Worauf ich hinaus will:
Wenn Du einen Raumsensor hast, der 30 Bewegungszonen abbildet, die Temperatur und Luftfeuchtigkeit liefert und noch mehr Zeug, möchtest Du vom Modell her eigentlich recht flexibel sein.
Da spricht m.E. viel für Dokument basierte Speicherverfahren, die einfach per JSON alles "schlucken", was kommt. Oft ist die Schnittstelle eh schon json. Also vielleicht mal drüber nachdenken, da mitzugehen und eine geeignete, vielseitige DB zu nehmen.

Hallo dabadepdu,

vielen herzlichen Dank für die ausführliche Antwort. Das erklärt einiges, das EAV Prinzip kannte ich noch gar nicht.

Objekte aus dem echten Leben in einer DB darzustellen kann schon kniffelig sein.

*Absolut


Ich denke, ich belasse mein Konzept vorerst so wie es aktuell ist, da es bis dato gut funktioniert und die Anzahl der Datensätze überschaubar ist auch in Zukunft.

Das Temp_Device = Temperatur_Device, richtig. Das ist der jeweilige Temperatursensor zum entsprechenden Heizelement.

DB-Design ist ein komplexes Thema, ich werde mich weiter damit beschäftigen.


Grüße

 

[Gevent]

Was mir gerade auch wieder eingefallen ist, hatte meinen Code schon seit Monaten nicht mehr angeschaut, ich handle den DB-Zugriff über MySQL-Alchemie und habe das in einer objektrelationales Modell mittels ORM implementiert. Warum ich das so gemacht habe, verstehe ich auf theoretischer Basis zwar noch nicht ganz, aber es funktioniert.

 

[dabadepdu]

Naja, vielleicht hast Du jemand gefragt und der hat Dir den Tipp gegeben.
Diese Mapper sind ja dafür da, Du kannst Code/Objekte entwickeln und es kann Dir sch.. egal sein, was der Mapper bzw. die DB dann daraus macht. Ich bin nicht überzeugt von diesen Mappern, da kommt m.E. manchmal ziemlicher Dreck raus. Nicht aus Prinzip, aber u.a. deswegen, weil sie offenbar "DB agnostisch" arbeiten und ihr Mapping offenbar auf "dem kleinsten gemeinsamen Nenner" (funktional) der unterschiedlichen RDBMS Anbieter aufbauen.
In einer kleinen Hausautomatisierung dürfte das zumindest unter Performanceaspekten aber egal sein.
Andererseits, wenn genug Daten zusammenkommen und das kann bei dem Thema schnell gehen, dann wird es spannend. Reporting könnte man dann ebenfalls über Mapper laufen lassen oder man macht es direkt auf dem Modell, das ORM produziert hat. Könnte lustig werden.

 

[Gevent]

Naja, vielleicht hast Du jemand gefragt und der hat Dir den Tipp gegeben.
Diese Mapper sind ja dafür da, Du kannst Code/Objekte entwickeln und es kann Dir sch.. egal sein, was der Mapper bzw. die DB dann daraus macht. Ich bin nicht überzeugt von diesen Mappern, da kommt m.E. manchmal ziemlicher Dreck raus. Nicht aus Prinzip, aber u.a. deswegen, weil sie offenbar "DB agnostisch" arbeiten und ihr Mapping offenbar auf "dem kleinsten gemeinsamen Nenner" (funktional) der unterschiedlichen RDBMS Anbieter aufbauen.
In einer kleinen Hausautomatisierung dürfte das zumindest unter Performanceaspekten aber egal sein.
Andererseits, wenn genug Daten zusammenkommen und das kann bei dem Thema schnell gehen, dann wird es spannend. Reporting könnte man dann ebenfalls über Mapper laufen lassen oder man macht es direkt auf dem Modell, das ORM produziert hat. Könnte lustig werden.

Dasselbe habe ich mir auch gedacht, deswegen auch meine Frage zum DB-Design usw., weil einerseits, auch wenn es aktuell funktioniert, was habe ich davon, wenn ich es nicht wirklich verstehe und andererseits stelle ich mir die Frage, ob es auch noch funktioniert, wenn ich an der DB was ändere.

Mit dem Python MySQL.connector hatte ich Schwierigkeiten bzw. habe ich damit keine vernüftigen Joins zusammenbekommen, keine Ahnung an was das lag... na ja egal, ich muss mich da wohl noch um Alternativen umsehen, befürchte ich.

 

[dabadepdu]

Ich kenne mich kaum aus mit ORM Mappern. An der DB würdest Du da prinzipiell nichts ändern, nicht von Seiten der DB aus jedenfalls. Du kannst dem ORM meist Annotationen mitgeben, wenn Dir z.B. die Namensgebung nicht gefällt, einfachster Fall oder wenn Du tatsächlich das DB Modell konkret beeinflussen willst oder vielleicht sogar Indexverwendung. Am Ende kannst Du natürlich nach Herzenslust Deine Klassen umbauen, dem muss der Mapper ja folgen.

Joins aus dem ORM müssen natürlich auf der DB in echtes SQL umgesetzt werden, im Code mit einem Entity Manager sieht es aber anders aus bzw. nur so ähnlich aus. Es gibt wie in SQL vielleicht implizite und explizite Joins, die über das Klassenwissen des ORM zu SQL aufgelöst werden. Left, right, outer Joins, hängt sicher alles vom spezifischen ORM ab.

Die Schritte des ORM zu verstehen, ist bestimmt nicht verkehrt. Da hilft nur Doku und echte Arbeit mit dem ORM. Immer wieder schauen, wie sich das DB Modell ändert, wenn man die Klassen umbaut. Aber die Popularität dieser Mapper scheint auch daran zu hängen, dass man von DB Design nichts verstehen muss und einfach "coden" kann.
Wenn man selber anfängt, dem ORM Joins reinzubauen, gibt es auf der Strecke vielleicht ein Missverständnis. Ich meine, man kann das vielleicht als Warnsignal verstehen, wenn man versucht ist, das zu tun. Man müsste ja immer mit Code in der Lage sein, die gewünschten Daten zu erhalten. Dann gibt es vielleicht noch die Motivation Faulheit oder Performance, so viel Coding für diese banale Anzeige, so schlechte Performance, wenn man jeden DS einzeln holt... Da hilft wahrscheinlich nur Ausprobieren (Code und verschiedene Mapper) und Lernen.

 

[Gevent]

Ok Danke.

Ich habe die Klassen im Programm der Datenbank angepasst, nicht andersherum

Ich möchte auf das Skript seitige ORM eigentlich verzichten, beim nächsten Refactoring werde ich eine andere Bibliothek verwenden wie mysql-client oder so...

Für meinen speziellen Fall würdest Du das auch mittels MySQL realisieren oder ein anderes Datenbanksystem nutzen? Wäre PostgreSQL vielleicht besser geeignet?


Wie ließe sich die Performance verbessern oder besser gefragt, welche DB-Systeme wären zu empfehlen, welche sich auch möglichst leicht administrieren lassen und auch für konkurrierende Zugriffe einen Sicherheitsmechanismus besitzen?

Welche Literatur würdest Du mir empfehlen, um mein Wissen solide zu erweitern, sollte aber nicht zu abgehoben sein, also besser eher praktisch orientiert als nur mathematische Beweise und Modelle.

 

[dabadepdu]

Ich würde mySQL nicht mit der Kneifzange anfassen.
Die generelle Datenmodellfrage ist weitgehend erstmal nicht so sehr eine Frage der DB (also die gängigen kommerziellen oder freien oder "freien"). Zumindest nicht, solange es nur um die Relationen selbst und ein paar Tabellen und Spalten geht. Die OR Mapper schaffen es ja auch DB unabhängig.
Aber dann ist man gleich bei Foreign Keys und generellen Spalten Constraints.
Wie schon gesagt, ein OR Mapper ist da wahrscheinlich eher bescheiden und nutzt eher wenig Hersteller spezifische Funktionen, Typen, Features usw.
Für kostenlose System kommen m.E. nur 2 in Frage, Postgres und Firebird, wenn es um einfache Administration geht.
Konkurrierende Zugriffe sind überall Standard. Wenn Du auf ORM verzichten willst, erschließt Du Dir m.E. erst die Power einer DB.

Literatur, das ist immer eine gute Frage, aber ich habe schon lange kein Buch mehr in der Hand gehabt.
Du machst das glaub ich nicht so verkehrt, ein Projekt starten, implementieren, Schwächen erkennen, umbauen, Alternativen suchen.
Dazu kann man noch Tutorials durcharbeiten oder eben ganz spezifisch Problemlösungen zu konkreten Fällen suchen, die einen plagen. Dann bist Du bei Foren wie diesem oder auch englischen Foren, die etwas näher am Puls sind. Die PG Community ist jedenfalls sehr hilfsbereit.
Am Ende hat man was gelernt und Erfahrung gesammelt. Am meisten wahrscheinlich dort, wo es auch "weh getan" hat.

 

[Gevent]

Ich würde mySQL nicht mit der Kneifzange anfassen.

Weil Oracle ?

Gut, vielen Dank für deine kompetenten Ratschläge, ich werde mir PostgreSQL auch mal ansehen und mein System sowie die Implementierung damit testen.

Falls sich noch weitere Fragen auftun, komme ich gerne wieder auf das Forum hier zurück. Stimmt, hier hat man das Gefühl, dass die Leute leidenschaftlich an der Hilfestellung interessiert sind, das ist leider nicht überall so.

Beste Grüße

 

[dabadepdu]

Weil Oracle ?

Nein, Oracle hat auch ein gutes (und sehr teures) Kernprodukt, Oracle Database. mySQL ist m.E. nur noch ein Teaser dafür.
Oracle als Unternehmen bzw. Anbieter (eines teuren Produkts) ist leider auch nicht unproblematisch -wie andere ähnlicher Größenordnung. Man ist dem mehr oder weniger ausgeliefert, wenn es mal brennt. Allerdings auf einem wirklich deutlich besseren Niveau als bei mySQL.