wpforge
Goto Top

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.

Content-Key: 398575

Url: https://administrator.de/contentid/398575

Ausgedruckt am: 19.03.2024 um 03:03 Uhr

Mitglied: maretz
maretz 17.01.2019 um 21:34:55 Uhr
Goto Top
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,....
Mitglied: WPFORGE
WPFORGE 17.01.2019 um 21:52:14 Uhr
Goto Top
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.
Mitglied: falscher-sperrstatus
falscher-sperrstatus 17.01.2019 um 22:42:42 Uhr
Goto Top
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
Mitglied: WPFORGE
WPFORGE 17.01.2019 um 23:02:02 Uhr
Goto Top
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
Mitglied: maretz
maretz 18.01.2019 um 04:44:35 Uhr
Goto Top
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.
Mitglied: em-pie
em-pie 18.01.2019 um 07:07:40 Uhr
Goto Top
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
Mitglied: erikro
erikro 18.01.2019 um 08:15:57 Uhr
Goto Top
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
Mitglied: SeaStorm
SeaStorm 18.01.2019 aktualisiert um 08:31:34 Uhr
Goto Top
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
Mitglied: wiesi200
wiesi200 18.01.2019 um 09:03:36 Uhr
Goto Top
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.
Mitglied: ukulele-7
ukulele-7 18.01.2019 um 10:27:16 Uhr
Goto Top
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.
Mitglied: lcer00
lcer00 18.01.2019 um 10:51:46 Uhr
Goto Top
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
Mitglied: ukulele-7
ukulele-7 18.01.2019 um 13:34:40 Uhr
Goto Top
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.