Sugestão de estrutura
[Finalizado Pelo Aluno]
Olá equipe Especialliza TI, boa tarde!
Estou trabalhando em um projeto onde espero sugestão a respeito de estrutura de banco de dados. Se trata de um cadastro de imoveis onde se registra várias características.
Para você entender melhor vou citar um exemplo simplificado:
Tabela “properties” (imóveis)
[
{
Id: 10
codigo: APTO1002
tipo: Apartamento
dorm: 1...
}
]
Para registrar características adicionais dos imoveis (área de lazer, infra estrutura...) existe uma tabela chamada “property_features” que poderá conter dezenas de registros referente a um único imóvel:
[
{
Id:1
property_id:1 (chave estrangeira da tabela “properties”)
description: Piscina ....
}
]
Recentemente me deparei com um banco de dados onde possui um único campo longText para essas características adicionais separadas por vírgula.
Exemplo: Piscina, Salão de Festas, Salão de Jogos...
O que você acha disso?
É errado?
Agradeço o costumeiro apoio.
Olá, Roberto!
Tudo bem?
Não acho uma boa, até é funcional e vai atender (para projetos PEQUENOS). Mas, em casos mais complexos realmente não fica legal.
Você pode até ter colunas diferentes para cada um destes tipos (com valor boolean). E no projeto você mostra as opções com checkbox, ao clicar você insere o valor de true na respectiva coluna, fica mais profissional dessa forma.
Olá Carlos,
Muito Obrigado pelo retorno.
Como existem dezenas de caracteriticas possíveis (área de lazer, infra estrutura, area privativa) e outras que podem surgir, estive pensando em criar uma tabela com a seguinte estrutura:
Registro 1
id: auto_increment,
imovel_id: id da tabela de imoveis (foreign key)
tipo: Área de Lazer
descricao: Piscina
Registro 2
id: auto_increment,
imovel_id: id da tabela de imoveis (foreign key)
tipo: Area Privativa
descricao: Cozinha Americana
Dessa forma bastaria alterar no front-end a lista de items de cada área (area de lazer, infra..) e no back-end nada seria alterado.
Voce acha que dessa forma impacta no desempenho do banco?
Ou é melhor criar uma coluna boleana para cada caracteristica?
Grato!
Abs!
A vantagem de criar a coluna boolean é a performance de bancos de dados relacionais (mysql e afins).
Mas, você também pode salvar um JSON, sem problemas.
Entendi. Vou optar pela performance.
Seguindo esse caminho então voce colocaria todas as características na mesma tabela?
Evitando joins vai aumentar a perfomance?
É aquele ponto que levantei na minha primeira resposta, se o sistema for pequeno, dependente do que faça, dificilmente vai gerar perca significativa de performance.
Não vejo problemas separar em diferentes tabelas, e usar joins (desde que seja na mesma consulta -> No Laravel usando os relacionamento com ->with('relacao')).
Entendido. Obrigado!
Precisa estar logado para conseguir responder a este ticket!
Clique Aqui Para Entrar!