DB Design für große Menge User-Daten

[James.R.]

Hallo..
Ich hoffe das ich in diesem Forum richtig bin - oder gehört es doch in ein Android Forum? Wir werden es sehen

Zu meiner Frage..
Ich entwickel zur Zeit eine App für Android Mobilgeräte (weiteres für diese Frage ohne Bedeutung).
Als Server nutze ich einen Linux Server mit nutzbarer MySQL Datenbank.

Was möchte ich speichern?
Speichern möchte ich zumal die sich registrierenden User (realisierung ist klar) und eine riesen Menge User-Daten.

Die User-Daten bestehen aus täglichen Einträgen (kann man sich vorstellen wie eine Art Tagebuch. Siehe auch Ernährungstagebuch wie die App “Lifesum“ o.ä.).
Eingetragen werden pro Tag verschiedenste Lebensmittel aus einer vorhandenen Lebensmitteldatenbank (das was man am jeweiligen Tag halt ist).

D.h. also ich habe große Mengen Datensätze für jeden User.
Ist es nun sinnvoller für jeden User eine eigene Tabelle zu nutzen damit eine einzelne Tabelle für alle User nicht zu groß wird? Oder liegt das Problem eher dabei, dass ich meine Daten auf eine andere Weise sichern sollte.. z.B. in Files auf einem Server.

Zu mir: Ich kann grundsätzlich mit SQL umgehen.. kenne aber manche “Kniffe“ nicht.



Vielen Dank!

 

[ukulele]

Also eine Tabelle pro User ist ganz ganz ganz großer Blödsinn, deine Kenntnisse scheinen nicht so grundsätzlich zu sein wie du an nimmst.

Selbst MySQL kann mit großen Datenmengen sinnvoll umgehen. Ich bin aber skeptisch was die Menge angeht. Entweder du hast ein grundlegendes Problem weil dein einer Linux DB Server nicht reichen wird um viele tausend User zu versorgen, du brauchst also ein DB Cluster. Oder wir haben ein unterschiedliches Verständnis von "großen" Datenbanken, so ein paar Millionen Datensätze ist nicht das Thema.

Ich rate dir in jedem Fall wenn du auf viele User skalieren willst gleich PostgreSQL anstelle von MySQL zu verwenden, da hast du wenigstens später Optionen. Und natürlich eine Tabelle für eine Entität.

 

[akretschmer]

ACK. Eine Tabelle, aber natürlich die DB normalisiert. Und ja, PostgreSQL wäre wirklich die bessere Wahl.

 

[akretschmer]

Über was für Datenmengen reden wir? 1 Million Records? 10, 100? 10 Milliarden? Dann wird es langsam interessant. Wie sehen die typischen Zugriffsmuster aus? Da wird dann die Indexstrategie wichtig. Für Daten wie z.B. Logdaten, die quasi in einer natürlichen Sortierung anfallen (hier die Zeit) und wirklich großen Datenmengen, bei denen das Datum mit Bstandteil des Where ist, böten sich z.B. BRIN-Indexe an. (Block Range INdex). Sehr, sehr klein und wahnsinnig effizient.