nicht angemeldet
MYSQLI Datenbank mit komplexeren Einträgen?
Rolf B
AugeHallo,
Mir macht die Eindimensionalität von MYSQLI Datenbanken ein wenig zu schaffen...
Ist es möglich / ratsam, komplexere Zusammenhänge z.B. in Form eines Objekts/Dictionarys zu speichern?
z.B. ein Eintrag in der Spalte "Erfordernisse": {Alter: 14+, Ausbildung: ["Volkschule", "Hauptschule", "Realschule", "Gymnasium"]}
Wenn das prinzipiell keine schlechte Idee ist - wie kann dann ein Query aussehen? z.B.
"FINDE "Erfordernisse" WO Erfordernisse.Alter = "14+" UND Erfordernisse.Ausbildung.contains "Volksschule" UND Erfordernisse.Ausbildung.contains "Hauptschule" ODER Erfordernisse.Ausbildung.contains "Realschule"
Wenn das KEINE gute Idee ist, wie lassen sich solche komplexen Sachzusammenhänge dann umsetzen?
(Für gewisse zu unterrichtende Fächer gibt es leider verschiedenste Erfordernisse, die auch je nach KundenInnenstamm vollkommen unterschiedlich aussehen können - alternativ fiele mir nur noch ein, für JEDES. EINZELNE. Spezifikum eine eigene Spalte zu kreieren und dann einfach "Ja"/"Nein" als Eintrag zu hinterlegen -- das wäre dann aber eine Tabelle mit locker 100+ [!] Spalten 🤯 )
Danke, Rudi.
-
Hallo Rudi,
die "Eindimensionalität" einer relationalen Datenbank ist volle Absicht. SQL würde ohne diese Eigenschaft nicht sinnvoll funktionieren. Bzw. es kommt dann später im Betrieb der Datenbank zu Problemen, weil Abfragen nicht performant sind oder Updates umständlich werden.
Wenn das prinzipiell keine schlechte Idee ist
Doch. Ist es. Das Stichwort, was Du brauchst, heißt "Normalisierung". Dazu gibt's einiges in der Wikipedia oder auch in SQL Büchern.
Eine gute, normalisierte Datenbank zu designen ist nichts, was ich Dir in einem Forenbeitrag erklären kann, das ist zu umfangreich.
Deine Erfordernisse dürften jedenfalls zu mehreren Tabellen führen. Um ein Modellierungsbeispiel zu machen, ist deine Anfrage zu knapp, da fehlt es mir an Kontext.
Neuere Datenbanken kennen JSON Typen oder XML Typen und bieten an, eine komplexe Struktur als JSON- oder XML-String zu speichern. Sie bieten auch SQL Erweiterungen an, um darin zu suchen. Ich habe aber keine Ahnung, wie performant das ist und ob solche Spalten indexierbar sind. Sind sie es nicht, hast Du bei kleinen Tabellen und/oder wenig Zugriffen eine prima Leistung in der DB und bist happy. Und irgendwann schlägt es um, dann passt nicht mehr alles in den RAM des Servers und die DB ist von jetzt auf gleich schneckenlangsam.
Rolf
--
sumpsi - posui - obstruxi-
Hallo Rolf, Hallo Räuber,
Bin gerade schwer begeistert, das macht tatsächlich alles Sinn!
Kannte diese Leitlinien bisher nicht, fragte mich allerdings stets, wie es der Menschheit immer wieder gelingt, komplexe Sachzusammenhänge in einer Datenbank abzubilden - die Normalisierungsstufen 1NF bis 5NF sind eigentlich SO simpel und einleuchtend, dennoch wunderschön! 😜
EEEEEINE Frage allerdings zur normalisierten Aufteilung auf Tabellen:
Zusammenhänge zwischen einzelnen Tabellen werden dann ja sozusagen in "sekundären" Tabellen (ja ich weiß, technisch nicht die richtige Bezeichnung, hoffe ihr wisst trotzdem, was ich meine) mit Fremdschlüsseln (foreign keys) gespeichert.
...dies führt dann dazu, dass z.B. für "Dr. Rolf Räuber" Einträge in mehreren Tabellen angelegt werden.
WAAAAAS aber, wenn Dr. Rolf Räuber sich in der Datenbank nicht mehr wohlfühlt und beschließt, seinen Account zu löschen?
Durchsuche ich dann strategisch ALLE Tabellen und lösche alle Einträge die mit Dr. Rolf Räubers ID (primary Key der "ersten" Tabelle) gefunden werden?
Dank euch recht.
-
WAAAAAS aber, wenn Dr. Rolf Räuber sich in der Datenbank nicht mehr wohlfühlt und beschließt, seinen Account zu löschen?
Du wirst dem „Dr. Rolf Räuber“ (Namensähnlichkeiten sind sicher nur unbeabsichtigter Zufall) vor dem ersten Eintrag darauf hinweisen, dass er Einträge in ein öffentliches Forum macht, dass also seine Beiträge erhalten und seinem (Nick-)Name zugeordnet bleiben wenn er sich abmeldet.
Du musst ohnehin eine Datenschutzerklärung veröffentlichen, welcher die Betroffenen zustimmen müssen und Dir die Nutzungsrechte an den Äußerungen übertragen lassen.
Natürlich kannst Du auch den Nutzername durch „abgemeldete Person“ ersetzen. Hoffentlich klagt dann keine künstliche Intelligenz vor einem nur künstlich intelligentem Gericht auf Gleichstellung.
-
@@Rudi:
WAAAAAS aber, wenn Dr. Rolf Räuber sich in der Datenbank nicht mehr wohlfühlt und beschließt, seinen Account zu löschen?
Durchsuche ich dann strategisch ALLE Tabellen und lösche alle Einträge die mit Dr. Rolf Räubers ID (primary Key der "ersten" Tabelle) gefunden werden?
Du musst Deine Frage etwas präzisieren:
Reden wir gerade von Datenschutz im Sinne von z.b. DSGVO oder
sind wir rein technisch unterwegs und Du fragst, wie Du Rolf Räuber z.b. aus der Suchfunktion deiner Anwendung entfernst?Ersteres ist etwas differenzierter zu betrachten und mit allerlei Fallstricken versehen.
Zweiteres erledigt z.b. ein einfaches "Delete-Flag" in den Stammdaten Deiner Kunden, Mandanten, Ansprechpartner, Sportler, oder was auch immer dahinter steckt).
-
Hallo Roy Bär,
"Delete-Flag"
Guter Hinweis.
Es kommt darauf an, ob man Aufbewahrungsfristen für die Daten zu beachten hat.
Wenn nicht, kann man einfach löschen. Wenn doch, ja, dann braucht man ein "Deleted" Flag oder ein "Gültig_Bis" Datenfeld, und muss genau überlegen, wie man die Suchen baut, um nur gültige Rows zu verarbeiten. Ggf. muss man die Gültigkeit nicht nur auf Personenebene festlegen.
Bei einer "Gültig-Bis" Speicherung muss man dann auch noch einen Aufräumjob haben, der Sätze entfernt, die ungültig sind und deren Aufbewahrungsfrist abgelaufen ist. Einer solchen Pflicht-Aufbewahrung kann ein Kunde nicht widersprechen. Weil - ist ja Pflicht.
Rolf
--
sumpsi - posui - obstruxi-
Hallo Rolf,
Es kommt darauf an, ob man Aufbewahrungsfristen für die Daten zu beachten hat.
Und das müssen nicht einmal zwingend rechtliche Vorschriften der Aufbewahrung die Ursache sein, wie Du weiter unten aufführst.
Wenn nicht, kann man einfach löschen. Wenn doch, ja, dann braucht man ein "Deleted" Flag oder ein "Gültig_Bis" Datenfeld, und muss genau überlegen, wie man die Suchen baut, um nur gültige Rows zu verarbeiten. Ggf. muss man die Gültigkeit nicht nur auf Personenebene festlegen.
Bei einer "Gültig-Bis" Speicherung muss man dann auch noch einen Aufräumjob haben, der Sätze entfernt, die ungültig sind und deren Aufbewahrungsfrist abgelaufen ist. Einer solchen Pflicht-Aufbewahrung kann ein Kunde nicht widersprechen. Weil - ist ja Pflicht.
Nimm nur den reumütigen User, der gestern noch nichts mehr mit Rudis DB zu tun haben wollte, sich aber nach einmal darüber schlafen doch entschieden hat, wieder im Datenbestand sein zu wollen. Wie gut, wenn man ein Delete Flag hat.
Demnach würde ich eher umgekehrt agieren, nämlich, dass ich nur dann physikalisch lösche, wenn rechtliche Vorschriften mich hierzu zwingen (oder moralische Aspekte eine Rolle spielen), es ohnehin nur um temporäre Daten geht oder die Daten wirklich nur Ballast sind, der nie wieder gebraucht wird.
Alle anderen Daten würde ich im Datenbestand lassen und über einen Delete-Flag "deaktivieren".
Roy
-
Hallo Roy Bär,
Nimm nur den reumütigen User, der gestern noch nichts mehr mit Rudis DB zu tun haben wollte, sich aber nach einmal darüber schlafen doch entschieden hat, wieder im Datenbestand sein zu wollen. Wie gut, wenn man ein Delete Flag hat.
Ich denke, da irrst Du. Wenn ich keine Aufbewahrungspflicht habe, dann darf ich nicht aufbewahren. Ich könnte dieses Vorgehen dem User zwar bei der Registrierung in der Datenschutzerklärung aufnötigen. Dann muss ich mir aber auch einen wichtigen Grund dafür zusammenfabulieren, denn ansonsten könnte das ein Gericht (a) als überraschende Klausel und (b) als Verstoß gegen Datensparsamkeit kassieren. „Komfort bei irrtümlicher Accountkündigung“ dürfte als wichtiger Grund nicht durchgehen.
Wenn ich dieser reumütigen Userin[1] also ihr persönliches Osterfest bereite und die Daten wiederauferstehen lasse, dann laufe ich Gefahr, dass sie sofort zum Abmahnanwalt spaziert und sich ihr Osterkörbchen mit goldenen Eiern füllen lässt.
Oh. Dies hab ich überlesen:
Demnach würde ich eher umgekehrt agieren, nämlich, dass ich nur dann physikalisch lösche, wenn rechtliche Vorschriften mich hierzu zwingen
Ok, dann sind wir einer Meinung. Die rechtlichen Vorschriften sind nämlich so, dass jegliche Datenspeicherung, die keinen Grund hat, untersagt ist.
Rolf
--
sumpsi - posui - obstruxi
m/w/d ↩︎
-
@@ Rolf,
Nimm nur den reumütigen User, der gestern noch nichts mehr mit Rudis DB zu tun haben wollte, sich aber nach einmal darüber schlafen doch entschieden hat, wieder im Datenbestand sein zu wollen. Wie gut, wenn man ein Delete Flag hat.
Ich denke, da irrst Du. Wenn ich keine Aufbewahrungspflicht habe, dann darf ich nicht aufbewahren. Ich könnte dieses Vorgehen dem User zwar bei der Registrierung in der Datenschutzerklärung aufnötigen. Dann muss ich mir aber auch einen wichtigen Grund dafür zusammenfabulieren, denn ansonsten könnte das ein Gericht (a) als überraschende Klausel und (b) als Verstoß gegen Datensparsamkeit kassieren. „Komfort bei irrtümlicher Accountkündigung“ dürfte als wichtiger Grund nicht durchgehen.
Wenn ich dieser reumütigen Userin[^1]
Siehst Du Rolf, Du fängst mit dieser überflüssigen Genderei an und schon denkst auch Du nur noch eindimensional. Scheint irgendwie zur "Verblödungsstrategie der Menschen" der links-woken Gemeinde zu gehören. 😉
Oh. Dies hab ich überlesen:
Geht ja sogar noch einen Schritt weiter bei Dir. 😁
Klamüsern wir mal auf:
-
Vermengst Du Technik und Gesetz. Technisch sinnvoll ist ein Delete-Flag allemale. Wenn es Gesetze gibt, die mir etwas verbieten, halte ich die natürlich ein.
-
Wir reden jetzt hier von Usern, weil Rudi das eingangs erwähnt hat. Da er aber scheinbar noch am Beginn seiner "Datenbankspezialistenkarriere" steht, möchte ich seinen Hozizont dahingehend erweitern, dass ein delete-Flag ihm mehr Optionen bietet. Denn irgendwann löscht er womöglich Daten, die keinen Personenbezug haben. Dann wäre aber ein Delete-Flag sicher angebrachter (von temporären Daten oder Ballast abgesehen)
Ok, dann sind wir einer Meinung. Die rechtlichen Vorschriften sind nämlich so, dass jegliche Datenspeicherung, die keinen Grund hat, untersagt ist.
Wir sind ohnehin im Großen und Ganzen einer Meinung (vom Gendequatsch einmal abgesehen), wobei Du mir bitte noch einen Link zur verfügung stellen magst, wo geschrieben steht, dass ich die Anzahl der Klinker an meinem Haus und die Zahl der Grashalme meines Vorgartens nicht grundlos speichern darf. 😉
Wir sind doch nicht tatsächlich in Deutschland schon soweit, dass auch sowas nun, womöglich aus Klimaschutzgründen, reglementiert wird, oder? 😱
Roy
-
Hallo
… Wir reden jetzt hier von Usern, weil Rudi das eingangs erwähnt hat.
Ok, dann sind wir einer Meinung. Die rechtlichen Vorschriften sind nämlich so, dass jegliche Datenspeicherung, die keinen Grund hat, untersagt ist.
Wir sind ohnehin im Großen und Ganzen einer Meinung (vom Gendequatsch einmal abgesehen), wobei Du mir bitte noch einen Link zur verfügung stellen magst, wo geschrieben steht, dass ich die Anzahl der Klinker an meinem Haus und die Zahl der Grashalme meines Vorgartens nicht grundlos speichern darf. 😉
Erst bestehst du darauf, dass es um Benutzerdaten geht, dann, wenn dir das Argument nicht mehr passt, ziehst du es ins Lächerliche.
Tschö, Auge
--
„Habe ich mir das nur eingebildet, oder kann der kleine Hund wirklich sprechen?“ fragte Schnapper. „Er behauptet, nicht dazu imstande zu sein“ erwiderte Victor. Schnapper zögerte (…) „Nun …“ sagte er schließlich, „ich schätze, er muss es am besten wissen.“ Terry Prattchett, Voll im Bilde-
Hi Auge,
Erst bestehst du darauf, dass es um Benutzerdaten geht, dann, wenn dir das Argument nicht mehr passt, ziehst du es ins Lächerliche.
Erstens stimmt das nicht und zweitens gilt auch für Userdaten nicht, dass ich die nicht grundlos speichern darf.
Es sind nur Daten betroffen, die persönlich sind und auch einer Person tatsächlich zugeordnet werden könen. Alles andere darf ich speichern.
-
Hallo Roy Bär,
"nicht persönliche Userdaten" klingt für mich nach einem weißen Rappen.
Okay, Daten eines Users weiterzuspeichern, wenn der User nicht mehr da ist, kann z.B. für Statistiken einen Sinn ergeben. Sie müssen dann so anonymisiert werden, so dass sie der Person auch dann nicht mehr zugeordnet werden können, wenn die sich nochmal neu registriert. Das sollte okay sein. Aber man muss dann sehr genau schauen, was personenbezogen ist und was nicht, das ist ein Minenfeld.
Rolf
--
sumpsi - posui - obstruxi -
Hallo
Erst bestehst du darauf, dass es um Benutzerdaten geht, dann, wenn dir das Argument nicht mehr passt, ziehst du es ins Lächerliche.
Erstens stimmt das nicht …
Doch. Oder wie kommst du von „Wir reden jetzt hier von Usern“ zu „die Anzahl der Klinker an meinem Haus und die Zahl der Grashalme meines Vorgartens“?
… und zweitens gilt auch für Userdaten nicht, dass ich die nicht grundlos speichern darf.
Es sind nur Daten betroffen, die persönlich sind und auch einer Person tatsächlich zugeordnet werden könen. Alles andere darf ich speichern.
Na dann erkläre mal bitte, welche Daten, die typischerweise in einem Benutzeraccount gespeichert werden, nicht persönlich oder zumindest personenbeziehbar sind. Und erkläre bitte auch, wie du die hypothetischen nicht persönlichen oder personenbeziehbaren Daten behalten willst, ohne illegal persönliche oder personenbeziehbare Daten zu speichern – und sei es nur, um eine Beziehung zwischen den Daten herstellen zu können.
Tschö, Auge
--
„Habe ich mir das nur eingebildet, oder kann der kleine Hund wirklich sprechen?“ fragte Schnapper. „Er behauptet, nicht dazu imstande zu sein“ erwiderte Victor. Schnapper zögerte (…) „Nun …“ sagte er schließlich, „ich schätze, er muss es am besten wissen.“ Terry Prattchett, Voll im Bilde
-
-
-
-
Ok, dann sind wir einer Meinung. Die rechtlichen Vorschriften sind nämlich so, dass jegliche Datenspeicherung, die keinen Grund hat, untersagt ist.
Rolf
Okay. Wie lösche ich also sämtliche zu löschende Daten unseres Kandidaten mit dieser fast schon unheimlichen Namensähnlichkeit am besten?
Query über ALLE Tabellen hinweg, wobei alle Einträge mit entsprechender [Fremd-] ID aufgegriffen und gelöscht werden?
Danke, Rolf Räub ich meine Rudi
-
Hallo Rudi,
schrub ich doch.
Fremdschlüssel und InnoDB (oder eine andere DB als MySQL)
Oder Querys über alle relevanten Tabellen, wenn Dir die Definition von Fremdschlüsseln zu lästig ist, Du InnoDB nicht verwenden willst oder Du generell eine DB betreibst, die keine Fremdschlüssel mit Kaskadierung kennt.
Rolf
--
sumpsi - posui - obstruxi
-
-
-
-
-
Hallo Rudi,
wenn Du eine Person löschst und möchtest, dass alle von ihr abhängigen Einträge in anderen Tabellen automatisch gelöscht werden, benötigst Du Fremdschlüssel (FOREIGN KEY).
In einer von der Person abhängigen Tabelle XY befindet sich typischerweise die Personen-ID. Wenn Du dann für die Tabelle XY definierst, dass die dort gespeicherte Personen-ID ein Fremdschlüssel ist und sich darin die ID aus der Personentabelle befindet (WIE man das tut, hängt vom verwendeten Tool ab), dann kannst Du dem noch hinzufügen, wie sich der Fremdschlüssel bei Änderungen in der Personentabelle verhalten soll. Du hast die Wahl zwischen CASCADE (Löschung der Person löst die Zeile mit dem Fremdschlüssel bzw. Ändern der Personen-ID ändert den Fremdschlüssel automatisch mit), RESTRICT (solange eine Personen-ID als Fremdschlüssel vorkommt, kannst Du die Row nicht löschen oder die Personen-ID ändern) oder SET NULL (Löschen oder Ändern der ID setzt die Einträge, wo sie als Fremdschlüssel vorkommt, auf NULL).
Was Du ohne Fremdschlüssel tust, hast Du richtig erkannt:
Durchsuche ich dann strategisch ALLE Tabellen und lösche...
Nicht alle. Nur die, wo die Personen-ID als Fremdschlüssel vorkommt. Das sind nicht unbedingt alle. Es gibt ja auch Tabellen, deren Inhalt nicht von einer Person abhängt.
Zu Beachten
Kaskadieren von Fremdschlüsseln funktioniert nicht in jeder Datenbank-Engine. Bei MYSQL/MariaDB benötigst Du InnoDB, damit das geht. MyISAM unterstützt das nicht.
Rolf
--
sumpsi - posui - obstruxi
-
-
-
Hi Rudi,
Wenn das KEINE gute Idee ist, wie lassen sich solche komplexen Sachzusammenhänge dann umsetzen?
(Für gewisse zu unterrichtende Fächer gibt es leider verschiedenste Erfordernisse, die auch je nach KundenInnenstamm vollkommen unterschiedlich aussehen können - alternativ fiele mir nur noch ein, für JEDES. EINZELNE. Spezifikum eine eigene Spalte zu kreieren und dann einfach "Ja"/"Nein" als Eintrag zu hinterlegen -- das wäre dann aber eine Tabelle mit locker 100+ [!] Spalten 🤯 )
In Gedensprache gelingt es dir, mehrdimensional zu denken.
Der Sinn dahinter erschließt sich mir nicht.
Wende das mal auf Datenbanken an, dann bist Du der Lösung näher und es ergibt auch einen Sinn.
Eine Datenbank ist nicht Excel, eine Datenbank hat mehr als eine Dimension. Rolf Hat Dir schon das Strichwort "Normalisierung" genannt und genau darauf läuft es hinaus.
Ergo: Weniger gendern, mehr Tabellen. 😜-
Hallo Roy Bär,
mein Minus für themenfremde Seitenhiebe.
Rolf
--
sumpsi - posui - obstruxi
-