12
Aufbau einer MYSQL Datenbank
Hallo,
Ich habe etwa 1 mio Datensätze.
Mit ekelhaft vielen Feldern (ca. 120).
Je nach Kategorie des Datensatzes weichen diese Felder auch leicht von einander ab.
Anstatt nun eine Tabelle mit unendlich vielen Spalten zu zimmern scheint die Möglichkeit, das über zwei Tabellen zu tun verführerisch
Tabelle 1
id , created_at
Tabelle 2
table1_id , key , value
Wobei value ein LONGTEXT wäre und alle möglichen Feldinhalte damit abdecken würde.
Die Menge der Abfragen wird sich wohl in engen Grenzen (<1000 /Tag) halten.
Sieht jemand einen Grund, warum die Idee dumm sein könnte?
Danke schonmal für eure Antworten.
Ich habe etwa 1 mio Datensätze.
Mit ekelhaft vielen Feldern (ca. 120).
Je nach Kategorie des Datensatzes weichen diese Felder auch leicht von einander ab.
Anstatt nun eine Tabelle mit unendlich vielen Spalten zu zimmern scheint die Möglichkeit, das über zwei Tabellen zu tun verführerisch
Tabelle 1
id , created_at
Tabelle 2
table1_id , key , value
Wobei value ein LONGTEXT wäre und alle möglichen Feldinhalte damit abdecken würde.
Die Menge der Abfragen wird sich wohl in engen Grenzen (<1000 /Tag) halten.
Sieht jemand einen Grund, warum die Idee dumm sein könnte?
Danke schonmal für eure Antworten.
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 398575
Url: https://administrator.de/contentid/398575
Ausgedruckt am: 25.11.2024 um 04:11 Uhr
12 Kommentare
Neuester Kommentar
Moin, wie soll man das ohne deine Anforderungen sagen? Du hast jetzt diverse Felder -> ok, was ist da drin, lässt sich das kombinieren? Ganz davon abgesehen ist es eigentlich egal wieviele Felder du hast - da du das ja auch beliebig in der Anwendung kombinieren kannst...
Das könnte z.B. dumm sein wenn du auf die einzelnen Felder schreiben willst, wenn du ne Applikation bereits hast die auf die Felder verweisen möchte,....
Das könnte z.B. dumm sein wenn du auf die einzelnen Felder schreiben willst, wenn du ne Applikation bereits hast die auf die Felder verweisen möchte,....
Es gibt noch keine Applikation dazu.
Die Felder, die da reingeschrieben werden, liegen alle als String vor.
Ggf. Wären wohl etliche Felder als INT, FLOAT oder BOOL (was hier wohl 0,1 wäre) klassifizierbar.
Aber die Felder mit gleichem key sind dann auch einheitliche Datentypen.
Und so wie ich das sehe kann ja auch in einem Longtext ein Zahlenvergleich (> als, <als) durchgeührt werden.
Die Felder, die da reingeschrieben werden, liegen alle als String vor.
Ggf. Wären wohl etliche Felder als INT, FLOAT oder BOOL (was hier wohl 0,1 wäre) klassifizierbar.
Aber die Felder mit gleichem key sind dann auch einheitliche Datentypen.
Und so wie ich das sehe kann ja auch in einem Longtext ein Zahlenvergleich (> als, <als) durchgeührt werden.
Sieht jemand einen Grund, warum die Idee dumm sein könnte?
Ohne Tabelle/Hintergründe können wir wenig dazu sagen, also das primär dumme ist die Erwartung einer technisch korrekten Antwort ohne einen groben Überblick des Sachverhalts/Nutzzwecks.
VG
Also ich habe etwa 1 mio Objekte.
Diese haben ca 100 Attribute.
Die Objekte lassen sich grundsätzlich in 4 Kategorien aufteilen. Wobei sich die Attribute der Objekte leicht unterscheiden.
Damit kommen wir auf insgesamt etwa 120 mögliche Attribute.
Die Attribute können alle im Datentyp String dargestellt werden.
Der Datentyp pro Attribut ist für alle Objekte gleich.
Die Überlegung ist nun anstatt 1 Tabelle pro Kategorie mit jeweils etwa 100 Spalten zu erstellen, 2 Tabellen zu erstellen:
objects:
id (BIGINT)
type (VARCHAR 255) Kategorie des Objekts
created_at(DATE) eingetragen am
attributes
id(BIGINT)
object_id (BIGINT)
object_key (VARCHAR255) Feldbezeichnung
object_value (LONGTEXT) Feldwert
etliche der Felder könnten auch als INTEGER, FLOAT oder BOOL erfasst werden.
Nachdem aber soweit ich weiß auch der Longtext hier quantitative Vergleiche erlaubt, wäre die Frage ob es Sinn macht die Daten so zu speichern.
Vom erfassen der Daten her wäre das sehr viel praktischer.
Mir fehlt hier die Abschätzung, wie groß der Unterscheid für den DB Server ist, wenn man eine 1mio Zeilen mit 100 Spalten hat oder 100mio Zeilen mit 4 Spalten. Auch wenn schlussendlich das Gleiche drinsteht.
Zur veranschaulichung könnte man sich hier eine Immobilie mit ihren Attributen vorstellen.
Die Abfrage wäre nachher nach dem Motto zu gestalten:
Finde Alle Immobilien mit feld1 zwischen X und Y UND feld2 zwischen A und B
Diese haben ca 100 Attribute.
Die Objekte lassen sich grundsätzlich in 4 Kategorien aufteilen. Wobei sich die Attribute der Objekte leicht unterscheiden.
Damit kommen wir auf insgesamt etwa 120 mögliche Attribute.
Die Attribute können alle im Datentyp String dargestellt werden.
Der Datentyp pro Attribut ist für alle Objekte gleich.
Die Überlegung ist nun anstatt 1 Tabelle pro Kategorie mit jeweils etwa 100 Spalten zu erstellen, 2 Tabellen zu erstellen:
objects:
id (BIGINT)
type (VARCHAR 255) Kategorie des Objekts
created_at(DATE) eingetragen am
attributes
id(BIGINT)
object_id (BIGINT)
object_key (VARCHAR255) Feldbezeichnung
object_value (LONGTEXT) Feldwert
etliche der Felder könnten auch als INTEGER, FLOAT oder BOOL erfasst werden.
Nachdem aber soweit ich weiß auch der Longtext hier quantitative Vergleiche erlaubt, wäre die Frage ob es Sinn macht die Daten so zu speichern.
Vom erfassen der Daten her wäre das sehr viel praktischer.
Mir fehlt hier die Abschätzung, wie groß der Unterscheid für den DB Server ist, wenn man eine 1mio Zeilen mit 100 Spalten hat oder 100mio Zeilen mit 4 Spalten. Auch wenn schlussendlich das Gleiche drinsteht.
Zur veranschaulichung könnte man sich hier eine Immobilie mit ihren Attributen vorstellen.
Die Abfrage wäre nachher nach dem Motto zu gestalten:
Finde Alle Immobilien mit feld1 zwischen X und Y UND feld2 zwischen A und B
Ok - also mit technisch kommen wir hier scheinbar nicht weiter. Versuchen wir es mal anders.
Erstmal - dein MySQL kann nicht Zaubern, Hexen oder sonst was. Schwarze Magie ist in der Informatik zwar oft unterstellt, aber wenig verbreitet.
Jetzt kannst du dir ja mal einfach die Frage stellen: Was geht schneller: Du hast nen Aktenschrank mit sagen wir 100 Ordnern, jeder davon hat 100.000 Blätter drin. Oder du hast eben 100.000 Ordner, jeder hat aber nur 100 Blätter drin. Wo findest du schneller eine Information. Und die Antwort ist ein eindeutiges "Hängt davon ab".
Ist nämlich die Information die du suchst leider so umfangreich das es normalerweise mind. 500 Blätter füllt dann kannst du natürlich im ersten Fall mit EINER Suche gleich alle Informationen rausholen. Du stehst also genau einmal auf, bewegst dich zum Schrank, holst den Ordner und hast alles was du brauchst. Im zweiten Fall musst du min. 5x zum Schrank gehen und auch jedes mal noch schauen ob nicht auf der letzten der 100 Seiten steht "Fortsetzung auf Ordner xyz".
Ist aber die Information eben nur _irgendwo_ EIN Blatt Papier in einem Ordner und du hast ein vernünftiges Archiv-System dann kann das zweite besser sein. Denn du brauchst jetzt eben nicht den dicken Ordner zu nehmen und erst mal 100.000 Seiten zum Schreibtisch übertragen - sondern nur den kleinen mit 100 Seiten.
Das ganze hängt jetzt also davon ab wie weit dein Schreibtisch vom Schrank weg ist. Ausserdem davon wie deine Informationen sortiert sind - hast du z.B. den Ordner mit 100.000 Blättern einfach nur "Fängt mit A an" genannt, deine 100 Blätter-Ordner jedoch z.B. "AA, AB, AC" kann die Suche effektiver sein - nur wenn du dann ALLES mit A willst dann rennst du dir halt die Füsse wund.
Du kannst jetzt also mit deinen Object-IDs um dich werfen usw... Nur: NUR DU kennst die Daten die du hast und das Ziel was du verfolgst. Eine generelle Aussage kann man da halt eher nicht treffen.
Erstmal - dein MySQL kann nicht Zaubern, Hexen oder sonst was. Schwarze Magie ist in der Informatik zwar oft unterstellt, aber wenig verbreitet.
Jetzt kannst du dir ja mal einfach die Frage stellen: Was geht schneller: Du hast nen Aktenschrank mit sagen wir 100 Ordnern, jeder davon hat 100.000 Blätter drin. Oder du hast eben 100.000 Ordner, jeder hat aber nur 100 Blätter drin. Wo findest du schneller eine Information. Und die Antwort ist ein eindeutiges "Hängt davon ab".
Ist nämlich die Information die du suchst leider so umfangreich das es normalerweise mind. 500 Blätter füllt dann kannst du natürlich im ersten Fall mit EINER Suche gleich alle Informationen rausholen. Du stehst also genau einmal auf, bewegst dich zum Schrank, holst den Ordner und hast alles was du brauchst. Im zweiten Fall musst du min. 5x zum Schrank gehen und auch jedes mal noch schauen ob nicht auf der letzten der 100 Seiten steht "Fortsetzung auf Ordner xyz".
Ist aber die Information eben nur _irgendwo_ EIN Blatt Papier in einem Ordner und du hast ein vernünftiges Archiv-System dann kann das zweite besser sein. Denn du brauchst jetzt eben nicht den dicken Ordner zu nehmen und erst mal 100.000 Seiten zum Schreibtisch übertragen - sondern nur den kleinen mit 100 Seiten.
Das ganze hängt jetzt also davon ab wie weit dein Schreibtisch vom Schrank weg ist. Ausserdem davon wie deine Informationen sortiert sind - hast du z.B. den Ordner mit 100.000 Blättern einfach nur "Fängt mit A an" genannt, deine 100 Blätter-Ordner jedoch z.B. "AA, AB, AC" kann die Suche effektiver sein - nur wenn du dann ALLES mit A willst dann rennst du dir halt die Füsse wund.
Du kannst jetzt also mit deinen Object-IDs um dich werfen usw... Nur: NUR DU kennst die Daten die du hast und das Ziel was du verfolgst. Eine generelle Aussage kann man da halt eher nicht treffen.
Moin,
Da schreit - ohne die Inhalte zu kennen - fast nach Normalisieren.
Gibt es in den Attributen werte, die immer in der gleichen Kombination vorkommen, z.B. Anschriften von Personen?
Wenn ja, lagere die z.B. aus und referenziere dann darauf. Du musst die Adresse ja nicht 800mal redundant mitschleppen.
Außer, es sind zB. Rechnungsdaten. Dann müssten die ja auch erhalten bleiben, selbst wenn später die Adresse geändert wird.
Hängt also, wie o.g. Immer vom Anwendungsfall ab.
Gruß
em-pie
Da schreit - ohne die Inhalte zu kennen - fast nach Normalisieren.
Gibt es in den Attributen werte, die immer in der gleichen Kombination vorkommen, z.B. Anschriften von Personen?
Wenn ja, lagere die z.B. aus und referenziere dann darauf. Du musst die Adresse ja nicht 800mal redundant mitschleppen.
Außer, es sind zB. Rechnungsdaten. Dann müssten die ja auch erhalten bleiben, selbst wenn später die Adresse geändert wird.
Hängt also, wie o.g. Immer vom Anwendungsfall ab.
Gruß
em-pie
Moin,
lies mal das hier:
https://de.wikipedia.org/wiki/Normalisierung_(Datenbank)
Dann weißt Du, warum Deine Idee im Prinzip richtig, aber noch nicht zuende gedacht ist.
hth
Erik
lies mal das hier:
https://de.wikipedia.org/wiki/Normalisierung_(Datenbank)
Dann weißt Du, warum Deine Idee im Prinzip richtig, aber noch nicht zuende gedacht ist.
hth
Erik
Hi
das kommt ganz darauf an wie du die Daten abrufst. Ohne Hintergründe, was das für Daten sind und wie diese Daten verwendet werden, kann man da keine qualifizierte Aussage tätigen.
Es gibt Gründe zu normalisieren, es gibt aber auch gründe sowas flach zu lassen.
Also: Tu mal nicht so vage und erzähl uns um was es geht
das kommt ganz darauf an wie du die Daten abrufst. Ohne Hintergründe, was das für Daten sind und wie diese Daten verwendet werden, kann man da keine qualifizierte Aussage tätigen.
Es gibt Gründe zu normalisieren, es gibt aber auch gründe sowas flach zu lassen.
Also: Tu mal nicht so vage und erzähl uns um was es geht
Hallo,
je nach dem wie die "ekelhaft viele" Felder verwendet werden, könnte man diese auch in eine XML Struktur, innerhalb einer SQL Spalte packen.
Wenn du diese jedoch für Abfrage benötigst wird's dann schnell blöd.
Sprich das geht nur für sehr wenig einsatzzwecke.
je nach dem wie die "ekelhaft viele" Felder verwendet werden, könnte man diese auch in eine XML Struktur, innerhalb einer SQL Spalte packen.
Wenn du diese jedoch für Abfrage benötigst wird's dann schnell blöd.
Sprich das geht nur für sehr wenig einsatzzwecke.
Also was dir im Kopf rum schwebt nennt sich EAV, damit wir das ganze erstmal beim Namen nennen:
https://en.wikipedia.org/wiki/Entity%E2%80%93attribute%E2%80%93value_mod ...
Es ist nicht unüblich oder dumm und kann durchaus sinnvoll sein, unser DMS nutzt das z.B.. Aber der Anwendungsfall ist tatsächlich wichtig. Wenn zu deinen vier verschiedenen Typen, ich würde jetzt sagen Entitäten, keine weiteren dazu kommen, dann würde ich vermutlich ganz darauf verzichten. Wenn die Anzahl der Entitäten variirt dann würde ich dazu raten.
Also Beispiel:
Du bildest Fahrzeuge ab. Es gibt vier Entitäten die alle Fahrzeuge sind (PKW, LKW, Krafträder und Flugzeuge). Da kann natürlich jederzeit was dazu kommen also würde ich das auf jeden Fall mit EAV machen.
Es empfiehlt sich natürlich (wie em-pie schon formuliert hat) Attribute, die immer gegeben sind in die Haupttabelle zu packen. Alles was du im EAV führst hat Nachteile. Datentypen und Constraints sind nur eingeschränkt umsetzbar (gut, MySQL ist auch nur eingeschränkt nutzbar aber das ist ein anderes leidiges Thema). Das kann sich auf deine Datenqualität und auf die Geschwindigkeit auswirken, wenn auch nicht merkbar bei so wenig Datensätzen (okay, MySQL ist hier auch ein Risiko). Die Querys werden auch umfangreicher.
Alternativen aus DB sicht wären XML Spalten. Das taugt wirklich nur gut wenn man darin nicht suchen muss, ansonsten ist es wirklich nervig zu schreiben. Zur Umsetzung in MySQL kann ich nichts sagen, mit MSSQL geht das eigentlich brauchbar schnell.
Unter Postgre gibt es JSON Datentypen. Die bieten viele Vorteile in Sachen Funktionen und Geschwindigkeit. Ich hatte noch nicht das Vergnügen aber für ein neues Projekt würde ich es sofort empfehlen.
https://en.wikipedia.org/wiki/Entity%E2%80%93attribute%E2%80%93value_mod ...
Es ist nicht unüblich oder dumm und kann durchaus sinnvoll sein, unser DMS nutzt das z.B.. Aber der Anwendungsfall ist tatsächlich wichtig. Wenn zu deinen vier verschiedenen Typen, ich würde jetzt sagen Entitäten, keine weiteren dazu kommen, dann würde ich vermutlich ganz darauf verzichten. Wenn die Anzahl der Entitäten variirt dann würde ich dazu raten.
Also Beispiel:
Du bildest Fahrzeuge ab. Es gibt vier Entitäten die alle Fahrzeuge sind (PKW, LKW, Krafträder und Flugzeuge). Da kann natürlich jederzeit was dazu kommen also würde ich das auf jeden Fall mit EAV machen.
Es empfiehlt sich natürlich (wie em-pie schon formuliert hat) Attribute, die immer gegeben sind in die Haupttabelle zu packen. Alles was du im EAV führst hat Nachteile. Datentypen und Constraints sind nur eingeschränkt umsetzbar (gut, MySQL ist auch nur eingeschränkt nutzbar aber das ist ein anderes leidiges Thema). Das kann sich auf deine Datenqualität und auf die Geschwindigkeit auswirken, wenn auch nicht merkbar bei so wenig Datensätzen (okay, MySQL ist hier auch ein Risiko). Die Querys werden auch umfangreicher.
Alternativen aus DB sicht wären XML Spalten. Das taugt wirklich nur gut wenn man darin nicht suchen muss, ansonsten ist es wirklich nervig zu schreiben. Zur Umsetzung in MySQL kann ich nichts sagen, mit MSSQL geht das eigentlich brauchbar schnell.
Unter Postgre gibt es JSON Datentypen. Die bieten viele Vorteile in Sachen Funktionen und Geschwindigkeit. Ich hatte noch nicht das Vergnügen aber für ein neues Projekt würde ich es sofort empfehlen.
Hallo,
also so beim lesen...
Teste das am besten. Schritt 1, Du konvertierst Deine Daten in das von Dir gewünschte Format. Dann simuliere ein paar praxisrelevante Datenbankabfragen für Variante 1 und 2. Vermutlich wirst Du sehr schnell herausbekommen, wo die Probleme liegen und welche Variante besser geeignet ist.
Es gibt auch andere Datenbankmodelle ausser mysql. Vielleicht wäre ja Elasicsearch was für Dich?
OFF-Topic: wir reden hier aber nicht über diese Daten?
Grüße
lcer
also so beim lesen...
Teste das am besten. Schritt 1, Du konvertierst Deine Daten in das von Dir gewünschte Format. Dann simuliere ein paar praxisrelevante Datenbankabfragen für Variante 1 und 2. Vermutlich wirst Du sehr schnell herausbekommen, wo die Probleme liegen und welche Variante besser geeignet ist.
Es gibt auch andere Datenbankmodelle ausser mysql. Vielleicht wäre ja Elasicsearch was für Dich?
OFF-Topic: wir reden hier aber nicht über diese Daten?
Grüße
lcer
Er redet von 1Mio Datensätze, nicht 1Mrd.
MySQL ist auch kein Datenmodell sondern eben relationale Datenbanken allgemein und SQL im speziellen. Elastic Search verwendet JSON, wie oben schon erwähnt kann man JSON mit Postgre SQL nutzen und das innerhalb der SQL Syntax aufrufen.
MySQL ist auch kein Datenmodell sondern eben relationale Datenbanken allgemein und SQL im speziellen. Elastic Search verwendet JSON, wie oben schon erwähnt kann man JSON mit Postgre SQL nutzen und das innerhalb der SQL Syntax aufrufen.
