Implementei um sistema de carrinho de compras no meu app usando o localStorage do javascript como método de armazenamento. Depois de alguns testes decidi migrar essa responsabilidade de armazenamento para o banco de dados e pensei em uma estrutura assim:
Cada registro da tabela Usuarios teria uma tabela (tipo um relacionamento REGISTRO X TABELA) chamada {ID}_CARRINHO_COMPRAS, onde ID seria o id do registro do usuário ao qual essa tabela pertence. Ex: O Usuario id: 3 vai ter uma tabela com o nome 3_CARRINHO_COMPRAS. Essa tabela seria criada no momento que o usuário se cadastrasse.
As minhas dúvidas são:
Usando esse sistema o banco de dados iria ter centenas de tabelas, levando em consideração que podem haver centenas de usuários cadastrados. Isso é um problema?
Provavelmente o cadastro do usuário iria ficar lento e a consulta nas tabelas também. Então, teria outra forma de fazer o que eu estou tentando fazer?
Pode ser que sim. Mas como você chegou à ideia de ter uma tabela para cada carrinho de compras de cada usuário?
Geralmente, é mais simples ter uma única tabela pra todos os itens de todas as vendas, e nela ter um campo para saber quais itens pertencem a qual venda, e uma tabela de vendas que tem um campo para saber a qual usuário pertence aquela venda.
É uma gambiarra que eu já tinha feito antes. Na época eu fiz um app de email e cada usuário teria uma tabela ID_EMAILS_RECEBIDOS e outra ID_EMAILS_ENVIADOS, que o nome já é auto explicativo. Daí, quando um usuário id: 2, por exemplo, enviava um email para um usuario id: 4, esse email ficava armazenado nas tabelas 2_EMAILS_ENVIADOS e 4_EMAILS_RECEBIDOS. A ideia era que os registros da tabela ID_EMAILS_RECEBIDOS dependessem da tabela ID_EMAILS_ENVIADOS para existir. Ou seja, se um registro é apagado em uma, também é apagado na outra.
Uma doidera do carai, mas eu ainda era novato ksksksks