Filozofie tvorby tabulek

Mám tabulku uživatelů obsahující snadno představitelné sloupce: user_id, name, email, created_time, password, state, face_img, ...

Uživatel se může nacházet v několika stavech (sloupec state):

opened_nc - účet otevřen, ale není zkonfirmovaný email
open - účet otevřen - 95% uživatelů je v tomto stavu
deactivated - účet deaktivován
deleted - účet smazán (čeká na kompletní odstranění všeho, co uživatel spáchal za celý svůj život)

Každý stav vyžaduje nějaký jiný přístup/činnosti/operace.
Např. ve stavu opened_nc chci uživatele opakovaně informovat, že účet nezkonfirmoval. To si žádá uložení dalších informací (kdy jsem ho naposled informoval, kolikrát jsem ho již informoval, ...).

A tím se dostávám k otázce. Jak to udělat?

Verze 1: Přidat do tabulky uživatelů sloupce smysluplné jen s tím jedním stavem. Případně přidat index potřebný pro práci jen s tím jedním stavem.

Verze 2: Vytvořit pomocnou tabulku users_opened_nc, zachycující všechny uživatele v tomto stavu.

Verze 3: Vytvořit pomocnou tabulku users_no_opened, která pokryje všechny stavy mimo stav opened.

Verze 4: ???

Jistě budou "fungovat" všechny verze, ale která verze je ta korektní z hlediska DB.

Kajman:
„Kolik tam bude řádků?“
Teď je všech řádků 3mil, ale těch ve stavu opened_nc jen 2tis.

„Přijde mi divné dávat last_notice, notice_count do nové tabulky. Vždyť všem uživatelům se přeci bude posílat žádost o potvrzení. Aby byli open, deactivated nebo deleted musí projít stavem opened_nc.“
Mně zase přijde divné "špinit tabulku" sloupci a indexy, které aktuálně využije 0,06% řádků. Ale možná se na to dívám jen špatně.

anonym:
„Přesouvání uživatelů mezi tabulkami tak, jak jsi to navrhoval ty, je nesmysl“
Přesouvat uživatele mezi tabulkami jsem neměl v plánu. Pouze uživatelé, kteří jsou ve stavu opened_nc mají po dobu pobytu v tomto stavu pomocné informace v druhé tabulce. Ať už se ta tabulka jmenuje users_opened_nc nebo acc_confirmations.