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

[Eduardo Villa 2]

1) Me explique, por favor, qual a real necessidade de alocar este código?

 

2) Você irá desenvolver uma query normal e direcionar para o arquivo no item comando.

Tente também

SELECT * FROM tabela WHERE data BETWEEN CURDATE() AND DATE_SUB(CURDATE(), INTERVAL 30 DAY)

 

3) Exemplo de como funciona a biblioteca: LINK EXTERNO

[hinom 5]

#20

 

1. vou sugerir só mais uma vez.

Modele conforme todos aqui já sugeriram.

Analisando as dúvidas que tem sobre a questão 2, subentendo que seja inexperiente tanto na parte técnica quanto na parte de negócios.

 

Por isso agora posso afirmar que está pegando o caminho errado se insistir nesse modelo.

 

 

2. aprenda primeiro o que é e como executar o php em linha de comando:

acho que isso lhe dará uma visão mais ampla do que estamos falando..

[Rafael Impacto 15]

Bom dia,

 

Tenho algumas dicas para você resolver seus problemas.

 

Antes de começar, só gostaria de ressaltar o que o amigo @Vinicius Ianni disse e apoiar suas palavras, se é uma necessidade do cliente, seu trabalho como desenvolvedor é encontrar uma alternativa a isso. tome isso como desafios e aumento de experiência para projetos futuros, se ver sem saída não adianta nada ou com criticas ao cliente só vai dificultar as coisas ainda mais com os recursos disponíveis hoje em dia em programação não acredito que exista algo que não se possa dar um jeito.

 

Não estou criticando sua opinião, mais por experiência própria já passei por situações assim e não me ajudaram a crescer, encare como uma dica.

 

Bora la.

 

Trabalhei em um sistema de e-commerce que precisa de algo similar a sua questão dos códigos, para cada categoria cadastrada eu tinha uma sigla e o código do produto que era um campo varchar precisa incrementar +1 a sigla a cada novo produto e como já existia um cadastro de produtos foi solicitado que o campo ficasse em aberto caso precisa-se de alguma alteração no código.

 

Minha solução: enxerguei um padrão nas siglas que era a quantidade de caracteres, no meu caso 2 e isso é uma coisa importante, padrões facilitam nas condições para resolver o problema.

 

No cadastro de produtos tinha um select com as categorias, utilizei ajax jquery para que no change deste select ele enviasse para outra página o código da categoria escolhida, nesta outra página existe uma função que recebe a categoria, recupera sua sigla e faz uma busca na tabela de produtos para encontrar o último produto cadastrado nesta com essa categoria e recuperar seu código.

 

Se não existir nenhum produto, ótimo, se pega a sigla, adiciona o número 1 e devolve o resultado via ajax e o adiciona ao campo código.

 

Caso exista algum produto se faz um tratamento no código retornado, como a sigla são sempre 2 caracteres utilizei substr para remover a sigla e só me sobra o número, incremento mais um e devolvo o resultado para o ajax e o adiciono ao campo código.

 

No seu caso está facil fazer algo similar, adicionaria o campo código e implementaria algo neste sentido já que os padrões estão claros no modelo que seu cliente precisa.

 

-----------------------------------------------------------------------------

 

No caso dos 60 dias, você pode adicionar um campo date para cadastrar até qual data o imóvel vai aparecer, na hora de cadastrar esse campo pode vir preenchido com a data atual + 60 dias, você pode calcular isso utilizando mktime

 

E na hora de selecionar os imóveis você coloca a condição que a data cadastrada precisa ser >= CURDATE().

 

Com isso você resolve o problema e ainda deixa aberto no back-end a possibilidade do imóvel voltar a ser exibido se trocando a data.

 

-----------------------------------------------------------------------------

 

PDF - A classe FPDF realmente é legal, mais acho ela meio limitada referente a posicionamento.

 

Sugiro que utilize a classe DOM PDF que consegue reproduzir html e gerar um pdf melhor diagramado.

 

Espero ter ajudado, até mais

 

 

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?

 

1 - Penso que 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 - 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?

 

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.

 

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,

AndreLC90

 

Bom dia,

 

Tenho algumas dicas para você resolver seus problemas.

 

Antes de começar, só gostaria de ressaltar o que o amigo @Vinicius Ianni disse e apoiar suas palavras, se é uma necessidade do cliente, seu trabalho como desenvolvedor é encontrar uma alternativa a isso. tome isso como desafios e aumento de experiência para projetos futuros, se ver sem saída não adianta nada ou com criticas ao cliente só vai dificultar as coisas ainda mais com os recursos disponíveis hoje em dia em programação não acredito que exista algo que não se possa dar um jeito.

 

Não estou criticando sua opinião, mais por experiência própria já passei por situações assim e não me ajudaram a crescer, encare como uma dica.

 

Bora la.

 

Trabalhei em um sistema de e-commerce que precisa de algo similar a sua questão dos códigos, para cada categoria cadastrada eu tinha uma sigla e o código do produto que era um campo varchar precisa incrementar +1 a sigla a cada novo produto e como já existia um cadastro de produtos foi solicitado que o campo ficasse em aberto caso precisa-se de alguma alteração no código.

 

Minha solução: enxerguei um padrão nas siglas que era a quantidade de caracteres, no meu caso 2 e isso é uma coisa importante, padrões facilitam nas condições para resolver o problema.

 

No cadastro de produtos tinha um select com as categorias, utilizei ajax jquery para que no change deste select ele enviasse para outra página o código da categoria escolhida, nesta outra página existe uma função que recebe a categoria, recupera sua sigla e faz uma busca na tabela de produtos para encontrar o último produto cadastrado nesta com essa categoria e recuperar seu código.

 

Se não existir nenhum produto, ótimo, se pega a sigla, adiciona o número 1 e devolve o resultado via ajax e o adiciona ao campo código.

 

Caso exista algum produto se faz um tratamento no código retornado, como a sigla são sempre 2 caracteres utilizei substr para remover a sigla e só me sobra o número, incremento mais um e devolvo o resultado para o ajax e o adiciono ao campo código.

 

No seu caso está facil fazer algo similar, adicionaria o campo código e implementaria algo neste sentido já que os padrões estão claros no modelo que seu cliente precisa.

 

-----------------------------------------------------------------------------

 

No caso dos 60 dias, você pode adicionar um campo date para cadastrar até qual data o imóvel vai aparecer, na hora de cadastrar esse campo pode vir preenchido com a data atual + 60 dias, você pode calcular isso utilizando mktime

 

E na hora de selecionar os imóveis você coloca a condição que a data cadastrada precisa ser >= CURDATE().

 

Com isso você resolve o problema e ainda deixa aberto no back-end a possibilidade do imóvel voltar a ser exibido se trocando a data.

 

-----------------------------------------------------------------------------

 

PDF - A classe FPDF realmente é legal, mais acho ela meio limitada referente a posicionamento.

 

Sugiro que utilize a classe DOM PDF que consegue reproduzir html e gerar um pdf melhor diagramado.

 

Espero ter ajudado, até mais

 

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?

 

1 - Penso que 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 - 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?

 

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.

 

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,

AndreLC90

[AndreLC90 0]

1 - Mas não entendo ajax nem jQuery!

 

E aqui não posso limitar o nr, pois tanto poderão ter 20, como 100 ou 1000 imóveis...

 

Não poderia ser algo do género?

 

$lastid=mysql_query("SELECT id_calculado FROM Imoveis WHERE id_agente ='".$idagente."' ORDER BY id_calculado DESC LIMIT 1");
if(mysql_num_rows($lastid))
{
$lastid = mysql_fetch_array($lastid);
$newid = $lastid['id_calculado']+1;
}
else
{
$newid = 1;
}
mysql_insert(...); 

 

Estou desesperando...

 

2 e 3 - Já tinha ouvido falar desse Dom Pdf. Obrigado vou estudar esta fucionalidade e biblioteca.

[Vinicius Ianni 189]

Essa query você limitaria pelo primeiro registro encontrado, que pode não ser o ultimo inserido.

 

Se não me engano, o mysql tem a clausula MAX que deve atender melhor o que procura.

[AndreLC90 0]

Mas se usar o MAX LIMIT 1, que devolve o último ID, seja 40 e lhe somo um, sendo o próximo 41. Mas depois se apagar esse imóvel e criar outro por cima, ficaria com o mesmo ID 41 que o anterior, que na verdade já identificou outro imóvel anteriormente (e não seria único por esse motivo). Por isso não poderá ser...

 

Não estou a ver como resolver... :ermm:

[Eduardo Villa 2]

A função MAX não e vinculada ao LIMIT como você fez MAX LIMIT 1

sql ="SELECT MAX(numero) AS numeromax FROM tabela";

[AndreLC90 0]

Por exemplo se fizer:

 

SELECT CONCAT(CONCAT(CONCAT(CONCAT(id_agencia, '-'), id_corrector), '-'), MAX(id)) AS Referencia
FROM imoveis
GROUP BY id_corrector;

 

Obtenho isso do máximo é certo. Mas não preciso de efectuar nenhuma contas? É que assim vou estar sempre a apresentar o mesmo id em todos os imóveis ou estou incorrecto?

[AndreLC90 0]

Uma vez ouvi que as chaves compostas possivelmente não funcionariam em ENGINE=InnoDB, e eu tenho em InnoDB e agora como faço aí?

 

Uma questão que estou encalhado e peço desculpa desde ja colocar aqui o outro tópico, mas podem-me ajudar aqui, por favor?

 

http://forum.imasters.com.br/topic/463882-relacionamento-nn-terceira-tabela/page__gopid__1839873#entry1839873

 

Obrigado pela compreensão, ajuda e atenção.