Melhor abordagem para armazenamento básico de dados de sessão PHP DB

Decidi mudar do gerenciamento de sessão nativo do PHP baseado em $_SESSIONusar o meu próprio, devido a muitos problemas diferentes que tive até agora com as possibilidades do PHP e também porque estou construindo uma API que deve ser compatível com solicitações de aplicativos móveis ; então eu não posso confiar de $_SESSIONqualquer maneira. Eu sei que existem frameworks como symfony etc. por aí para isso, mas usar sth assim para essas operações de bebê seria um exagero.

O que estou implementando no momento é, portanto, de acordo com essa lógica ( source ):

O último ponto que estou querendo saber é que o Redis / o artigo vinculado recomenda "Armazenar informações da sessão e do usuário " após uma primeira autenticação bem-sucedida, como um login ou similar. No entanto, acho que seria muito mais benéfico não fazer isso e armazenar apenas o identificador da sessão, como um cartão VIP que permitirá ao cliente lançar solicitações na área segura do aplicativo da web.

Meu pensamento foi apenas isso:

• a maioria das informações do usuário em questão está no banco de dados de qualquer maneira e de forma não criptografada; a maior parte mesmo em uma única tabela de banco de dados.
• Eu acho que geralmente é uma má prática armazenar os mesmos dados em vários locais de um banco de dados, mesmo que um seja armazenado para acesso "mais rápido" ou "facilitado" nesse sentido.
• Todas as informações do usuário (= todos os dados necessários para todas as solicitações REST possíveis da plataforma, reunidas em um JSON) abrangem cerca de 50 pares de valores-chave, e alguns desses valores são criptografados, então eu também precisaria criptografar o usuário resultante info , resultando em enormes operações de criptografia / descriptografia a cada solicitação (e carregamento de página, como também usado para autenticação), e uma coluna adicional de sth like VARBINARY(600).
• Para uma solicitação, nunca preciso de mais de 10 desses dados de kv e, principalmente, apenas coisas como 2 - 3.

Dadas as considerações acima, eu me perguntei: não é um exagero completo e uma enorme transferência de dados para nada, armazenar todas as informações do usuário (soma de todos os dados do usuário que preciso em todas as solicitações REST da plataforma) ao longo do identificador de sessão para imitar uma sessão? Não é melhor apenas armazenar o identificador de sessão no banco de dados e consultar apenas as informações necessárias do usuário quando a solicitação real chegar (etapa 4a da img acima)? Isso não faz muito mais sentido?

Sinto vontade de desperdiçar tantos recursos se armazenar todas as informações do usuário junto com o identificador de sessão. Como isso também significa que eu estaria descriptografando e enviando uma quantidade significativa de carga útil em vão para diferentes solicitações.

Então, qual é a melhor prática aqui, armazenar as informações do usuário na autenticação (etapa 1b) ou recuperá-las quando a autenticação for uma solicitação (etapa 4b) ??

Para lhe dar uma ideia; a compensação resultante precisaria ser feita entre:

• descriptografar os dados e enviar muito mais informações do usuário do que realmente necessário pelo endpoint, a cada solicitação

VS

• fazendo pelo menos 2 JOINS em PRIMARY KEYs em cada carregamento / solicitação de página, em média, e, eventualmente, 1-2 descriptografias menores nessa consulta também.

Em termos de desempenho, não tenho ideia do que é mais inteligente aqui.

E outra compensação é a conveniência de codificação, pois não armazenar todo o conjunto de dados da sessão como tal no banco de dados significa uma solicitação específica do banco de dados de informações do usuário por chamada REST.