======================================== 0.1) USUÁRIOS ======================================== Tabela: tb_usuario Status: AJUSTAR (levemente) Campos essenciais do MVP: - id_usuario | INT, PK, AUTO_INCREMENT - nome | VARCHAR(150) - email | VARCHAR(150), UNIQUE - telefone | VARCHAR(20) - senha_hash | VARCHAR(255) - role | ENUM('dev','admin','func') - ativo | TINYINT(1) DEFAULT 1 - remember_token | VARCHAR(512) NULL - ultimo_login | DATETIME NULL - criado_em | DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP Campos legados não essenciais (removidos do MVP): - imagem (não é funcional para o SaaS) - nivel (substituído por 'role') - id_funcao (pertence ao sistema antigo) - setor (não faz sentido para usuários do SaaS) Observações: - 'senha' do legado se torna 'senha_hash' - 'role' define permissões: dev/admin/func ======================================== 0.2) CLIENTES (EMPRESAS) ======================================== Tabela: tb_empresas Status: AJUSTAR (moderado) Objetivo no SaaS: - Representar o cliente do SaaS (tenant) e seus dados básicos. - Ser a “raiz” para amarrar tudo: usuários, cobranças, módulos, permissões, etc. Campos essenciais do MVP (recomendado) - id_empresa | INT, PK, AUTO_INCREMENT - empresa | VARCHAR(150) (nome interno/identificação) - slug | VARCHAR(150), UNIQUE (url/identificador amigável) - tipo_cliente | ENUM('pf','pj') (ou TINYINT com tabela/enum) - nome | VARCHAR(150) (nome do responsável ou razão social, depende do tipo) - cpf | VARCHAR(14) NULL (se PF) - cnpj | VARCHAR(18) NULL, UNIQUE (se PJ) - email | VARCHAR(150) (principal) - telefone | VARCHAR(20) NULL - cep | VARCHAR(10) NULL - cidade | VARCHAR(100) NULL - estado | CHAR(2) NULL - endereco | VARCHAR(180) NULL - numero | VARCHAR(20) NULL - bairro | VARCHAR(100) NULL - complemento | VARCHAR(100) NULL - segmento | VARCHAR(80) NULL - ativo | TINYINT(1) DEFAULT 1 - criado_em | DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP Por que isso é o MVP real: com isso você já consegue cadastrar tenant, logar usuários vinculados, e futuramente cobrar/ativar módulos. Campos úteis, mas opcionais (pode ficar para “MVP+”) - telefone_2 | VARCHAR(20) NULL - email_2 | VARCHAR(150) NULL - contato | VARCHAR(150) NULL (nome do contato principal) - cargo | VARCHAR(80) NULL - obs | TEXT NULL - fantasia | VARCHAR(150) NULL - abertura | DATE NULL (abertura da empresa) - ie | VARCHAR(30) NULL - ie_isento | TINYINT(1) DEFAULT 0 Campos legados / não essenciais (eu colocaria como “avaliar/remover”) - rg (muito específico / LGPD sensível; só se você realmente precisar) - especifico / especifico_2 (campo “coringa” vira bagunça; melhor virar tabela de campos extras depois) - nascimento (PF até vai, mas no SaaS eu evitaria no começo) - idade (derivado, não armazenar; calcula na hora se precisar) - data_cadastro (substituir por criado_em e atualizado_em, padrão do sistema) Observações / ajustes recomendados - Padronizar nomes: se hoje é id, no SaaS fica melhor id_empresa (como fizemos id_usuario). - slug: manter único porque vira a “assinatura” do tenant (url, subdomínio, etc.). - PF/PJ: em vez de obrigar tudo junto, deixe cpf/cnpj null e valide conforme tipo_cliente. - Evitar “idade”: sempre derive de nascimento. - Criar atualizado_em (quando você estiver pronto): DATETIME NULL ON UPDATE CURRENT_TIMESTAMP (ou controlado no código). ======================================== 0.3) USUÁRIO ↔ EMPRESA ======================================== Tabela: tb_usuario_empresa Status: ESSENCIAL (core do SaaS) Objetivo Relacionar usuários às empresas (clientes), definindo o papel do usuário dentro de cada empresa. Campos essenciais do MVP - id_usuario_empresa | INT, PK, AUTO_INCREMENT - id_usuario | INT, FK → tb_usuario.id_usuario - id_empresa | INT, FK → tb_empresas.id_empresa - role_empresa | ENUM('admin','financeiro','operador','visualizador') - ativo | TINYINT(1) DEFAULT 1 - criado_em | DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP Campos opcionais (MVP+) - ultimo_acesso | DATETIME NULL - criado_por | INT NULL (id_usuario que realizou o vínculo) Campos não essenciais / avaliados - permissões diretas (usar funções/perfis futuramente) - flags específicas por módulo (avaliar depois) Observações - Um mesmo usuário pode estar vinculado a várias empresas - O mesmo usuário pode ter roles diferentes em cada empresa - Recomenda-se chave única composta: UNIQUE (id_usuario, id_empresa) - O campo role_empresa não substitui o role da tabela tb_usuario: -- tb_usuario.role → papel global no sistema -- tb_usuario_empresa.role_empresa → papel dentro da empresa ======================================== 0.4) FUNÇÕES ======================================== Tabela: tb_funcao Status: AJUSTAR (leve) Objetivo Definir perfis/funções (roles) que agrupam permissões (ex: Admin, Financeiro, Operador). Campos essenciais do MVP - id_funcao | INT, PK, AUTO_INCREMENT (hoje está “id”) - nome | VARCHAR(80) (nome do perfil: Admin, Financeiro...) - nivel_id | INT (pode ser hierarquia/prioridade — manter por enquanto) - ativo | TINYINT(1) DEFAULT 1 (recomendado) - criado_em | DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP (recomendado) Campos opcionais (MVP+) - descricao | VARCHAR(255) NULL (pra explicar o perfil) Campos legados / não essenciais - nenhum óbvio, mas nivel_id pode virar opcional se não for usado. Observações - Padronizar campo id para id_funcao (igual fizemos em usuário/empresa). - nome deve ser único (recomendado): UNIQUE(nome). ======================================== 0.5) PERMISSÕES DA FUNÇÃO ======================================== Tabela: tb_permissao_da_funcao Status: ESSENCIAL (core) Objetivo Amarrar quais recursos cada função pode acessar (RBAC simples). Campos essenciais do MVP - id_permissao_funcao | INT, PK, AUTO_INCREMENT (hoje está “id”) - id_funcao | INT, FK → tb_funcao.id_funcao - id_recurso | INT (FK recomendada — ver observação) - criado_em | DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP (recomendado) Campos opcionais (MVP+) - permitir | TINYINT(1) DEFAULT 1 (se quiser negar/permitir sem apagar linha) Campos legados / não essenciais - nenhum. Observações - Recomenda-se chave única composta para não duplicar permissão: UNIQUE (id_funcao, id_recurso) - Idealmente id_recurso aponta para uma tabela tipo tb_recurso (ou você pode usar tb_menu como “recurso”, se já existir assim). Se permissões forem por empresa, o correto é adicionar: -- id_empresa na tb_permissao_da_funcao OU -- criar tb_empresa_funcao e “clonar” funções por empresa (mas isso pode ficar para depois — MVP pode ser global). ======================================== 0.6) MENU ======================================== Tabela: tb_menu Status: AJUSTAR (leve) Objetivo Definir a estrutura de navegação do sistema, permitindo controle de acesso via permissões. Campos essenciais do MVP - id_menu | INT, PK, AUTO_INCREMENT (hoje está menu_id) - menu_name | VARCHAR(100) (nome exibido no menu) - parent_id | INT NULL (FK para tb_menu.id_menu — submenu) - link | VARCHAR(255) (rota/URL do menu) - status | TINYINT(1) DEFAULT 1 (ativo/inativo) - icone | VARCHAR(80) NULL (classe do ícone) - ordem | INT DEFAULT 0 (ordenação no menu) - dropdown | TINYINT(1) DEFAULT 0 (indica se abre submenu) Campos opcionais (MVP+) - descricao | VARCHAR(255) NULL (uso interno / tooltip) - criado_em | DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP (recomendado) - Campos legados / não essenciais - nenhum evidente. Observações - Padronizar menu_id para id_menu (consistência com o resto do sistema). - parent_id permite menu hierárquico (nível infinito, se quiser). - dropdown = 1 geralmente indica que o menu não tem link próprio, só agrupa filhos. - Esse menu pode (e costuma) ser usado como recurso em tb_permissao_da_funcao: -- tb_permissao_da_funcao.id_recurso → tb_menu.id_menu ======================================== 0.7) CONFIGURAÇÕES BASE ======================================== Tabela: tb_configuracoes Status: AJUSTAR (moderado) Objetivo Armazenar configurações específicas por empresa (tenant), usadas em comunicações, identidade visual, integrações e parâmetros do sistema. Campos essenciais do MVP 🔴 Aqui é importante ser honesto: nem tudo precisa estar no MVP. Campos mínimos para o SaaS rodar bem: - id_configuracao | INT, PK, AUTO_INCREMENT (hoje está id) - id_empresa | INT, FK → tb_empresas.id_empresa (hoje está empresa) - email | VARCHAR(150) (email principal do sistema) - telefone | VARCHAR(20) NULL - site | VARCHAR(150) NULL - logotipo | VARCHAR(255) NULL - cor_email | VARCHAR(20) NULL (hex ou nome) - tempo_sessao | INT DEFAULT 30 (minutos) - criado_em | DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP (recomendado) Campos úteis (MVP+) 📍 Endereço / Identidade - endereco | VARCHAR(180) NULL - numero | VARCHAR(20) NULL - bairro | VARCHAR(100) NULL - cidade | VARCHAR(100) NULL - estado | CHAR(2) NULL - cep | VARCHAR(10) NULL - cnpj | VARCHAR(18) NULL 📧 E-mail / SMTP - email_form | VARCHAR(150) NULL - email_form_senha | VARCHAR(255) NULL (⚠️ ver observação) - serv_saida_smtp | VARCHAR(150) NULL - porta_smtp | INT NULL - conexao_segura | ENUM('ssl','tls','none') DEFAULT 'tls' 📞 Contatos - email_contato_1 | VARCHAR(150) NULL - email_contato_2 | VARCHAR(150) NULL - telefone_contato_1 | VARCHAR(20) NULL - telefone_contato_2 | VARCHAR(20) NULL 🌐 Redes sociais - rede_social_1 … rede_social_6 | VARCHAR(255) NULL ✉️ Comunicação - frase_email | VARCHAR(255) NULL - marca_dagua | VARCHAR(255) NULL Campos avançados / específicos (avaliar manter) 🔐 Segurança / Integrações - chave_de_site | VARCHAR(255) NULL - chave_secreta | VARCHAR(255) NULL 🧠 SEO / Tags - keywords | VARCHAR(255) NULL - description | VARCHAR(255) NULL - tag_head | TEXT NULL - tag_body | TEXT NULL - tag_header | TEXT NULL - tag_footer | TEXT NULL Campos não recomendados (alerta) - email_form_senha 🔴 Nunca salvar senha em texto puro ✔️ Se mantiver: criptografar ou usar secret manager Misturar SEO/site institucional com configuração de sistema (aceitável agora, mas futuramente pode virar outra tabela) Observações importantes - Padronizar empresa → id_empresa - Deve existir 1 linha por empresa: -- usar UNIQUE(id_empresa) -Essa tabela é lida o tempo todo: -- cache recomendável (session ou redis no futuro)