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

Aplicaria as chaves compostas na própria tabela ou numa terceira tabela?

Ainda não apliquei porque queria manter o campo "id" original e não neste mesmo... Mas para isso quando insiro um registo posso utilizar outro campo "id_imovel" e utilizar a função mysql_insert_id() para obter o "id" e então utilizar a chave composta no "id_imovel", correcto?

Obrigado pela ajuda.

xBoShY disse:
A ideia é permanecer com o mesmo código desde a sua criação. Este código é, em parte, derivado de chaves primárias (tal como exemplifiquei, no meu caso seria uma chave composta num tabela intermediaria para relações N:N)
A outra parte é dependente do agente, e é calculada para o agente (daí o uso da view para gerar esta parte do código).


Já devias saber que views não podem ser ordenadas. No caso que exemplifiquei, será naturalmente ordenada pelas chaves compostas.


O cliente certamente que saberá vender imoveis, e Dados, BD e afins não lhe tiram o sono nem a vontade de ter as coisas como ele deseja.
Quanto à solução, o user veio pedir opiniões... está explicito no titulo tópico, e não é preciso que lhe relembrem...


Concluindo, ainda não vi razão para o user experimentar o codigo sql que postei e expor duvidas relacionadas com esse código.
Ou então, ainda não vi outra solução prática e exemplificada em todo o resto desta thread...

Ajudem-se a vocês proprios e não percam tempo com bitaites.
Clicar para expandir...
 
Ainda não percebi bem a tua ideia das cópias dos ids...

Se puderes exemplificar, agradeço.

Obrigado pela ajuda e atenção.

naoliveira disse:
Vou dar um exemplo do que escrevi:

suponhamos que o inserimos um novo registo com o id=75, este id é também guardado no campo id_original=75, mais tarde se este imóvel passar para outro vendedor, em vez de alterar o registo, cria uma copia deste, que pode, p.ex, ter o id=123, no entanto o id_original mantém-se o 75, faz as alterações que tem de fazer neste novo id (123). Se mais tarde este imóvel voltar a sofrer alguma alteração, será sobre o id 123, cria uma cópia do registo 123, no entanto o id_original continuará a ser sempre 75. Deste modo consegue sempre saber as alterações de um determinado imóvel.


Voltando a este problema, se um cliente fizer uma reclamação, se for utilizado o método que exemplifiquei (nunca alterar um registo, mas criar uma cópia), consegue sempre chegar ao registo da reclamação.
Clicar para expandir...
 
não é cópia de ids é cópia de registo, por ex, se o imóvel com id=75 pertencer ao agente 100 quando quiseres alterar o imóvel para o agente 130, em vez de alterares no registo id=75 o código do agente (e respectivo código do imóvel), crias antes um registo novo em que copias os dados do registo id=75 e alteras só os campos que vão reflectir as novas alterações (neste caso parece-me que seria o código do agente e o código do imóvel). Para conseguires saber as alterações que já ocorreram sobre um imóvel deves manter o id_original sempre igual ao id do 1º registo desse imóvel.
 
Mas assim vou ficar com uma base de dados muito pesada!

Estava a reparar que logo no início disseram-me que as chaves compostas possívelmente não funcionariam em ENGINE=InnoDB, e eu tenho em InnoDB e agora como descalço esta bota?

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.zwame.pt/showthread.php?t=720292

Obrigado pela compreensão, ajuda e atenção.
 
Última edição:
Acho que não, mas é melhor precaver-me desse aspecto.

Sim, o histórico será o mais importante...

naoliveira disse:
Mas achas que vai haver muitos imóveis a passar de um agente para o outro?
Por outro lado, tens de decidir o que preferes (ou o que é mais importante) o peso da bd ou o perder o histórico de um imóvel?
Clicar para expandir...
 
OK!

As chaves compostas funcionam em ENGINE=InnoDB, correcto?

Quanto ao ponto 3 que referi ao início do tópico sobre o PDF, utilizei a classe dompdf e fiz um teste numa página e demorou-me cerca de 20 segundos a gerar o pdf, não é tempo demais? Não posso "acelerar" o processo? É que este tempo de espera é crucial para o utilizador...

naoliveira disse:
Pois, mas não tens bem a noção das capacidades dos SGBD, por ex, num site onde tenho instalado o phplist, a lista de eventos já chegou a ter 300mil registos e não era por isso que sentia um grande peso na bd.
Clicar para expandir...
 
Última edição:
Exacto era como queria... Aqueles três botoes com as mesmas funções.

O botão de imprimi que irá exportar o html para uma página e imprimir (como faço este? deve ser relativamente simples, mas estou a bloquear), o pdf e o enviar a um amigo...

Não sei o que possa ser para gerar o pdf tenho relativamente isto:

Código: 
    <?php
    
    ini_set("memory_limit", "512M"); # Define o limite de uso da memória em execução para 128 Mb.
    ini_set('max_execution_time',3600); # Define o tempo máximo que um script pode demorar a processar até ser terminado por timeout.
    
    require_once("dompdf/dompdf_config.inc.php");
    
    $html = ob_get_clean();
     
    $dompdf = new DOMPDF();
    $dompdf->load_html($html);
    $dompdf->set_paper('a4', 'portrait'); //Página na Vertical    
    $dompdf->render();
    $dompdf->stream("exemplo-01.pdf");
    ?>

Com o dompdf dá para predefinir os cabeçalhos e rodapé?

Qual a melhor maneira de gerar os pdfs na vossa opinião? Classe do php mesmo para pdf, FPDF, dompdf ou mPDF, por exemplo?

Obrigado.
 
Última edição:
AndreLC disse:
Aplicaria as chaves compostas na própria tabela ou numa terceira tabela?
Clicar para expandir...
No teu primeiro post:
AndreLC disse:
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...
Clicar para expandir...
Usa esta mesma query e cria uma view que devolva as 3 colunas com ID da Agência, ID do Agente e ID do Imóvel.
Essa view é a mesma a que me referi no meu exemplo como agencias_agentes_imoveis.

AndreLC disse:
Ainda não apliquei porque queria manter o campo "id" original e não neste mesmo... Mas para isso quando insiro um registo posso utilizar outro campo "id_imovel" e utilizar a função mysql_insert_id() para obter o "id" e então utilizar a chave composta no "id_imovel", correcto?

Obrigado pela ajuda.
Clicar para expandir...
Eu não alterei o id original... apenas calculo um novo id a cada select na view.

A forma como inseres os registos não muda em nada... Apenas quando queres apagar imoveis ou o imovel muda de agencia ou agente.
No caso de apagar, utilizas uma flag ou a tabela de inactivos. É a teu critério.

No caso de mudança de agencia ou agente, considera que apagaste o imovel e o crias outra vez.

Atenção que isto é uma solução que tem em vista não alterar a estrutura das tuas tabelas (eu abstrai-me por completo neste ponto). Isto está longe de ser ideal.
Sem conhecer a estrutura das tabelas e as suas relações, pouco mais te posso ajudar.
 
Inicie sessão ou registe-se para poder participar.
Back
Topo