Dicas para design de banco de dados em um aplicativo web [fechado]

Question

Alguém tem alguma dica/conselho sobre design de banco de dados para um aplicativo da web?O tipo de coisa que pode me poupar muito tempo/esforço no futuro, quando/se o aplicativo em que estou trabalhando decolar e começar a ser muito utilizado.

Para ser um pouco mais específico, o aplicativo é um jogo de estratégia (baseado em navegador, apenas texto) que envolverá principalmente jogadores emitindo "ordens" que serão armazenadas no banco de dados e processadas posteriormente, sendo os resultados também armazenados lá (o histórico de "pedidos" e os resultados correspondentes provavelmente serão bastante grandes).

Editado para adicionar mais detalhes (como pedido):

plataforma:Django

mecanismo de banco de dados:Eu estava pensando em usar MySQL (a menos que haja uma grande vantagem em usar outro)

o esquema:tudo o que tenho agora são alguns modelos do Django, e isso é detalhe demais para postar aqui.E se eu começar a postar esquemas isso fica muito específico, e eu estava procurando dicas gerais.Por exemplo, considere que eu emito "pedidos" que serão posteriormente processados ​​e retorno um resultado que devo armazenar para exibir algum tipo de "histórico".Neste caso é melhor ter uma tabela separada para o “histórico” ou apenas uma que agregue tanto os “pedidos” quanto o resultado?Acho que poderia armazenar em cache a tabela de "histórico", mas isso ocuparia mais espaço no banco de dados e também mais operações no banco de dados, porque eu teria que criar constantemente novas linhas em vez de apenas alterá-las na tabela agregada.

Answer 1

Você provavelmente tocou em uma questão muito maior de projetar para alta escalabilidade e desempenho em geral.

Essencialmente, para o design do seu banco de dados, eu seguiria boas práticas, como adicionar chaves estrangeiras e índices aos dados que você espera que sejam usados ​​com frequência, normalizar seus dados dividindo-os em tabelas menores e identificar quais dados devem ser lidos com frequência e quais devem ser lidos com frequência. escrito com freqüência e otimizar.

Muito mais importante do que o design do seu banco de dados para aplicativos da Web de alto desempenho, é o uso eficaz do cache tanto no nível do cliente, por meio do cache de páginas HTML, quanto no nível do servidor, por meio de dados armazenados em cache ou servindo arquivos estáticos no lugar de arquivos dinâmicos.

A grande vantagem do cache é que ele pode ser adicionado conforme necessário, para que, quando seu aplicativo decolar, você evolua de acordo.

No que diz respeito aos seus dados históricos, é ótimo armazenar isso em cache, pois você não espera que eles mudem com frequência.Se você deseja produzir relatórios regulares e bastante intensivos a partir de seus dados, então é uma boa prática colocar esses dados em outro banco de dados para não interromper sua aplicação web enquanto ela é executada.

É claro que esse tipo de otimização não é realmente necessário, a menos que você ache que seu aplicativo o justifica.

Answer 2

Normalização de banco de dados, e pensar bem nos índices são duas coisas que você não pode perder.Especialmente se você considerar um jogo onde SELECTS acontecem com muito mais frequência do que UPDATEs.

No longo prazo, você também deve dar uma olhada memcached, já que as consultas ao banco de dados podem ser o gargalo sempre que você tiver mais do que alguns usuários.

Answer 3

Por que você não posta o esquema que você tem agora?É uma pergunta muito ampla para ser respondida de forma útil sem alguns detalhes sobre qual plataforma e banco de dados você usará e a estrutura da tabela que você está propondo...

Answer 4

Você deve desnormalizar suas tabelas se você juntar mais de 6 tabelas em uma consulta para recuperar dados para uma página da web do tipo relatório que será acessada com frequência.Além disso, se você usar bibliotecas ORM como Hibernate ou ActiveRecord, gaste algum tempo nos mapeamentos padrão que elas geram e no sql que acaba gerando.Eles tendem a conversar muito com o banco de dados quando você poderia obter os mesmos resultados com uma viagem de ida e volta ao banco de dados.