In einem vergangenen Projekt hatte ich das aufgeteilt... da gab es dann "usersettings", "users", "userdata", und und und. Aber ich glaube, in einer Tabelle wäre es einfacher. Oder spricht was dagegen?
Kommt wohl drauf an. Daten, die nur einmal vorkommen sollte man meiner Meinung nach durchaus beisammen halten, wenn man solche Tabellen trennt riskiert man imho dass irgendwann irgendwas durcheinander gerät.
Du schriebst etwas von "über Neuigkeiten benachrichtigen" also ein Newsletter oder soetwas ähnliches wie ein Newsfeed. Wenn die Benutzer nur "Benachrichtigen über Neuigkeiten" auswählen können oder eben nicht, dann kann und sollte man das meiner Meinung nach durchaus in einer Tabelle halten.
Wenn aber sagen wir Kategorien oder "Tags" existieren, dann könnte also ein Benutzer anwählen er möchte über Neuigkeiten benachrichtigt werden aber nur wenn sie in die Kategorien A B oder K fallen. Die Neuigkeiten über C bis J interessieren ihn nicht.
In dem Falle macht es dann gar keinen Sinn mehr das in einer User-Tabelle zu halten, denn entweder man macht 10 Felder (Benachrichtigen_A [Boolean}, Benachrichtigen_B [Boolean], (...) Benachrichtigen_F [bool], Benach....) oder man macht ein Sammelfeld (Benachrichtigen VarChar[10] in dem dann die gewünschten Buchstaben stehen).
Beide Varianten sind Speicherfressend und unflexibel (hui eine Kategorie mehr und gleich alles umschreiben).
In einem solchen Fall dann lieber eine eigene Benachrichtigungen-Tabelle, die dann in User und in Kategorien linkt.
Aber wie gesagt, wenn es nur ein Feld pro User ist und du sicher bist dass das auch so bleibt, dann würde ich das in der User-Tabelle behalten und nicht in X einzelne aufteilen.
sh:( fo:| ch:? rl:( br:& n4:& ie:{ mo:} va:) de:µ_de:] zu:) fl:( ss:| ls:[ js:(