mysql: die effizienteste Methode, um Parameter mit unbekanntem Typ (string/int) in der Datenbank zu speichern

Question

Ich habe ein Nachrichtensystem, das Standardvorlagen enthält. Zum Beispiel:

you won X coins

friend X wants to share the url Y with you

so ändert sich die Anzahl der Parameter in jeder Nachricht/Templat-Typ.

Ich dachte, von 4 Arten von Lösungen das Problem zu beheben:

1. eine Parameter-Tabelle erstellen und die einzelnen Parameter Typen als String darstellen. Das Problem hier, dass user_ids als Zeichenfolgen dargestellt werden, so dass Joins wahrscheinlich langsamer sein werden. e

2. Erstellen einer Parametertabelle, die jede Zeile enthält eine Boolean, die angibt, ob der Parameter ein int oder eine Zeichenfolge ist, und 2 andere Spalten ein Typ Text und der andere Typ INT. Hier verschwenden wir also Platz, denn wenn wir einen int-Parameter verwenden, enthält die Zeile eine nicht verwendete String-Zelle.

3. Um überhaupt keine Parametertabelle zu erstellen, enthält jede Benachrichtigung eine Parameterzeichenfolge, die jeden benötigten Parameter mit einem Trennzeichen ; enthält. dieser kann die langsamste Lösung sein.

4. Erstellen von zwei verschiedenen Tabellen für jede Zeit von Parametern: notification_param_int und notification_param_string und eine Tabelle, die jeden Parameter in der Benachrichtigung an die relevante Tabelle enthält. Diese Lösung ist möglicherweise langsamer als die Lösung 2, weil ich zuerst prüfen muss, von welcher Tabelle die Informationen abgerufen werden sollen.

Gibt es noch andere Optionen, an die ich nicht gedacht habe? Wenn mir der Platz egal ist, nur über Geschwindigkeit, welche Methode sollte ich nehmen?

Ich bin kein MySQL-Experte, daher kann die Schlussfolgerung jeder Methode falsch sein.

Alle Informationen würden sehr geschätzt werden.

danke!

Answer 1

Wenn Sie eine offene Eigenschaftstabelle haben, werden Sie feststellen, dass einige der Eigenschaften wichtiger sind (entweder müssen sie immer da sein, oder sie müssen schnell sein). In diesem Fall werben Sie diese Felder im Hauptdatensatz hoch.

Ich könnte mir vorstellen, dass UID das ist. Es wäre später ein Problem, wenn Sie eine Liste von UID (Freunden) haben müssten, aber dann könnten Sie auch Freunde für eine eigene Tabelle werben.

In Ihrem Fall würde ich mich einfach für # 1 oder # 2 entscheiden und darüber nachdenken, wichtige Eigenschaften zu fördern, wenn sich die Notwendigkeit ergibt.