Padrões de design de banco de dados relacional? [fechadas]

283

Os padrões de design geralmente estão relacionados ao design orientado a objetos.
Existem padrões de design para criar e programar bancos de dados relacionais ?
Muitos problemas certamente devem ter soluções reutilizáveis.

Exemplos incluem padrões para design de tabelas, procedimentos armazenados, gatilhos, etc ...

Existe um repositório online desses padrões, semelhante ao martinfowler.com ?

Exemplos de problemas que os padrões podem resolver:

Armazenamento de dados hierárquicos (por exemplo, tabela única com tipo vs tabelas múltiplas com chave 1: 1 e diferenças ...)
Armazenando dados com estrutura variável (por exemplo, colunas genéricas xml x colunas delimitadas ...)
Desnormalizar dados (como fazê-lo com o mínimo impacto, etc ...)

design-patterns database-design rdbms

— Sklivvz
fonte

Vou reivindicar o melhor Q & A aqui para armazenamento de dados hierárquico: stackoverflow.com/questions/4048151/...

— orangepips

1

De acordo com nossa orientação no tópico , " Algumas perguntas ainda estão fora do tópico, mesmo que se encaixem em uma das categorias listadas acima: ... Perguntas nos pedindo para recomendar ou encontrar um livro, ferramenta, biblioteca de software, tutorial ou outro recursos externos são off-topic ... "

— Robert Columbia

@RobertColumbia a pergunta era sobre o tema em 2008, quando perguntado ...

— Sklivvz

Confira a lista de recursos padrão de design em bancos de dados relacionais e muitas áreas de engenharia de software github.com/DovAmir/awesome-design-patterns

— dov.amir

150

Há um livro na Signature Series de Martin Fowler chamado Refactoring Databases . Isso fornece uma lista de técnicas para refatorar bancos de dados. Não posso dizer que ouvi tanto uma lista de padrões de banco de dados.

Eu também recomendaria altamente os padrões de modelo de dados de David C. Hay e o acompanhamento de um mapa de metadados, que se baseia no primeiro e é muito mais ambicioso e intrigante. O Prefácio por si só é esclarecedor.

Também é um ótimo lugar para procurar alguns modelos de banco de dados pré-enlatados. O Volume 1 da série de livros de recursos de modelo de dados de Len Silverston contém modelos de dados universalmente aplicáveis (funcionários, contas, remessa, compras, etc.), o Volume 2 contém modelos de dados específicos do setor (contabilidade, assistência médica, etc.), o Volume 3 fornece padrões de modelo de dados.

Por fim, embora este livro seja ostensivamente sobre UML e modelagem de objetos, o Modeling in Color With UML de Peter Coad fornece um processo orientado por "arquétipo" de modelagem de entidades, partindo da premissa de que existem 4 arquétipos principais de qualquer modelo de objeto / dados

— Michael Brown
fonte

1

O livro é intitulado [Refactoring Databases: Evolutionary Database Design] [1] por Scott W. Ambler e Pramod J. Sadalage e é realmente muito bom. [1]: ambysoft.com/books/refactoringDatabases.html

— Panos

3

Em relação ao livro Ambler: Não, você não pode listar "inserir uma coluna" ou "criar restrição FK" como padrão pelo mesmo motivo. O livro Gang of 4 não lista o loop "for" como padrão.

— Tegiri Nenashi

Não é um padrão, é uma refatoração. Como método de extração ou renomear parâmetro. Refatoração e padrões andam de mãos dadas.

— Michael Brown

Um a acrescentar: "Analysis Patterns", de Fowler. Semelhante ao material do Hay

— Neil McGuigan

2

O Volume 3 de Len Silverston é o único que eu consideraria "Design Patterns". Os dois primeiros mostram modelos de dados de amostra que eram comuns no período em que os livros foram escritos. O volume 3, na verdade, possui vários padrões de design para um determinado cenário de problema. Por exemplo, o capítulo 4 aborda as hierarquias / agregações / cenários ponto a ponto e, em seguida, oferece vários designs que abordam aqueles COM prós e contras de cada um.

— DarrellNorton

46

Os padrões de design não são soluções trivialmente reutilizáveis.

Os padrões de design são reutilizáveis, por definição. São padrões que você detecta em outras boas soluções.

Um padrão não é trivialmente reutilizável. No entanto, você pode implementar seu design descendente seguindo o padrão.

Os padrões de design relacional incluem coisas como:

Relacionamentos um-para-muitos (detalhes mestre, pai-filho) usando uma chave estrangeira.
Relacionamentos muitos-para-muitos com uma tabela de ponte.
Relacionamentos um-para-um opcionais gerenciados com NULLs na coluna FK.
Esquema em estrela: dimensão e fato, design OLAP.
Projeto OLTP totalmente normalizado.
Várias colunas de pesquisa indexada em uma dimensão.
"Tabela de pesquisa" que contém PK, descrição e valor (es) do código usado por um ou mais aplicativos. Por que ter código? Não sei, mas quando eles precisam ser usados, essa é uma maneira de gerenciar os códigos.
Uni-table. [Alguns chamam isso de antipadrão; é um padrão, às vezes é ruim, às vezes é bom.] Esta é uma tabela com muitas coisas pré-unidas que violam a segunda e a terceira forma normal.
Tabela de matriz. Esta é uma tabela que viola a primeira forma normal por ter uma matriz ou sequência de valores nas colunas.
Banco de dados de uso misto. Este é um banco de dados normalizado para processamento de transações, mas com muitos índices extras para geração de relatórios e análises. É um anti-padrão - não faça isso. As pessoas fazem isso de qualquer maneira, então ainda é um padrão.

A maioria das pessoas que cria bancos de dados pode facilmente dizer meia dúzia de "É mais um desses"; esses são padrões de design que eles usam regularmente.

E isso não inclui padrões administrativos e operacionais de uso e gerenciamento.

— S.Lott
fonte

Alguns outros padrões que eu vi são tabelas filho multiparental (ou seja, como notas globais com um tipo de objeto e um objeto que podem ser vinculados a qualquer outra tabela) ou um FK auto-referencial (ou seja, employee.manager -> employee. Eu iria). Também usei uma tabela de configuração singleton que possui muitas colunas.

— R00fus

1

Por que exatamente um banco de dados de uso misto é um anti-padrão. O que devo fazer se quiser extrair relatórios de um banco de dados?

— olive

3

@lhnz: Você não pode puxar um monte de grandes relatórios a partir de um projeto de banco de dados transacional - bloqueio para o relatório vai abrandar transações. Junções complexas (executadas repetidas vezes) são outra batida contra o desempenho da transação. Você não pode fazer as duas coisas em um banco de dados. Para fazer muitos relatórios grandes, você deve mover os dados para um esquema em estrela. O padrão de esquema em estrela é otimizado para geração de relatórios. E mover os dados remove qualquer contenção de bloqueio.

— S.Lott

A normalização do esquema reduziria a contenção de bloqueio de linhas se você estivesse fazendo as tabelas conterem dados mais "coesos"? Meu pensamento é que, se uma tabela grande estava atendendo gravações em 2 tipos de conjuntos de dados, mas ambos estão na mesma linha, isso resultaria em contenção de bloqueio desnecessária.

— CMCDragonkai

6

O AskTom é provavelmente o recurso mais útil sobre as práticas recomendadas nos bancos de dados Oracle. Normalmente, digito "asktom" como a primeira palavra de uma consulta do Google em um tópico específico.

Não acho que seja realmente apropriado falar de padrões de design com bancos de dados relacionais. Os bancos de dados relacionais já são a aplicação de um "padrão de design" a um problema (o problema é "como representar, armazenar e trabalhar com dados enquanto mantém sua integridade" e o design é o modelo relacional). Outras abordagens (geralmente consideradas obsoletas) são os modelos de navegação e hierárquica (e tenho certeza de que existem muitas outras).

Dito isto, você pode considerar o "Data Warehousing" como um "padrão" ou abordagem um pouco separada no design do banco de dados. Em particular, você pode estar interessado em ler sobre o esquema Star .

— Galghamon
fonte

4

Depois de muitos anos de desenvolvimento de banco de dados, posso dizer que existem alguns problemas e algumas perguntas que você deve responder antes de começar:

questões:

Deseja usar no futuro outro DBMS? Se sim, então não usa para itens SQL especiais do DBMS atual. Remova a lógica do seu aplicativo.

Não usa:

espaços em branco nos nomes de tabelas e nomes de colunas
Caracteres não Ascii nos nomes de tabela e coluna
vinculação a uma letra minúscula ou maiúscula específica. E nunca use 2 tabelas ou colunas que diferem apenas em minúsculas e maiúsculas.
não usa palavras-chave SQL para nomes de tabelas ou colunas como "FROM", "ENTRE", "EXCLUIR" etc.

recomendações:

Use NVARCHAR ou equivalentes para suporte a unicode, para não ter problemas com páginas de código.
Dê a cada coluna um nome exclusivo. Isso facilita a junção para selecionar a coluna. É muito difícil se todas as tabelas tiverem uma coluna "ID" ou "Nome" ou "Descrição". Use XyzID e AbcID.
Use um pacote de recursos ou igual a expressões SQL complexas. Facilita a troca para outro DBMS.
Não lança duro em nenhum tipo de dados. Outro DBMS não pode ter esse tipo de dados. Por exemplo, os dados da Oracle não têm apenas um número SMALLINT.

Espero que este seja um bom ponto de partida.

— Horcrux7
fonte

7

Embora seus comentários sejam bastante instrutivos e úteis, eles não são padrões de design. São práticas recomendadas. Obrigado,

— Sklivvz

7

Não concordo com a recomendação para nomes de colunas exclusivos. Prefiro dizer customer.id para desambiguar do que dizer customerid, mesmo quando não há nada para desambiguar.

— Paul Tomblin 28/09/08

1

Sua pergunta é um pouco vaga, mas suponho que UPSERTpossa ser considerado um padrão de design. Para idiomas que não são implementados MERGE, existem várias alternativas para resolver o problema (se existir uma linha adequada;; UPDATEoutro INSERT).

— Sören Kuklau
fonte

UPSERT é um comando e parte da linguagem SQL. Não é um padrão.

— Todd R

O UPSERT é um comando em algumas variantes da linguagem SQL - várias plataformas não o possuem, ou apenas o obtiveram recentemente.

— Steve Homer

@ToddR - Ouvi dizer (cinicamente) que "padrões" não passam de deficiências em uma linguagem ou modelo, para os quais o usuário deve criar soluções alternativas. Não sei o que o UPSERT faz, mas, embora tenha sido adicionado a alguns SQLs e não a outros, é um padrão.

— Martin F

1

Depende do que você quer dizer com um padrão. Se você está pensando em Pessoa / Empresa / Transação / Produto e tal, então sim - já existem muitos esquemas genéricos de banco de dados.

Se você está pensando em Factory, Singleton ... então não - você não precisa de nenhum deles, pois eles são de nível muito baixo para a programação de banco de dados.

Se você está pensando em nomear objetos de banco de dados, está na categoria de convenções, não no design em si.

BTW, S.Lott, relacionamentos um para muitos e muitos para muitos não são "padrões". Eles são os blocos de construção básicos do modelo relacional.

— André não é o santo
fonte

e quanto à herança de banco de dados (pessoa, cliente, funcionário), talvez esse tipo de coisa possa ser considerado como padrão de design?

— Muflix