Das deutsche Python-Forum

Hallo,
ich plane eine Datenbank mit unterschiedlichen Materialien und bin gerade dabei, mir ein Konzept auszudenken.
Die Datenbank hat unterschiedliche Parameter(Spalten), wie bspw. ID, Name, Dichte, Viskosität, usw.
Nun habe ich aber die Viskosität oftmals in Form einer Tabelle vorliegen in Abhängigkeit zweier Größen.

Ich kann/muss jetzt für jedes Material und jeden Parameter, der in Form einer Matrix vorliegt, eine neue Tabelle erstellen und diese irgendwie koppeln.
Oder kann man auch die Tabelle als Array in eine Zelle der Datenbank bringen und diese komplett auslesen?
Berechnen möchte ich innerhalb der Datenbank sowieso nichts.

Habt ihr da Ideen?

Patrick1990 hat geschrieben: ↑Freitag 19. Januar 2024, 15:32 Oder kann man auch die Tabelle als Array in eine Zelle der Datenbank bringen und diese komplett auslesen?

Hängt im Zweifel von der genutzten Datenbank ab. Welche soll es denn werden? In Firebird könnte man Array-Spalten definieren. Aber Zitat aus der Doku:

Therefore, the general advice is: do not use arrays.

https://firebirdsql.org/file/documentat ... array.html

Danke für die Antwort.
Das ist ja lustig...man kann sie verwenden aber sollte nicht.

An sich dachte ich an SQLite, damit habe ich schon einmal ein kleines Projekt umgesetzt.

Gibt es sonst eine andere Möglichkeit, wie ich so eine Materialdatenbank aufbauen kann? Hast du eine Idee?

Man kann nicht viel antworten, bevor du uns sagst, von welchen Werten die Viskosität in deinem Modell genau abhängt. Material? Temperatur? Luftdruck? Sternenkonstellation?

Die Viskosität ist nur ein Beispiel. Sie hängt von Temperatur und Druck ab.
Bei anderen Materialien sind aber wieder andere Tabellen/Matrizen hinterlegt. Es muss also alles flexibel sein.

Patrick1990 hat geschrieben: ↑Freitag 19. Januar 2024, 19:29 Es muss also alles flexibel sein.

Wenn man eine relationale Datenbank verwendet, dann tut man das üblicherweise, weil man die relationalen Eigenschaften auch nutzen will, nämlich indem man per select-Statement und Joins Daten abfrägt, wobei sich die Datenbank darum kümmert, dass das richtig herausgesucht wird. Wen du also Abfragen machen willst wie: "Zeig mir alle Materialien an, deren Viskosität bei einer Temperatur von ... und einem Druck von ... im Bereich von ... bis ... liegt". Oder: "Zeig mir für das Material ... an, welche Viskositäten es im Temperaturbereich ... bis ... bei einem Druck von ... hat". Dazu muss es aber eine Tabelle geben, in der der relationale[*] Zusammenhang von Material, Temperatur, Druck und Viskosität drinsteht. Das als Array (oder als Komma-getrennten String *schauder*) zu speichern, würde komplett dem relationalen Ansatz widersprechen.

[*]Relational heißt, dass es eine logische Relation zB. zwischen Material, Temperatur, Druck und Viskosität gibt. Relation ist einfach ein anderes Wort für Tabelle. Damit man Daten nicht redundant speichern muss, was im Lauf der Zeit zu Inkonsistenzen führen könnte, vergibt man für die Material-Tabelle einen Primärschlüssel, also einen Schlüssel, der jede Zeile innerhalb der Tabelle eindeutig identifizierbar macht, und referenziert diesen dann in einer anderen Tabelle (zB. die, in der der Zusammenhang mit der Viskosität festgelegt wird). Diese Referenz nennt man dann einen Fremdschlüssel. Relationale Datenbanken haben das eingebaut, dass man Primär- und Fremdschlüssel festlegen kann, und die Datenbank kümmert sich dann darum, dass man keinen Fremdschlüssel eintragen kann, zu dem es keinen korrespondierenden Primärschlüssel in der referenzierten Tabelle gibt. Die Datenbank kümmert sich dann auch darum, dass über den Fremdschlüssel abhängige Zeilen gelöscht werden, wenn die Zeile mit dem Primärschlüssel gelöscht wird, oder dass man letzteren nicht löschen kann, sofern es noch abhängige Zeilen mir entsprechendem Fremdschlüssel gibt. Das kann man für jede Tabelle festlegen.

Man erzeugt nicht eine Tabelle pro Material, Tabellen sind statisch. Statt dessen gibt es eine Tabelle mit Materialien und eine mit Viskositätswerten, wobei in der Viskositätstabelle Werte für alle Materialien stehen und jeder Wert hat neben Temperatur und Druck auch die ID zum Material gespeichert.

Die Temperatur und Druck-Werte sind jedoch nicht für alle Materialien gleich. Dann bräuchte ich nahezu für jedes Material eine extra Tabelle mit den Viskositätswerten, und viele weitere Tabellen mit Werten für dieses Material. Macht das dann noch Sinn?

Ich habe vorhin etwas von json-Datenbanken gelesen. Würde sowas nicht mehr Sinn ergeben? Müsste mich jedoch dazu erstmal noch genauer belesen.

@Patrick1990: such mal bei Wikipedia nach Normalisierung von Datenbanken. Der Artikel erklärt das ganz gut.

Patrick1990 hat geschrieben: ↑Freitag 19. Januar 2024, 19:29 Es muss also alles flexibel sein.

Ja, "alles ganz flexibel" will man natürlich gerne Aber auf dem Abstraktionsniveau, auf dem du bisher bleibst, ist das, finde ich, nur ein schwammiger Allgemeinplatz und du wirst vmtl. nicht wirklich voran kommen. M.M.n. ist ein wichtiger Schritt beim Datenbank-Entwurf, dass man sich eben hinsetzt und z.B. überlegt, was für Daten man hat, wie die strukturiert sind, welche internen Beziehungen untereinander bestehen, welche Abfragen man darauf durchführen möchte usw. – ganz konkret. Danach kann man dann anfangen, zu überlegen, wie man das modelliert. Wenn es denn unbedingt relational sein soll, wurden ja schon gute Hinweise hier in anderen Posts gegeben, wie man das angehen kann. Oder man kann, wie du in deinem letzten Post angedeutet hast , noch mal einen Schritt zurückgehen auch über andere Datenbankkonzepte nachdenken ( "JSON" übertragen auf die Datenbankwelt kann zum Beispiel eine schemafreie Dokumentendatenbank sein); das kann aber ggf. für den Anfang etwas zu viel sein. Natürlich kann ein solches Design auch flexibel im Rahmen des Erwartbaren sein, aber wenn man alles ganz offen und unspezifisch hält, kommt halt wahrscheinlich nichts dabei raus, mit dem man gut und effizient arbeiten kann.

sparrow hat geschrieben: ↑Samstag 20. Januar 2024, 20:49 @Patrick1990: such mal bei Wikipedia nach Normalisierung von Datenbanken. Der Artikel erklärt das ganz gut.

Ich bin da nun noch nicht schlauer geworden.
So wie ich es verstehe, gebe ich dem Material bspw. eine Material ID und kann bspw. andere Tabelleneinträge(Zeilen) mit dieser ID verknüpfen.
Wie wende ich das aber nun auf meine Gegebenheiten an?

nezzcarth hat geschrieben: ↑Samstag 20. Januar 2024, 21:17

Patrick1990 hat geschrieben: ↑Freitag 19. Januar 2024, 19:29 Es muss also alles flexibel sein.

Ja, "alles ganz flexibel" will man natürlich gerne Aber auf dem Abstraktionsniveau, auf dem du bisher bleibst, ist das, finde ich, nur ein schwammiger Allgemeinplatz und du wirst vmtl. nicht wirklich voran kommen. M.M.n. ist ein wichtiger Schritt beim Datenbank-Entwurf, dass man sich eben hinsetzt und z.B. überlegt, was für Daten man hat, wie die strukturiert sind, welche internen Beziehungen untereinander bestehen, welche Abfragen man darauf durchführen möchte usw. – ganz konkret. Jedenfalls kann man danach dann kann man anfangen, zu überlegen, wie man das modelliert. Wenn es denn unbedingt relational sein soll, wurden ja schon gute Hinweise hier in anderen Posts gegeben, wie man das angehen kann. Oder man kann, wie du in deinem letzten Schritt angedeutet hast, noch mal einen Schritt zurückgehen auch über andere Datenbankkonzepte nachdenken; das kann aber ggf. für den Anfang etwas zu viel sein. Natürlich kann ein solches Design auch flexibel im Rahmen des Erwartbaren sein, aber wenn man alles ganz offen und unspezifisch hält, kommt halt wahrscheinlich nichts dabei raus, mit dem man gut und effizient arbeiten kann.

Danke, ich bin bzgl. des Datenbankkonzepts sehr offen und hole mir auch deshalb Hilfe ein, weil ich eben noch gar keine Ahnung habe, was hier Sinn machen würde. Es muss also nicht unbedingt relational sein. Bisher kannte ich ehrlich gesagt nur diese SQL Datenbanken.

Patrick1990 hat geschrieben: ↑Samstag 20. Januar 2024, 20:38 Die Temperatur und Druck-Werte sind jedoch nicht für alle Materialien gleich. Dann bräuchte ich nahezu für jedes Material eine extra Tabelle mit den Viskositätswerten, und viele weitere Tabellen mit Werten für dieses Material. Macht das dann noch Sinn?

Hatte ich nicht geschrieben, dass du nicht für jedes Material eine eigene Tabelle sollst?
Ein Eintrag in der Viskositätstabelle besteht aus: material_id, temperatur, Druck, viskosität.
Von diesen Einträgen gibt es eben dann ziemlich viele. Das ist der Datenbank aber im Normalfall ziemlich schnurz. Die kann damit umgehen.

Ok jetzt hab ichs verstanden...Das wird dann in der Tat mächtig groß.
Aktuell ist es so, dass diese Werte als Input für eine Interpolation dienen. Ich müsste dann also die relevanten Zeilen der Tabelle (ca. 300 pro Datensatz eines Materials) auslesen und dann verarbeiten. Ist das dennoch ok?

Wie Sirius3 schon sagte: ist der Datenbank schnurz. Das sind triviale Datenmengen.

Also wäre eine SQL noch besser als eine noSQL Datenbank?

Du hast strukturierte Daten.
Ich sehe nicht, warum da eine RDBMS nicht passen sollte.

Ok vielen Dank, dann spiele ich mal etwas rum.