Eléments négatifs ? Non je ne peuse pas.

Toujours est-il qu'il faut bien gérer le lien (clés étrangères) entre les tables pour pouvoir utiliser correctement la base de données plus tard et ne pas la corrompre avec des données qui ne sont rattachées à rien du tout.

Plus ta base est décomposées plus elle te permet d'etre maléable et adaptable par la suite si tu veux ajouter des modules à tes programmes et qui demandent certaines fonctionnalités en plus que celles existante.
Mais le but n'est pas non plus de fragmenter le plus possible sa base de données (donc le MCD) parce que cela implique qu'elle devient plus complexe à gérér, et point de vue code, plus complexe sera l'application qui utilise la base de données, plus complexe seront les requêtes SQL générée, et parfois même, le temps d'acces aux données en sera plus long.

C'est pour cela qu'il faut réfléchir à l'avance aux fonctionnalités de l'application qui repose sur la base de données, afin d'avoir une base la plus adaptables et la plus rapide à la fois.

Dans ton cas, si tu laisse par exemple 'status' en tant que propriété, tu aura de la redondance dans tes tables, mais vu que tu ne t'en servira que pour effectuer des requêtes de sélection pour connaitre les connectés et les non connectés, il faut que tu laisse cela en tems que propriété.
Si tu en fais une table, tu n'aura que deux valeurs dedans, qui ne te serviront pas à grands choses au final et compliquera tes requetes sur la base.
Pour ce qui est du 'type' par contre... à voir selon les fonctionnalités de ton application.