Tabela sem primary key

433 views
Skip to first unread message

Leandro Diniz Soares

unread,
Oct 23, 2008, 10:46:47 AM10/23/08
to zfbr...@googlegroups.com
Senhores,

Tenho uma tabela produtos e uma tabela de fotos.
Mas essa tabela eu não preciso de ter uma primary key.
Ele só tem dois campos:
id_produto
nome_foto

Assim quando tento fazer uma inserção dá erro exigindo que a tabela tenha uma PK.

O que sugerem?
Colocar um campo id (PK) em fotos?


--
[],
Leandro Diniz Soares
Desenvolvedor / Analista (Web)
leandro...@gmail.com

Wanderson

unread,
Oct 23, 2008, 10:58:14 AM10/23/08
to zfbr...@googlegroups.com
Acho que o ZF precisa de uma PK. Vi alguma coisa na WIki se não me engano,
falando sobre.

Em Thu, 23 Oct 2008 12:46:47 -0200, Leandro Diniz Soares
<leandro...@gmail.com> escreveu:

Diego Henrique Oliveira

unread,
Oct 23, 2008, 11:08:24 AM10/23/08
to zfbr...@googlegroups.com
porque voce não pode ter uma chave primaria nesta tabela?
Acho que facilitaria pra voce ate pra apagar fotos.

foto_id int not null auto_increment primary key
foto_produto int not null
foto_arquivo varchar not null


ate
 

Diego Henrique
E-mail/MSN: diegoho...@yahoo.com.br
Cel: (31) 8415 4732
Website: http://www.diegoholiveira.com





----- Original Message ----
From: Leandro Diniz Soares <leandro...@gmail.com>
To: zfbr...@googlegroups.com
Sent: Thursday, October 23, 2008 12:46:47 PM
Subject: [zfbrasil] Tabela sem primary key

Senhores,

Tenho uma tabela produtos e uma tabela de fotos.
Mas essa tabela eu não preciso de ter uma primary key.
Ele só tem dois campos:
id_produto
nome_foto

Assim quando tento fazer uma inserção dá erro exigindo que a tabela tenha uma PK.

Paulo Vitor Bettini de Albuqerque Lima

unread,
Oct 23, 2008, 12:44:25 PM10/23/08
to zfbr...@googlegroups.com
ao meu ver, o melhor nesse caso é criar uma chave primária composta por todos os campos dessa tabela.

2008/10/23 Diego Henrique Oliveira <diegoho...@yahoo.com.br>




--
Paulo Vitor Bettini de Albuquerque Lima

Everton Schipfer

unread,
Oct 23, 2008, 3:57:02 PM10/23/08
to zfbr...@googlegroups.com
coloca no seu model
protected $_sequence = false;

2008/10/23 Paulo Vitor Bettini de Albuqerque Lima <paulov...@gmail.com>



--
______________
Everton Schipfer
(41) 9673-0386

Kaléu Puskas Diedrich Caminha

unread,
Oct 23, 2008, 4:40:34 PM10/23/08
to zfbr...@googlegroups.com
Se as tabelas estão estruturadas como você colocou não ejo problema nenhum em o atributo nome_foto estar dentro da tabela produto..

Caso você queira que um produto tenha mais de uma foto então você será obrigado a acriar uma chave primária para a tabela que contém o nome da foto..

Acho que o Zend não tem opção para "não ter chave primária" pois isso (caso eu esteja errado, me corrijam) não faz sentido..pelo menos uma chave composta deveria existir..

;)



2008/10/23 Everton Schipfer <evesc...@gmail.com>

Paulo Vitor Bettini de Albuqerque Lima

unread,
Oct 23, 2008, 5:01:36 PM10/23/08
to zfbr...@googlegroups.com
De fato Kaléu, não faz sentindo, pois a idéia é que a chave primária seja um identificador único (porém pode se constituir de mais de um atributo). A chave primária deve identificar unicamente um registro, afim de entre outras coisas evitar redundancias, e oferecer uma forma de reduzir o acesso a informaçao desejada, já que normalmente é tambem criado um indice para a PK. Normalmente cria-se uma chave que seja incrementada automaticamente, porém nem sempre é o melhor caso, já que por exemplo, poderiamos ter um ambiente com restrições de armazenamento o qual restringisse a criação de um atributo de 32 bits para cada linha da tabela, dessa forma poderiamos utilizar outras chaves. No seu caso, eu acho desnecessario criar um atributo com auto incremento, porque cada linha será única pelo que entendi.


2008/10/23 Kaléu Puskas Diedrich Caminha <kaleu....@gmail.com>

Jonathan Gehard Kohler

unread,
Oct 23, 2008, 5:03:40 PM10/23/08
to zfbr...@googlegroups.com
Criando uma chave primária, as operaćões de SELECT serão muuuuito mais rápidas!! (a não ser que SEMPRE for necessário selecionar todos os campos da tabela!)
--
Abraços
Jonathan Gehard Kohler
jona...@inf.ufsc.br
jonatha...@gmail.com

Paulo Vitor Bettini de Albuqerque Lima

unread,
Oct 23, 2008, 5:17:14 PM10/23/08
to zfbr...@googlegroups.com
Caro Jonathan,

Criar uma chave primária não garante isso que você falou.

Ao executar uma query, temos alguns tipos de atitude que oneram o banco de dados, uma é a quantidade de registros e atributos retornados (o que independe de pks, ou indices), nesse caso o melhor a se fazer é mesmo buscar apenas o que importa, evitando o '*' nas clausulas Select.

E a outra é a foma que relacionamos as tabelas, nesse ponto é fundamental entender os conceitos de chaves primárias, estrageiras e indices. No mysql toda PK tem um indice o que facilita a busca e a associação entre as diversas tabelas.  Quando pesquisamos em alguma tabela (na clausua where) utilizando um campo que seja indice, seja ele pk, ou fk, realizamos a consulta por indice, que varre uma tabela menor e armazenada em cache. Dessa forma obtemos um ganho enorme de processamento. Os sgbds utlizam várias técnicas para manterem as tabelas de indices como por exemplo o uso de ABB e tabelas hash, onde registros podem ser mais facilmente encontrados.

Existem ainda outras coisas que podem tornar pesadas as consultas ao banco de dados, como por exemplo o abuso de funções built-in como por exemplo sum ou avg.

Caso ainda tenha alguma duvida sobre isso, por favor me mande um email.

2008/10/23 Jonathan Gehard Kohler <jona...@inf.ufsc.br>

Leandro Diniz Soares

unread,
Oct 23, 2008, 8:42:23 PM10/23/08
to zfbr...@googlegroups.com
Senhores,

Obrigado pelas respostas...
Neste caso um produto terá várias fotos.
E sempre vou buscar todas as fotos de um produto neste caso todos as fotos com id_produto = 10 (exemplo).

Estava pensando aqui... Eu poderia antes de salvar as fotos com os nomes originais usar um md5 (pegando os 12 caracteres) e criar um nome único... Assim posso usar o campo nome_foto como PK o que acham?

Seria uma solução elegante?

Ps. tenho um pouco de receio de mudar o nome da foto pois sistema de busca (ex. google) utilizam o nome de imagens para indexar o site...

Jonathan Gehard Kohler

unread,
Oct 24, 2008, 10:05:03 AM10/24/08
to zfbr...@googlegroups.com
Caro Paulo,

Concordo plenamente, nem todas as consultas farão uso de índice. Acho que me espressei mal. Utilizando a tabela que foi dada como exemplo, a maioria dos selects vai utilizar indice (pk) na cláusula WHERE, sendo assim, as consultas ficarão muito mais rápidas.

Leandro,

Essas suas fotos ficarão armazenadas em disco, ou no próprio banco de dados??

Se for armazená-las em disco, porque você não cria uma estrutura do tipo:
/photos/products/1/photo1.jpg
/photos/products/1/photo2jpg
/photos/products/1/photo3.jpg
/photos/products/2/photo1.jpg
/photos/products/2/photo2.jpg
/photos/products/2/photo3.jpg

E, para mostrar as fotos, vc faria um select no banco, pega o código do produto, e faz uma concatenaćão de string para abrir uma foto:
'/photos/produtos/' . $result->{Tabela_Produtos::COL_CODIGO} . '/photo' . $indice '.jpg;

E, para abrir todas as fotos de um produto, você somente abre todos os arquivos do diretório.
(É só uma solućão alternativa, pois eu não gosto de colocar arquivos binários em banco de dados)

Leandro Diniz Soares

unread,
Oct 24, 2008, 10:53:56 AM10/24/08
to zfbr...@googlegroups.com
Os arquivos (fotos) ficaram no servidor e não no banco...
A estrutura das pasta ainda estou estudando...
Tem essa forma como você colocou ou só uma pasta produtos e todas as fotos lá... (evito de  criar, excluir pastas constantemente...apesar de o trabalho para isso ser mínimo...)




2008/10/24 Jonathan Gehard Kohler <jona...@inf.ufsc.br>
Reply all
Reply to author
Forward
0 new messages