Relacionamentos no Mysql

[Altevir]

Pessoal boa tarde,

Sou iniciante no Mysql estou montado um banco de dados de um blog pessoal para começar a estudar Mysql + PHP.

Estou querendo montar um script SQL do banco num arquivo só, mas como estou querendo aprender os comandos sem usar nenhuma ferramenta grafica estou com duvida com relação ao relacionamento das tabelas, com minhas andanças pelo google descobri o comando:

FOREIGN KEY (id) REFERENCES myOtherTable(idOtherTable)

Com relação aos comandos comuns de criação de tabelas, inserção de dados e alguns outros já estou um pouco familiarizado pelos tutoriais que já consegui. Mas com relação aos Relacionamentos (1 pra 1, 1 pra N, N pra N) esta muito vago nos tutoriais, gostaria de saber o que muda neste comando para cada tipo de relacionamento que mencionei ou na hora de criar a tabela tem algum outro comando que eu defino isto.

Desde já agradeço a atenção de todos.

[paulobergo]

Olá...

Não vou sugerir que você não faça andanças pelo Google ou pelo Yahoo... agora, vou sugerir que você pegue o guia do próprio MySQL que é uma, digo duas, digo quatro ou dez mãos-na-roda!...

Veja um trecho:

******************

1.9.5.5. Foreign Keys

In MySQL Server 3.23.44 and up, the InnoDB storage engine supports checking of foreign key constraints, including CASCADE, ON DELETE, and ON UPDATE. See Section 14.2.6.4, “FOREIGN KEY Constraints”.

For storage engines other than InnoDB, MySQL Server parses the FOREIGN KEY syntax in CREATE TABLE statements, but does not use or store it. In the future, the implementation will be extended to store this information in the table specification file so that it may be retrieved by mysqldump and ODBC. At a later stage, foreign key constraints will be implemented for MyISAM tables as well.

Foreign key enforcement offers several benefits to database developers:

Assuming proper design of the relationships, foreign key constraints make it more difficult for a programmer to introduce an inconsistency into the database.

Centralized checking of constraints by the database server makes it unnecessary to perform these checks on the application side. This eliminates the possibility that different applications may not all check the constraints in the same way.

Using cascading updates and deletes can simplify the application code.

Properly designed foreign key rules aid in documenting relationships between tables.

******************

* Em tempo... eu uso a versão em inglês, mas existe também a versão em português... ok?

Não deixa de dar uma olhada...

E seja bem-vindo!

[Altevir]

Paulobergo primeiramente muito obrigado pela sua atenção, como você indicou eu consultei o guia da MySQL, acabei sanando outras duvidas a respeito de alguns comandos, mas com relação aos relacionamentos me pareceu um pouco vago e ainda estou com duvida sobre o comando que mencionei, eu queria saber se para definir 1 pra 1 ele e daquela forma e quando é 1 pra N ele muda algo.

Abaixo esta o modelo do comando que usei para criar uma tabela já com o relacionamento com outra:

CREATE TABLE myTable (

id INT NOT NULL,

nome CHAR(200) NOT NULL,

valor DECIMAL,

PRIMARY KEY(id),

INDEX (nome),

FOREIGN KEY (id)

REFERENCES myOtherTable(idOtherTable)

ON UPDATE CASCADE ON DELETE RESTRICT

) TYPE=INNODB;

Como esta no comando eu usei o tipo Innodb, que e o tipo que aceita o relacionamentos.

Para finalizar minha duvida é o que muda no comando( FOREIGN KEY (id) REFERENCES myOtherTable(idOtherTable) ON UPDATE CASCADE ON DELETE RESTRICT ) quando um relacionamento é 1 para 1 e quando e 1 para n.

Desculpe-me se tem algo referente a isso no guia do Mysql que acabei não observando. :unsure:

Grato pela atenção!

Editado Outubro 22, 2008 por Altevir

[Denis Courcy]

Oi 'Altevir',

Se você normalizar corretamente vai perceber que o relacionamento 1 : 1 somente ocorre quando há a figura de generalização/especialização.

A característica básica deste tipo de relacionamento é que a chave primária da tabela que representa a generalização é, também a chave primária da tabela que faz a especialização.

No relacionamento 1: N a chave primária da tabela mãe difere da chave primária da tabela filha. A chave primária da tabela mãe pode até fazer parte da chave primária da tabela filha, mas será somente mais um atributo nesta chave/Tabela.

A forma de representar esta constraint no MySQL só difere (se é 1:1 ou 1:N) na forma como você representará as cláusulas ON DELETE e ON UPDATE.

Em 1:1 é comum usar ON DELETE CASCADE ON UPDATE CASCADE.

Em 1:N isto dependerá do modelo do projeto.

[Denis Courcy]

Oi 'Altevir',

Complementando o post que escrevi anteriormente, normalmente, para relacionamentos 1:N eu uso ON DELETE NO ACTION. A cláusula ON UPDATE vai depender do tipo de sistema que estiver modelando.

[Altevir]

Denis boa tarde, não querendo abusar como ficaria na seguinte situação, tenho as seguintes tabelas do blog que estou montando para começar a estudar PHP+Mysql com os respetivos campos:

Usuários

Nome

e-mail

login

senha

Links

Nome

Url

Descrição

Categorias

Nome da Categoria

Posts

Titulo

Data/hora

Conteudo

Permalinks (palavras associadas)

Dono(Usuário)

Categoria do Post

Resposta Comentários

Usuário

Resposta

Comentario Dono

Eu sei que um usuário pode ter N posts, que um post poder uma ou + categorias.

Segue abaixo parte do script que estou montando para testar:

CREATE TABLE posts(

postid INT NOT NULL PRIMARY KEY,

titulo VARCHAR(30) NOT NULL,

data_hora datetime,

conteudo text,

permalinks VARCHAR(30),

dono VARCHAR(30),

categoriaid VARCHAR(20),

FOREIGN KEY (categoriaid) REFERENCES categorias(categoriaid) ON UPDATE CASCADE ON DELETE RESTRICT,

FOREIGN KEY (postid) REFERENCES usuario(codigoid) ON UPDATE CASCADE ON DELETE RESTRICT,

ver char(3) DEFAULT 'off'

)TYPE=INNODB;

Gostaria de saber se esta correto o que estou fazendo?