Você sabe o que é um Diagrama de Entidades e Relacionamentos?

O DER é a representação visual das tabelas e relações do seu banco de dados.

Ele é super importante quando você vai desenvolver um projeto com um banco de dados com várias tabelas e relações e de preferência criado antes mesmo de escrever as primeiras linhas de código.

Também não esqueça de mantê-lo atualizado sempre que alterar ou adicionar tabelas.

No seguinte caso, temos duas tabelas, sendo elas: Cliente e Pedidos.

Na tabela Cliente temos as seguintes colunas:

ID, Chave Primária (PK), do tipo inteiro e que não pode ser nula
Nome, limitado à 50 caracteres e que não pode ser nulo.

Na tabela Pedido temos:

ID, Chave Primária (PK), do tipo inteiro e que não pode ser nula
ID do cliente, chave estrangeira (FK), do tipo inteiro e que não pode ser nulo
Data, do tipo Date que não pode ser nulo.

É importante ressaltar que na ligação entre as tabelas deve ser especificado o tipo daquela relação. Um cliente pode ter zero ou muitos pedidos e um pedido deve ter um cliente.

ElDja ano passado

o que me pega é isso aqui

Também não esqueça de mantê-lo atualizado sempre que alterar ou adicionar tabelas.

isso é praticamente o mesmo que falar que só será atualizado uma vez na vida e outra na morte. Sempre que alguém rodar uma migration esse alguém, ou um outro alguém da equipe, precisará dedicar uma quantidade x de tempo para atualizar o DER manualmente?

Do ponto de vista do DBA. Dado que a maioria das ferramentas de gerenciamento de banco de dados relacionais (mssql management studio, mysql workbench, dbeaver etc... até plugins do vscode) ja me permitem ter essas informações. Por que alguém deveria se dedicar a manter o DER?

Um cliente pode ter zero ou muitos pedidos e um pedido deve ter um cliente.

Do ponto de vista do programador. Esse tipo de relação, e todo tipo de constraint, ja não deve estar mapeada nas configurações do ORM?

essa descrição mesma que você fez das tabelas Cliente e Pedidos ja não é até melhor do que representação gráfica do banco?

Arlysthon ano passado

Não acredito que essa simples descrição que eu fiz possa ser melhor ou equivalente ao DER, pois nela eu apenas descrevo que a tabela de produtos contém o id do cliente. Logo, se eu olhar apenas para a descrição da tabela de clientes, eu jamais iria imaginar que existe uma tabela de produtos atrelada a ele. Eu precisaria ler as descricões de todas as outras tabelas para ter ciência de quais tabelas se relacionam com o cliente. Com o DER, eu consigo olhar para a tabela de clientes e seguir as setas que estão conectadas com ela. E de forma imediata já saber qual o tipo de relação entre a tabela Cliente e a tabela X

Arlysthon ano passado

> Do ponto de vista do programador. Esse tipo de relação, e todo tipo de constraint, ja não deve estar mapeada nas configurações do ORM? Essa é uma das soluções, mas em meus projetos eu prefiro não depender do ORM para saber como o meu banco de dados está estruturado. Como citei no meu outro comentário, o simples fato do banco estar visualmente representado, facilita a identificação imediata das relações. Inclusive para evitar dependências ciclicas antes mesmo de começar a escrever o código.

Arlysthon ano passado

> Do ponto de vista do DBA. Dado que a maioria das ferramentas de gerenciamento de banco de dados relacionais (mssql management studio, mysql workbench, dbeaver etc... até plugins do vscode) ja me permitem ter essas informações. Por que alguém deveria se dedicar a manter o DER? Por enquanto ainda não trabalhei em uma empresa que tenha um profissional específico como DBA e a única interface de banco que eu tive contato foi com o PGAdmin. Nele eu consigo ter uma ideia visual das relações entre as tabelas? EDIT: Acabei de entrar no PGAdmin e consegui gerar um DER do meu banco. Só ficou meio bagunçado pq ele não posiciona muito bem cada tabela.