Quando o cliente nos baralha a cabeça - Ajuda em 3 situações

AndreLC

Power Member
Boa tarde,

Hoje tive uma reunião com um cliente sobre o BackOffice que estou a desenvolver para imóveis e o cliente solicitou-me três alterações que me indignaram um pouco, pelo menos, a primeira delas:

1 - Tenho a gestão de Imóveis, Agências e Agentes Comerciais.
No Front-End o cliente queria que a referência do imóvel se pudesse visualizar da seguinte maneira:
ID da Agência - ID do Agente - ID do Imóvel.
E eu com um INNER JOIN juntei as referências todas e tudo bem. Mas tinha percebido mal...

O que o cliente pretende é mesmo na Base de Dados, num campo - por exemplo, no ID do imóvel (que actualmente está como auto increment e é chave primária) pudesse também juntamente ter os restantes id's, e justificou-se:
101-1001-40 (A agência é a número 101, o Agente 1001 e o imóvel 40),
O que indica que o Agente 1001 da Agência 101 já possui 40 imóveis.
Quando se registasse, por exemplo, o agente 1002, os imóveis voltavam a 1 (mas isto tudo no mesmo campo - o que me indignou):
101-1002-1 (O primeiro imóvel do Agente 1002) ... 101-1002-02 (O Segundo imóvel do Agente 1002) ....

Eu refutei que como estava com auto increment não dava para fazer isso, só se não fosse auto increment e colocasse a referência à mão e o cliente excluiu essa hipótese, porque queria isto de maneira automática.
Novamente, disse que isso era pouco ético, que ia contra as regras das Base de Dados e que os id's são para serem únicos, mas o cliente refere que os outros sites de imobiliárias também têm isso e então o dele também tem que ter. Que trabalham muito com essa referência e muito trabalho depende dela.

Ressaltou, que como tenho, está:
101-1001-40
E depois se registasse o agente 1002 o imóvel seria o 41
101-1002-41
E que revelaria que tinha já 41 imóveis o que não é verdade! De um certo ponto aqui tem razão. Disse que nem que resolvesse com 3 Base de Dados!

E agora, como resolvo isto?

2 - Quer que, por regra, os imóveis só estejam visíveis durante 60 dias no Front-End, depois desaparecem, mas não desaparecem totalmente, ficando na BD.

Como procedo para elaborar isto?

3 - Ter as opções de Guardar em .pdf e o Imprimir quando se regista a ficha do imóvel (a meu ver deve ser preferível na parte de visualização da ficha do imóvel)

Podem-me indicar como também posso tendo os dados na BD guardar/exportar para .pdf para que possa fazer a opção de guardar e posterior impressão?

Obrigado pela ajuda,

Cumprimentos,
AndreLC
 
1. Se usares MyIsam (acho que não funciona em innoDb), podes ter 2 chaves primárias, exemplo:

Código:
create table content (
    id integer auto_increment not null,
    id_agent integer not null,
    content text not null,
    primary key(id_agent,id)
);
Quando adicionares elementos só precisas de garantir que colocas o id do agente, e ele depois faz o resto.

2. É só teres uma coluna "available", quando está a 1 mostra, quando está a 0 não mostra, ou então crias um archive para colocar lá esses resultados, depois tens que ter um cronjob diário a fazer as funções que precisas.

3. Podes ter uma coluna na tabela indicando que é possível imprimir ou fazer download em pdf.
 
REE

1 - Não é tão simples, a ideia é não mostrar o ID do imóvel, mas sim um número calculado na altura de inserção, ou seja, antes de inserir tenho que verificar qual é o número máximo existente daquela combinação de agente e agência, somar um, e guardar junto com o registo. Se não existir nenhum, é o 1.

Mas não estou a ver como fazer.

Agradeço a vossa ajuda.

2 - Tenho que filtrar cuja data de inserção já foi há mais de 60 dias. Talvez na query o "WHERE DATEDIFF(CURDATE(), data_insercao) < 60" resolva correcto?
Mas isto para um campo que é do tipo DATE eu tenho um campo data que queria aproveitar que está em timestamp, como converto? Ou é preferível trabalhar com DATE? Posteriormente é necessário utilizar cronjobs?


Obrigado.
 
Última edição:
1. É simples sim, e é como disse
Insert(NULL, 1, 'Imovel 1')
Insert(NULL, 2, 'Imovel 2')
Insert(NULL, 1, 'Imovel 3')
Insert(NULL, 3, 'Imovel 4')
Insert(NULL, 1, 'Imovel 5')
Insert(NULL, 2, 'Imovel 6')

Na base de dados fica:
id|id_agent|content
1|1|Imovel 1
1|2|Imovel 2
2|1|Imovel 3
1|3|Imovel 4
3|1|Imovel 5
2|2|Imovel 6

2. Como vais usar as datas não sei (se é o php que define ou o mysql), mas basta guardar o timestamp e trabalhar com ele.
 
Não estou a perceber.

Eu possuo uma relação entre agências, agentes e imóveis (1 agência para n agentes, 1 agente para n imóveis e n imóveis para uma agência).

A tabela dos imóveis contém as chave estrangeiras da agência e do agente. Tenho:

CREATE TABLE `imoveis` (
`id` int(11) NOT NULL auto_increment,
`id_agencia` int(11) NOT NULL,
`id_agente` int(11) NOT NULL,
`id_director` int(11) NOT NULL,
`id_admin` int(11) NOT NULL,
`data_insercao` varchar(255) NOT NULL,
PRIMARY KEY (`id`),
KEY `id_agencia` (`id_agencia`),
KEY `id_consultor` (`id_consultor`),
) ENGINE=MyISAM AUTO_INCREMENT=11 DEFAULT CHARSET=utf8 AUTO_INCREMENT=11;

INSERT INTO `imoveis` (`id`, `id_agencia`, `id_agente`, `data_insercao`) VALUES
(1, 94, 998, '1332926140'),
(2, 98, 999, '1332926141'),
(3, 101, 1002, '1333383097'),
(4, 101, 1002, '1333545795'),
(5, 102, 1003, '1333125810'),
(6, 101, 1002, '1333461824'),
(7, 101, 1004, '1333545865'),
(8, 101, 1005, '1333547877'),
(9, 101, 1002,'1333545221'),
(10, 101, 1002, '1333547732'),

Ou seja, aqui na tabela dos imóveis acrescentaria um novo campo para fazer os tais campos, correcto? Mas depois se eliminar um imóvel desse agente a ordem irá ficar certa à mesma? A minha dificuldade é em termos de código o que poderei fazer, porque tenho que fazer esses tais cálculos quando faço a inserção, correcto? Estou confuso.

Obrigado, desde já, pela ajuda.
 
CREATE TABLE `imoveis` (
`id` int(11) NOT NULL auto_increment,
`id_agencia` int(11) NOT NULL,
`id_agente` int(11) NOT NULL,
`id_director` int(11) NOT NULL,
`id_admin` int(11) NOT NULL,
`data_insercao` varchar(255) NOT NULL,
PRIMARY KEY (`id_agente`, `id`),
KEY `id_agencia` (`id_agencia`),
KEY `id_consultor` (`id_consultor`),
) ENGINE=MyISAM AUTO_INCREMENT=11 DEFAULT CHARSET=utf8 AUTO_INCREMENT=11;

INSERT INTO `imoveis` (`id`, `id_agencia`, `id_agente`, `data_insercao`) VALUES
(NULL, 94, 998, '1332926140'),
(NULL, 98, 999, '1332926141'),
(NULL, 101, 1002, '1333383097'),
(NULL, 101, 1002, '1333545795'),
(NULL, 102, 1003, '1333125810'),
(NULL, 101, 1002, '1333461824'),
(NULL, 101, 1004, '1333545865'),
(NULL, 101, 1005, '1333547877'),
(NULL, 101, 1002,'1333545221'),
(NULL, 101, 1002, '1333547732');

Ficarias com:
Código:
1|94|998|1332926140
1|98|999|1332926141
1|101|1002|1333383097
2|101|1002|1333545795
1|102|1003|1333125810
3|101|1002|1333461824
1|101|1004|1333545865
1|101|1005|1333547877
4|101|1002|1333545221
5|101|1002|1333547732

O Mysql faz tudo sozinho, ele cria um contador por cada agente.
 
Uma coisa, o cliente vai ter acesso à estutura da base de dados ? ou vai apenas consultar dados da BD através do front office ???
Porque se ele não tiver acesso à estrutura da BD, pouco lhe interessa como implementas os campos, interessa-lhe apenas ver o que quer. No caso da tabela onde se codifica o agente, criavas um campo por exemplo numImoveis, e sempre que inserias um imóvel novo na tabela Imóveis, ele ia ao respectivo agente a adicionava 1 a esse campo (ou diminuia, conforme a operação). Uma espécie de trigger.
Assim tinhas sempre os 3 códigos que necessitas na tabela do agente como Agencia-Agente-NumImóveis.
Provavelmente não é mesmo nada disto hehehe
 
CREATE TABLE `imoveis` (
`id` int(11) NOT NULL auto_increment,
`id_agencia` int(11) NOT NULL,
`id_agente` int(11) NOT NULL,
`id_director` int(11) NOT NULL,
`id_admin` int(11) NOT NULL,
`data_insercao` varchar(255) NOT NULL,
PRIMARY KEY (`id_agente`, `id`),
KEY `id_agencia` (`id_agencia`),
KEY `id_consultor` (`id_consultor`),
) ENGINE=MyISAM AUTO_INCREMENT=11 DEFAULT CHARSET=utf8 AUTO_INCREMENT=11;

INSERT INTO `imoveis` (`id`, `id_agencia`, `id_agente`, `data_insercao`) VALUES
(NULL, 94, 998, '1332926140'),
(NULL, 98, 999, '1332926141'),
(NULL, 101, 1002, '1333383097'),
(NULL, 101, 1002, '1333545795'),
(NULL, 102, 1003, '1333125810'),
(NULL, 101, 1002, '1333461824'),
(NULL, 101, 1004, '1333545865'),
(NULL, 101, 1005, '1333547877'),
(NULL, 101, 1002,'1333545221'),
(NULL, 101, 1002, '1333547732');

Ficarias com:
Código:
1|94|998|1332926140
1|98|999|1332926141
1|101|1002|1333383097
2|101|1002|1333545795
1|102|1003|1333125810
3|101|1002|1333461824
1|101|1004|1333545865
1|101|1005|1333547877
4|101|1002|1333545221
5|101|1002|1333547732

O Mysql faz tudo sozinho, ele cria um contador por cada agente.

Mas não quero alterar esse id, esse fica para termos de manutenção à mesma.
 
O id do ímovel é para ser o id_agencia-id_agente-id_imovel e não o id na base de dados imoveis, no entanto o id_imovel está dependente do id_agente, isto para que com o tempo se houvesse 10000 imóveis nas agências todas e uma gente só tivesse 1 imóvel, aparecesse algo do genero 101-1010-10000, que dava a parecer que esse agente já tinha 10000 imóveis, tem outras coisas boas que é com o tempo o número de imóveis tende para infinito, no entanto se o id de imóvel depender do agente, irá sempre se manter um numero relativamente pequeno, senão daqui a 10 anos poderia aparecer um número do genero: 101-1010-1341212544321432, é certamente melhor ter 101-1010-120 (facilmente decorável e até de dizer ao telemóvel ou de escrever do que o outro).

As agências usam um padrão para id de imóvel, não vejo nenhum mal nisso, o programador só tem que programar esse padrão, que neste caso é super fácil pois basta ter 2 chaves primárias.


Não percebi a parte da manutenção, que termos de manutenção?
 
Última edição:
Uma coisa, o cliente vai ter acesso à estutura da base de dados ? ou vai apenas consultar dados da BD através do front office ???
Porque se ele não tiver acesso à estrutura da BD, pouco lhe interessa como implementas os campos, interessa-lhe apenas ver o que quer. No caso da tabela onde se codifica o agente, criavas um campo por exemplo numImoveis, e sempre que inserias um imóvel novo na tabela Imóveis, ele ia ao respectivo agente a adicionava 1 a esse campo (ou diminuia, conforme a operação). Uma espécie de trigger.
Assim tinhas sempre os 3 códigos que necessitas na tabela do agente como Agencia-Agente-NumImóveis.
Provavelmente não é mesmo nada disto hehehe

Não tem acesso a Base de Dados, só lhe interessa o Front-End. É mesmo isso! Agora como faço os cálculos correctos com esse numImoveis?

Obrigado.
 
O id do ímovel é para ser o id_agencia-id_agente-id_imovel e não o id na base de dados imoveis, no entanto o id_imovel está dependente do id_agente, isto para que com o tempo se houvesse 10000 imóveis nas agências todas e uma gente só tivesse 1 imóvel, aparecesse algo do genero 101-1010-10000, que dava a parecer que esse agente já tinha 10000 imóveis, tem outras coisas boas que é com o tempo o número de imóveis tende para infinito, no entanto se o id de imóvel depender do agente, irá sempre se manter um numero relativamente pequeno, senão daqui a 10 anos poderia aparecer um número do genero: 101-1010-1341212544321432, é certamente melhor ter 101-1010-120 (facilmente decorável e até de dizer ao telemóvel ou de escrever do que o outro).

As agências usam um padrão para id de imóvel, não vejo nenhum mal nisso, o programador só tem que programar esse padrão, que neste caso é super fácil pois basta ter 2 chaves primárias.

É para ser id_agencia-id_agente-id_imovel_campo_calculado! basta ter 2 chaves como assim? Eu tenho a tabela de imóveis com as duas chaves estrangeiras. Queria era um novo campo para que pudesse fazer as contas tal como o rosepwr referiu...

Obrigado pela ajuda.
 
Acho melhor falares melhor com eles porque o que estás a dizer não faz sentido nenhum, então um agente tem 10 imóveis e todos os imóveis tinham o id por exemplo 101-1001-10?
 
Não, não é essa a ideia. Não sei se me consegui explicar muio bem mas repara:O que tenho actualmente está a ir buscar o id do imovel e nao pode ser porque como está como auto increment se eu adicionar o imovel 50 ao agente 1001 tudo bem. Mas se inserir outro imovel para o agente 1002 o id sera 51 o que indicaria que esse mesmo agente ja teria 50 imoveis da posse dele e o que não é verdade, pois seria o primeiro imóvel. Daí um nono campo penso eu que cada vez que o imovel for adicionado aquele agente incrementa uma unidade penso eu. Mas depois se remover teria que também retirar. A ideia é que fique tudo ordenado nesse novo campo indicando o nr d imoveis que o agente possui: como ê auto increment nao posso cada vez que inserir um imóvel daquele respectivo agente o id volte a um e se ja for dois imovsis dois. agente 1001-ja tem 50 imoveis, o 1002-2 e por aí...Queria fazer esses caculos na tabela imoves messe novo campo, cada vez que inserir um imovel tenho que actualizar esse novo campo com o id correcto ordenado o nr de imoveis daquele agente.Não sei se me consegui explicar melhor.Obrigado pela ajuda.
 
Então, eu já dei a solução, onde está o problema? Tu não queres mudar o numero dos ids depois de definidos, se deres um id a um cliente, por exemplo 100-1000-10 e apagares o 100-1000-9, tu não queres que o 100-1000-10 passe para 100-1000-9, porque senão o cliente depois iria comprar o imóvel errado, os ids são para se manter sempre e nunca para fazer uma contagem, se queres uma contagem nos ids dos imóveis, fazes um count do número de imóveis desse agente e colocas no backoffice.
 
Sim tens razão e é exactamente isso que quero. Então qual será a melhor solução?

Podes exemplificar, por favor? Não percebi ainda muito bem o querias transmitir.

Obrigado pela ajuda e atenção.
 
CREATE TABLE `imoveis` (
`id` int(11) NOT NULL auto_increment,
`id_agencia` int(11) NOT NULL,
`id_agente` int(11) NOT NULL,
`id_director` int(11) NOT NULL,
`id_admin` int(11) NOT NULL,
`data_insercao` varchar(255) NOT NULL,
PRIMARY KEY (`id_agente`, `id`),
KEY `id_agencia` (`id_agencia`),
KEY `id_consultor` (`id_consultor`),
) ENGINE=MyISAM AUTO_INCREMENT=1 DEFAULT CHARSET=utf8;

INSERT INTO `imoveis` (`id`, `id_agencia`, `id_agente`, `data_insercao`) VALUES
(NULL, 94, 998, '1332926140'),
(NULL, 98, 999, '1332926141'),
(NULL, 101, 1002, '1333383097'),
(NULL, 101, 1002, '1333545795'),
(NULL, 102, 1003, '1333125810'),
(NULL, 101, 1002, '1333461824'),
(NULL, 101, 1004, '1333545865'),
(NULL, 101, 1005, '1333547877'),
(NULL, 101, 1002,'1333545221'),
(NULL, 101, 1002, '1333547732');

Vais ficar com os ids:

94-998-1 98-999-1 101-1002-1 101-1002-2 102-1003-1 101-1002-3 101-1004-1 101-1005-1 101-1002-4 101-1002-5Se organizares por agente:

94-998-1 98-999-1 101-1002-1 101-1002-2
101-1002-3
101-1002-4 101-1002-5 102-1003-1 101-1004-1 101-1005-1 Adicionando um novo imóvel a um novo agente 1006
INSERT INTO `imoveis` (`id`, `id_agencia`, `id_agente`, `data_insercao`) VALUES (NULL, 102, 1006, '1333426140');
O id fica:
102-1006-1

Quando tens PRIMARY KEY (`id_agente`, `id`) o que acontece é que tens uma chave primária única para essa dupla, se tivesses PRIMARY KEY (`id_agencia`,`id_agente`, `id`) tu tinhas uma chave primaria para essa tripla, podendo ter:
100-1000-1
101-1000-1
 
Uma coisa, o cliente vai ter acesso à estutura da base de dados ? ou vai apenas consultar dados da BD através do front office ???
Porque se ele não tiver acesso à estrutura da BD, pouco lhe interessa como implementas os campos, interessa-lhe apenas ver o que quer. No caso da tabela onde se codifica o agente, criavas um campo por exemplo numImoveis, e sempre que inserias um imóvel novo na tabela Imóveis, ele ia ao respectivo agente a adicionava 1 a esse campo (ou diminuia, conforme a operação). Uma espécie de trigger.
Assim tinhas sempre os 3 códigos que necessitas na tabela do agente como Agencia-Agente-NumImóveis.
Provavelmente não é mesmo nada disto hehehe

Tal e qual. Era mesmo isso que estava para dizer. Deduzo que o cliente não lhe interessa e tão pouco percebe ir ao backoffice ou seja consultar mesmo a BD e ver a estrutura da mesma.
O que interessa é a maneira como apresentas o output.
 
Tal e qual. Era mesmo isso que estava para dizer. Deduzo que o cliente não lhe interessa e tão pouco percebe ir ao backoffice ou seja consultar mesmo a BD e ver a estrutura da mesma.
O que interessa é a maneira como apresentas o output.

Mas lá está, quero a vossa opinião para construir um bom sistema de apresentação desse output que o cliente deseja. Pois nunca tinha feito algo desse género de "gerar" ou "camuflar" o id "verdadeiro" e dar-he a visualizar outro "calculado".
 
Vou ser sincero, do que li não percebi bem o problema a 100% mas eu pessoalmente não tocaria na estrutura da BD e faria essa alteração em código na plataforma...
 
Back
Topo