Peeyush Kushwaha's questions

Na tabela a seguir:

CREATE TABLE user (
    email           varchar[],
    ...
);

Eu gostaria de garantir que dois usuários não tenham o mesmo e-mail. Não tenho certeza de como a UNIQUErestrição interage com os tipos de dados da matriz. Qual é a maneira apropriada de garantir a exclusividade? Ou isso é um antipadrão e devo declarar outra emailstabela?

Meu raciocínio está correto ao dividir tabelas com estruturas semelhantes, pois contêm dados não relacionados?

Vou explicar a situação com um exemplo:

Suponha que haja um servidor que hospeda o banco de dados de um jogo online. O jogo tem vários mundos de jogo que operam em paralelo. O esquema para cada gameworld do jogo é o mesmo, digamos que haja 15 tabelas relacionais no design do banco de dados do jogo. Suponha também que o servidor decida não excluir os dados dos servidores antigos e, em vez disso, arquive-os.

Abordagem 1:

Agora, como os mundos do jogo estão hospedados em um servidor, pode parecer lógico colocar todos os dados do jogo em um banco de dados contendo 15 tabelas. A estrutura da tabela de uma tabela de exemplo pode ser assim:

CREATE TABLE `table` (
    playerid ...,
    score ....,
    gameworldid ...,
    PRIMARY KEY(gameworldid,playerid)
) ENGINE = InnoDB

Então, toda vez que eu precisar mostrar os 10 jogadores com mais pontuação, terei que fazer algo comoSELECT * FROM table WHERE gameworldid = {id} ORDER By score DESC LIMIT 10

Abordagem 2:

Uma vez que os dados de um gameworld não se relacionam com os dados do outro gameworld de forma alguma (exceto pela estrutura), podemos criar bancos de dados diferentes para diferentes gameworlds ou diferentes conjuntos de tabelas para cada gameworld. A estrutura da tabela ficará mais ou menos assim:

CREATE TABLE `gameworldid_table` (
    playerid ...,
    score ....,
    PRIMARY KEY(playerid)
) ENGINE = InnoDB

Neste caso, os 10 melhores jogadores com mais scorequery serãoSELECT * FROM table ORDER BY score DESC LIMIT 10

A questão é: qual abordagem é melhor nessa situação? O mecanismo de armazenamento que está sendo usado é InnoDB, e ao todo , pode-se esperar 6 bilhões ou mais de linhas na maior tabela mesclada, e 500 ou mais mundos de jogo. (Desde que os dados antigos não são excluídos, então, quando um gameworld é reiniciado, um novo gameworld é criado.

Na minha opinião, as vantagens da Abordagem 2 sobre a Abordagem 1 são:

• Menos espaço consumido pela chave primária e índices, tornando-os mais eficientes
• Classificação, junção e outras coisas mais rápidas em comparação com a tabela mesclada na abordagem um, que contém muitos dados extras que podem atrapalhar essas operações.
• Inserções mais rápidas em comparação com tabelas maiores
• Os dados não vão continuar se acumulando para sempre na mesma tabela

E as vantagens do Approach 1 sobre o Approach 2 ?

• Melhor capacidade de gerenciamento: 15 mesas soam melhor em comparação com 500 * 15 mesas, se você precisar fazer alguma correção manual (raro).
• soa menos insano
• Muitas tabelas podem tornar o banco de dados mais lento (não sei de fato, não consigo encontrá-lo na internet)

Acho que minhas opiniões sobre vantagens e desvantagens podem ser tendenciosas, mas realmente quero saber quais problemas podem surgir se eu escolher uma Abordagem em detrimento da outra. Além disso, existe alguma outra solução possível para esta solução?