Estou montando um projeto básico de banco de dados SQL e não sei como segmentar as informações sobre os usuários.
(Observe antes de entrar em qualquer coisa, as senhas armazenadas são salgadas e com hash, apenas escrevo "senha" para brevidade)
Por motivos que não posso abordar devido ao NDA, nosso banco de dados terá dois grupos de usuários - usuários humanos e usuários falsos. Os usuários humanos terão informações de login ( nome de tela, endereço de e-mail, senha ). Usuários falsos só precisam de um nome de tela. Todos os usuários, humanos e falsos, precisam de informações de perfil ( nome, sobrenome, gênero, localização, etc ). A maioria das informações de perfil é exibida apenas na página de perfil do usuário. No entanto, dependendo das configurações do usuário, seu nome real ou nome de tela pode ser exibido sob seu avatar em todo o front-end. O endereço de e-mail não está visível no perfil público do usuário.
Não consigo decidir como segmentar essas informações em tabelas. Meu primeiro instinto foi ter três tabelas separadas,
" contas " (para humanos - nome de tela, e-mail e senha)
" user_profiles " (primeiro nome, sobrenome, gênero, localização, etc)
" fake_user_profiles " (nome de tela, nome, sobrenome, gênero, localização, etc).
Mas isso esbarra em vários problemas:
- Cada usuário, humano ou falso, precisa de um ID exclusivo - nenhum ser humano deve ter o mesmo ID de qualquer usuário falso. Eu teria que impor UIDs em duas tabelas separadas
- Tenho duas tabelas quase idênticas com apenas um campo diferente entre elas
Minha próxima ideia foi juntar todos os usuários, humanos ou falsos. Então eu teria duas tabelas:
- " contas " (nome de tela, e-mail, senha)
- " perfis " (primeiro nome, sobrenome, sexo, localização, is_human, etc)
Com essa abordagem, faria sentido colocar o UID de cada usuário (humano ou falso) na tabela "contas". Mas o que eu faria com os campos "email" e "senha" que deveriam ser não nulos para humanos, mas não servem para usuários falsos?
Haveria uma abordagem melhor do que qualquer uma das duas que descrevi? Seria melhor colocar todas as informações em uma tabela?
A menos que haja um problema de segurança (você quer que alguém visualize algumas informações, mas não outras), não há necessidade; no entanto, em muitas plataformas sql, você pode negar o acesso a campos específicos de segurança ou apenas criar uma exibição. O único outro motivo pelo qual você deseja ter duas tabelas é se tiver um motivo comercial para segregar os dados em duas tabelas separadas. Caso contrário, se você precisar constantemente obter informações da tabela A e da tabela B ao mesmo tempo, precisará ingressar todas as vezes, o que aumentará a sobrecarga.