Exposição
Digamos que nosso sistema tenha usuários e alguns jogos . Vamos chamar esses jogos de A , B e C.
Para simplificar, nossas tabelas iniciais ficam assim:
CREATE TABLE IF NOT EXISTS users (
id SERIAL PRIMARY KEY
);
CREATE TABLE IF NOT EXISTS games (
id SERIAL PRIMARY KEY
);
Problema
Sempre que jogamos esses jogos e os terminamos, temos que registrar estatísticas relacionadas ao jogo para o usuário específico. Por exemplo, para o jogo A, temos que registrar total_jumps e total_crouches porque a mecânica do jogo permite tal acumulação, no entanto, os jogos B e C podem exigir que registremos outros campos total_* (embora o prefixo total_ não seja necessário). Como armazeno essas informações?
Estou preocupado com a solução para esse problema. Eu criei 2 abordagens:
Solução 1
Tenha uma única tabela para isso:
CREATE TABLE IF NOT EXISTS statistics (
user_id SERIAL REFERENCES users (id) ON DELETE CASCADE,
game_id SERIAL REFERENCES games (id) ON DELETE CASCADE,
fields JSONB,
PRIMARY KEY (user_id, game_id)
);
Dessa forma, deixamos para o nível do aplicativo analisar dados arbitrários provenientes da coluna de campos .
Solução 2
Tenha várias mesas, uma para cada jogo:
CREATE TABLE IF NOT EXISTS A_statistics (
user_id SERIAL PRIMARY KEY REFERENCES users (id) ON DELETE CASCADE,
total_jumps INTEGER,
total_crouches INTEGER
);
Pessoalmente, a solução #2 parece melhor para mim, mas... esse problema ainda me incomoda muito. Como se eu estivesse esquecendo de algo, porque nenhuma das opções torna a extensão (adicionar novos jogos) mais fácil? Digamos que adicionamos os jogos D , E e F . Ambas as soluções exigem que, de alguma forma, manipulemos campos específicos (no nível do aplicativo) necessários para esses jogos. Isso é algo com o qual eu simplesmente tenho que me conformar? Ou há uma terceira solução melhor para isso que eu simplesmente não vejo?
Você pode usar um banco de dados não relacional para armazenar esse tipo de dado. Por exemplo, no mongoDB você pode ter uma coleção de jogos. Então, no código do seu aplicativo, você pode ter vários modelos de dados:
Total_passes do jogo de futebol
Jogo de Boxe total_socos
Cada um desses modelos de dados seria salvo na mesma coleção, o que é possível devido ao uso de um banco de dados não relacional.
Além disso, cada um desses modelos de dados pode herdar de um modelo de jogo base com algumas propriedades comuns.
Cada modelo de dados armazenará algum tipo de discriminador que denota o jogo. Isso seria necessário para que o código do seu aplicativo saiba como carregar um jogo salvo do banco de dados, ou seja, a qual modelo de dados o documento salvo corresponde. Veja https://mongoosejs.com/docs/discriminators.html#discriminators
Os sistemas de gerenciamento de banco de dados relacional esperam estruturas de dados bem definidas - as "relações" no nome. Então, ter necessidades de variáveis de tempo de execução é um problema difícil conhecido.
Dito isso, a maioria das versões recentes de tudo lida bem com JSON. Ter alguma análise de JSON em uma consulta SQL não precisa prejudicar muito o desempenho.
Começar com uma única coluna JSON vai te deixar pronto e funcionando. Com o tempo, você verá que muitas consultas leem a mesma métrica, ou certos jogos são extremamente populares. Adicione uma coluna para estes especificamente e escreva o valor na coluna e também em JSON. Em outras palavras, comece com 1 e vá para 2 ao longo do tempo.
Se você pesquisar bastante, vai ler sobre o modelo "valor de atributo de entidade". Ele funcionará bem o suficiente em pequena escala (dependendo do hardware), mas, na minha experiência, fica muito feio bem rápido quando você não é mais pequeno.