[PROMOÇÃO] Assine com + 30% de desconto ANUAL MENSAL (últimas horas)
Roberto Noya
Criador Roberto Noya 28/01/2021

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.

Manager Carlos Ferreira 28/01/2021

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.

Carlos Ferreira
Criador Roberto Noya 28/01/2021

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!

 

 

 

 

 

 

Roberto Noya
Manager Carlos Ferreira 28/01/2021

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.

Carlos Ferreira
Criador Roberto Noya 28/01/2021

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?

Roberto Noya
Manager Carlos Ferreira 28/01/2021

É 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')).

Carlos Ferreira
Criador Roberto Noya 28/01/2021

Entendido. Obrigado!

Roberto Noya
Sabe a Solução? Ajude a resolver!

Precisa estar logado para conseguir responder a este ticket!

Clique Aqui Para Entrar!