Fórum Trabalhar com cadastro de dados e imagens em tabelas diferentes #385127
30/08/2010
0
Bom dia pessoal,
Estou desenvolvendo um cadastro de alunos e cada registro deverá conter a foto.
Em pesquisas que fiz na net, muitos aconselham a criar um campo que contenha apenas o caminho da imagem, pois a tabela poderá ficar muito "pesada".
Mas em alguns sistemas que vi, abrindo a base de dados notei que o sistema trabalhava com 2 tabelas, uma contendo o cadastro em si, e a outra contendo as fotos referente ao cadastro.
Acredito que desta forma nem a tabela e nem o sistema ficarão sobrecarregados. Então é desta forma que pretendo montar o sistema.
Minha dúvida é, qual melhor maneira de buscar as fotos utilizando o ClientDataset, fazendo uma subconsulta no select ou criando um campo LooKup no próprio ClientDataset, ou alguma outra forma ?
Se tiver algum exemplo, melhor.
Obrigado,
Uelson
Uelson Cavalcante
Curtir tópico
+ 0
Responder
Posts
30/08/2010
Wilson Junior
Olha Uelson, eu ja utilizei 3 formas:
1ª Criar diretório para as imagens e salvar o caminho da imagem em um campo no registro:
- Positivo: para carregar a imagem fica mais rápido dependendo da sua rede;
- Negativo: as imagens não ficam centralizadas no banco de dados;
2ª Gravar a imagem no mesmo registro do aluno:
- Positivo: as imagens ficam centralizadas no banco de dados;
- Negativo:
+ o banco de dados fica muito grande;
+ o retorno do SQL pode ficar muito lento;
3ª Gravar a imagem em outra tabela e criar uma FK para o registro do aluno:
- Positivo:
+ as imagens ficam centralizadas no banco de dados;
+ o retorno do SQL com a imagem somente é utilizado quando necessario (utilizando JOIN);
- Negativo:
+ o banco de dados fica muito grande;
+ o retorno do SQL, somente dos dados do aluno e não da imagem, fica mais rápido;
+ o retorno do SQL com a imagem pode ficar muito lento;
Espero ter colaborado.
1ª Criar diretório para as imagens e salvar o caminho da imagem em um campo no registro:
- Positivo: para carregar a imagem fica mais rápido dependendo da sua rede;
- Negativo: as imagens não ficam centralizadas no banco de dados;
2ª Gravar a imagem no mesmo registro do aluno:
- Positivo: as imagens ficam centralizadas no banco de dados;
- Negativo:
+ o banco de dados fica muito grande;
+ o retorno do SQL pode ficar muito lento;
3ª Gravar a imagem em outra tabela e criar uma FK para o registro do aluno:
- Positivo:
+ as imagens ficam centralizadas no banco de dados;
+ o retorno do SQL com a imagem somente é utilizado quando necessario (utilizando JOIN);
- Negativo:
+ o banco de dados fica muito grande;
+ o retorno do SQL, somente dos dados do aluno e não da imagem, fica mais rápido;
+ o retorno do SQL com a imagem pode ficar muito lento;
Espero ter colaborado.
Responder
Gostei + 0
Clique aqui para fazer login e interagir na Comunidade :)