Modelagem e DP para estrutura dos imóveis

[Matias Rezende 50]

Caros amigos

 

Estou desenvolvendo um site para uma imobiliária e me surgiu uma dúvida quanto à melhor modelagem e DP para gravar a infra-estrutura de um imóvel (por exemplo, se tem portaria, salão de festas, coisas assim). Qual seria a melhor modelagem? Qual seria o DP ideal para trabalhar com este caso? Pensei em trabalhar com um campo do tipo TEXT, gravando o nome de todas as estruturas, mantendo este campo como FULL TEXT e efetuando a busca neste campo, com base no que foi enviado, mas não creio que seja a melhor opção.

 

Tenho, neste mesmo site, uma tabela contendo os bairros. Existem bairros que tem características semelhantes.. Exemplificando, os bairros Kobrasol e Campinas, na cidade de São José, são semelhantes. Então, se a pessoa quiser localizar imóveis do bairro Kobrasol, eu quero mostrar os imóveis que estejam em Campinas também. Para este caso, eu pensei em trabalhar com um campo a mais na tabela de bairros, separando os ids dos bairros relacionados por virgula. Só que achei meio gambiarra e acho que vou ter problemas de desempenho fazendo assim, além de não ser a melhor opção.

 

Coloquei as duas dúvidas no mesmo tópico porque entendo que seja a mesma solução para os dois problemas.

 

Aí, resolvi pedir ajuda ANTES de fazer coisa errada, pra fazer correto desde o início.

 

Obrigado

 

Carlos Eduardo

[João Batista Neto 448]

Existem bairros que tem características semelhantes.

O que define as semelhanças entre os bairros ?

[Matias Rezende 50]

O usuário define quais são os bairros semelhantes. Ou seja, o usuário cadastra o bairro X e diz que os bairros Y, Z, A, B e C são semelhantes a este e faz isto em todos os bairros que tiverem semelhantes.

 

Carlos Eduardo

[William Bruno 1501]

O usuário define quais são os bairros semelhantes.

 

Qual usuário ?

 

o que está cadastrando o imóvel ?

ou o administrador do sistema ?

 

Nesse caso, eu sugeriria uma #@?$%~ tabela:

TABLE bairro_semelhante

id_anuncio, id_bairro, id_bairro_semelhante

 

Sendo que todos esses campos seriam FK

 

Para os 'acessórios' dos imóveis, melhor funcionará(acredito que a busca aqui, será muito mais rápida, do que esquemas de explode, ou LIKE que você possa fazer em campos TEXT), se você tiver essa lista pré-estabelecida, e no cadastro de um novo imóvel(anuncio), o cara só 'ticar', se tem ou não.

Ai temos outra tabela de relacionamento.

TABLE imovel_acessorio

id_imovel, id_acessorio

 

Isso vai inflar e muito essa tabela, terá milhares de linhas, porém por ser simples, e só possuir FKs, não acredito que fique 'pesada', ou comprometa o teu sistema.

[João Batista Neto 448]

Ok, primeiro vamos separar modelagem de design pattern.

 

1. Você terá bairros

2. Bairros poderão ser semelhantes a outros bairros

3. Bairros possuirão imóveis

4. Imóveis terão infra-estrutura.

 

Pensando inicialmente no imóvel e sua infra-estrutura:

 

1. Um imóvel poderá ter 1 ou mais infra-estrutura, por exemplo:

Salão de Festas (1)

Portaria (1)

Salas (1 ou mais)

 

Pensando dessa forma, a infra-estrutura deverá ter 1 tabela separada só com o nome, descrição e qualquer detalhe que seja comum para todos os imóveis, como não podemos duplicar o registro dos imóveis, teremos uma tabela de relacionamento que conterá o imóvel e sua infraestrutura (com respectiva quantidade).

 

No caso dos bairros, teremos uma tabela com os dados do bairro e suas características e uma segunda tabela que fará o relacionamento, alguma coisa assim:

 

Bom, com a modelagem, podemos pensar nas tabelas do banco:

 

 

Bom, o que acontece aqui:

 

Primeiro, referente aos bairros:

 

1. Se o usuário fizer uma pesquisa por características do bairro, nosso índice FULLTEXT para caracteristicaBairro permitirá que o usuário encontre bairros que possuam determinadas características, segundo o texto digitado.

 

2. Ao escolher um determinado bairro, nossa tabela BairroSemelhante trará os bairros relacionados em 1⁰ nível, mas, imagine o seguinte:

Bairro A

Bairro B

Bairro C

Bairro D

Bairro E

 

O administrador do sistema disse que o Bairro A é semelhante ao Bairro B e ao Bairro C, disse também, que o Bairro E é semelhante ao Bairro C e ao Bairro D.

Percebe que, ao definir a semelhança do Bairro E com o Bairro C ele definiu, indiretamente, a semelhança do Bairro E com o Bairro A e Bairro B !?

 

Essa semelhança de segundo nível pode ser utilizada em uma possível listagem de "Recomendamos também".

 

Segundo, referente aos imóveis:

 

Muitas vezes, quando procuramos um imóvel, procuramos baseado em um conjunto de pré-requisitos, por exemplo:

Precisamos de um imóvel com:

 

1. 4 Salas

2. Área de conferência

3. Internet

Como salas, internet, salão de festa, área de conferência são itens que podem ser comuns para vários imóveis, a separação em uma tabela específica permitirá que utilizemos esses itens como filtros.

Já a tabela de relacionamento permitirá que, além de localizar os imóveis que tenham os pré-requisitos, encontremos também imóveis similares, mesmo que estejam em bairros distintos.

 

Agora, antes de falarmos sobre design patterns, apenas confirme se o sistema é mais ou menos isso, ou se entendi errado.

 

[Matias Rezende 50]

No caso dos bairros, teremos uma tabela com os dados do bairro e suas características e uma segunda tabela que fará o relacionamento

 

Na verdade eu tinha pensado em algo mais simples do que isto. No bairro só teria o nome do bairro e o id da cidade que ele pertence. Não tinha pensado em colocar as características de cada bairro. Com certeza não vou implementar nada neste sentido agora... Será que vale a pena colocar para, quem sabe no futuro, implementar algo? Sobre fazer o relacionamento em outra tabela, até aqui tá ok.

 

Como salas, internet, salão de festa, área de conferência são itens que podem ser comuns para vários imóveis, a separação em uma tabela específica permitirá que utilizemos esses itens como filtros.

Já a tabela de relacionamento permitirá que, além de localizar os imóveis que tenham os pré-requisitos, encontremos também imóveis similares, mesmo que estejam em bairros distintos

 

Não entendi esta separação. Tabela de relacionamento e a separação em tabela específica não são a mesma coisa? Afinal, salas, internet, salão de festas e afins são a estrutura.

 

Agora, antes de falarmos sobre design patterns, apenas confirme se o sistema é mais ou menos isso, ou se entendi errado.

 

É bem isto mesmo. Esta seria a melhor modelagem então? Porque com esta modelagem, eu fiquei com dificuldade em compreender como faria a busca sem perder desempenho, utilizando IN. Por exemplo, para buscar os imóveis de um bairro ou bairros relacionados, eu faria algo assim:

SELECT campos FROM imovel JOIN bairro USING (idBairro) WHERE idBairro = 1 OR idBairro IN (SELECT idSemelhante FROM bairroSemelhante WHERE idBairro = 1)

Onde 1 seria o id do bairro escolhido na busca. O William me deu uma idéia no MSN, que seria mais ou menos assim:

SELECT campos FROM bairroSemelhante JOIN bairro USING (idBairro) JOIN imovel USING (idBairro) WHERE idBairro = 1

Acho que era mais ou menos isto.

 

Enfim, por isto que fiquei na dúvida sobre esta questão.

 

Agradeço ao apoio.

 

Carlos Eduardo

[João Batista Neto 448]

No bairro só teria o nome do bairro e o id da cidade que ele pertence.

Será que vale a pena colocar para, quem sabe no futuro, implementar algo?

 

Sem problemas, você pode ou não ter outros dados do bairro, já que essas informações não influem diretamente na modelagem.

 

Não entendi esta separação. Tabela de relacionamento e a separação em tabela específica não são a mesma coisa? Afinal, salas, internet, salão de festas e afins são a estrutura.

 

Sim, são.

 

Mas imagine: (E para estrutura, I para imóvel)

 

E: Sala

E: Quarto

 

I: Casa 1

I: Casa 2

 

Imagine que na Casa 1 você tenha 3 quartos e 1 sala e que na Casa 2 você tenha 2 quartos e 2 salas.

 

No ponto de vista de arquitetônico, sala é a mesma coisa, tanto para Casa 1 quanto para Casa 2, o mesmo ocorre com os quartos, a diferença está na área e na quantidade.

 

Então, se não tivermos uma tabela intermediária, que relacione Estrutura com Imóvel, informando apenas a quantidade, acabaremos tendo redundância de informações.

 

Tabela Estrutura:

+-------------+-----------------+
| idEstrutura | nomeEstrutura |
+-------------+-----------------+
| 1 	| Sala 	|
+-------------+-----------------+
| 2 	| Quarto 	|
+-------------+-----------------+

Tabela Imóveis:

+----------+------------+
| idImovel | nomeImovel |
+----------+------------+
| 1 	| Casa 1 	|
+----------+------------+
| 2 	| Casa 2 	|
+----------+------------+

Tabela de relacionamento:

+-------------------+-------------+----------+---------------------------+
| idImovelEstrutura | idEstrutura | idImovel | quantidadeImovelEstrutura |
+-------------------+-------------+----------+---------------------------+
| 1 	| 1 	| 1 	| 1 	| 	
+-------------------+-------------+----------+---------------------------+
| 2 	| 2 	| 1 	| 3 	|
+-------------------+-------------+----------+---------------------------+
| 3 	| 1 	| 2 	| 2 	| 	
+-------------------+-------------+----------+---------------------------+
| 4 	| 2 	| 2 	| 2 	|
+-------------------+-------------+----------+---------------------------+

 

Percebe que, dessa forma, não existe redundância ?

 

Cadastramos as possíveis estruturas e a reutilizamos em qualquer imóvel que a possua.

 

O William me deu uma idéia no MSN, que seria mais ou menos assim:

 SELECT campos FROM bairroSemelhante JOIN bairro USING (idBairro) JOIN imovel USING (idBairro) WHERE idBairro = 1 

 

Essa consulta possui um problema, sempre que você for fazer uma consulta utilizando JOIN, a consulta principal deve ser a com menor resultados.

 

Como a de bairroSemelhante sempre terá mais linhas que a de bairros, você não deve utilizá-la na consulta principal, então, ficaria assim:

SELECT campos FROM `Bairro` AS `B` LEFT JOIN `BairroSemelhante` AS `S` USING(`idBairro`) WHERE `B`.`idBairro` = 1;

 

Qual a diferença ?

 

Bom, imagine que você tenha 10 bairros semelhantes ao idBairro = 1

 

Se BairroSemelhante for a consulta principal, terá 10 linhas, então será feita a comparação, linha por linha do resultado principal com a tabela Bairro que contém apenas 1 resultado, ou seja, 10 vezes a mesma comparação.

 

Agora, se a Bairro for a consulta principal, terá apenas 1 resultado, então, apenas 1 vez será feita a comparação com a tabela BairroSemelhante que, devido ao índice, trará os 10 resultados.

 

Apenas por uma questão de contexto, eu não misturaria uma busca por imóveis em uma busca por bairros semelhantes, isso causará, inevitavelmente, uma replicação de resultados e, consequentemente um tráfego maior.

[Matias Rezende 50]

Cadastramos as possíveis estruturas e a reutilizamos em qualquer imóvel que a possua.

 

Perfeito. Era assim mesmo que eu tinha compreendido.

 

Essa consulta possui um problema, sempre que você for fazer uma consulta utilizando JOIN, a consulta principal deve ser a com menor resultados.

 

Entendi também.

 

Apenas por uma questão de contexto, eu não misturaria uma busca por imóveis em uma busca por bairros semelhantes, isso causará, inevitavelmente, uma replicação de resultados e, consequentemente um tráfego maior.

Uhn.... interessante. Não tinha pensado neste sentido. Como você faria então?

 

Carlos Eduardo

[João Batista Neto 448]

Uhn.... interessante. Não tinha pensado neste sentido. Como você faria então?

 

Vamos pensar no caso de uso:

 

Busca Imóvel por Bairro

Nesse caso, quando o usuário selecionar um bairro específico na lista, faremos 2 consultas, uma para localizar os bairros similares e outra para localizar os imóveis daquele bairro.

 

Você deve estar se perguntando: "Mas duas consultas ? Não perde-se em desempenho ?"

 

Na primeira visualização sim, mas na aplicação como um todo não.

 

Isso porque, se o usuário não gostar do imóvel que ele selecionou, ele voltará na listagem de imóveis daquele bairro.

Se nossa consulta de imóveis estiver atrelada aos bairros similares, cada nova busca por imóvel causará uma nova busca por bairros semelhantes. O problema é que, como os imóveis são diferentes, o SGDB não conseguirá fazer cachê das consultas. Já, se separarmos as duas consultas, a de bairros similares será executada apenas 1 vez e nas seguintes usaremos o cache do banco.

 

[Matias Rezende 50]

Certo. Então, só que na verdade não vai ser bem assim... Não vai ser pesquisa por bairro OU pesquisa por estrutura. Vai poder ser pesquisa só por bairro, só por estrutura ou por bairro e estrutura. E além destas opções, terão também:

• Por valor do imóvel
• Por tipo de imóvel - os tipos de imóveis estão cadastrados em outra tabela
• Por tamanho do imóvel
• Por cidade (Cada bairro está ligado à uma cidade. O imóvel está ligado somente no bairro - tá certo isto, né?)
• Por tipo de venda de imóvel (Aluguel, venda, permuta...)

Então, a pessoa que fizer a busca pode escolher 1, 2, 3 ou quantas opções quiser, entre todas elas. Aí não sei se daria na mesma com relação aos casos de uso.

 

Influencia nos casos de uso, no DP e/ou na modelagem utilizada?

 

Carlos Eduardo