Relacionais Design Patterns banco de dados?

https://stackoverflow.com/questions/145689

02-07-2019
|

Pergunta

Os padrões de design são geralmente relacionadas ao design orientado a objeto.
Existem padrões de design para criar e programar relacional bancos de dados ?
Muitos problemas certamente deve ter soluções reutilizáveis.

Exemplos incluem padrões para design da tabela, stored procedures, triggers, etc ...

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

Exemplos de problemas que os padrões poderia resolver:

O armazenamento de dados (tabela por exemplo único com tipo vs várias tabelas com 1: 1 chave e diferenças ...) hierárquica
Armazenamento de dados com estrutura variável (por exemplo, colunas genéricos vs vs xml coluna delimitado ...)
Dados desnormalizar (como fazê-lo com o mínimo impacto, etc ...)

Solução

Há um livro na assinatura de Martin Fowler Series chamado Refactoring Databases . Isso fornece uma lista de técnicas de refatoração bancos de dados. Eu não posso dizer que eu ouvi uma lista de padrões de banco de dados tanto.

Eu também recomendo Modelo de Dados de David C. feno eo acompanhamento a Metadados Mapa que constrói no primeiro e é muito mais ambicioso e intrigante. O Prefácio sozinho é esclarecedor.

Também é um ótimo lugar para olhar para alguns modelos de banco de dados pré-enlatados é Series Data Book Modelo de Recursos de Len Silverston Volume 1 contém modelos universalmente aplicáveis ??dados (funcionários, contas, transporte, compras, etc), Volume 2 contém modelos de dados específicos da indústria (contabilidade, saúde, etc.), Volume 3 fornece padrões de modelo de dados.

Finalmente, embora este livro é ostensivamente sobre UML e objeto Modelando, de Peter Coad Modelagem na cor com UML fornece um processo de "arquétipo" conduzido de entidade modelar a partir da premissa de que existem 4 arquétipos fundamentais de qualquer modelo de objeto / dados

Outras dicas

Aqui está um link para um senhor que tem desenvolvido várias centenas de esquemas de banco de dados livre.

http://www.databaseanswers.org/data_models/

Talvez se você tem que construir uma db rapidamente isso vai lhe dar um ponto de partida em termos de tabelas e relacionamentos em um determinado esquema. Tenha em mente que você provavelmente terá que modificar este ponto de partida. Eu achei muito útil.

Em segundo lugar SQL Server Magazine tem uma coluna ocasional chamado de "O modelador de dados", que é muito educativo e muitas vezes contém esquemas completos para um determinado sistema.

Projeto padrões não são trivialmente soluções reutilizáveis.

Projeto padrões são reutilizáveis, por definição. Eles são padrões você detectar em outras boas soluções.

Um padrão não é trivialmente reutilizável. Você pode implementar seu projeto para baixo seguindo o padrão no entanto.

padrões de design relacionais incluem coisas como:

Um-para-muitos relacionamentos (mestre-detalhe, pai-filho) relacionamentos usando uma chave estrangeira.
Muitos-para-muitos relacionamentos com uma mesa de bridge.
Opcional um-para-um relacionamento gerenciado com nulos na coluna FK.
Star-Schema:. Dimensão e de fatos, design OLAP
completamente normalizado projeto OLTP.
Várias colunas de busca indexada em uma dimensão.
"tabela de pesquisa", que contém PK, descrição e valor de código (s) utilizado por uma ou mais aplicações. Por ter o código? Eu não sei, mas quando eles têm de ser utilizados, esta é uma maneira de gerenciar os códigos.
Uni-mesa. [Alguns chamam isso de um anti-padrão; É um padrão, às vezes é ruim, às vezes é bom.] Esta é uma mesa com um monte de coisas pré-juntaram que viola segunda e terceira forma normal.
mesa Matriz. Esta é uma tabela que viola a primeira forma normal por ter um conjunto 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 lotes de índices adicionais para relatórios e análises. É um anti-padrão - não faça isso. As pessoas fazem isso de qualquer maneira, por isso é ainda um padrão.

A maioria das pessoas que bancos de dados de projeto pode facilmente recitar uma meia dúzia "É mais um daqueles"; estes são os padrões de design que eles usam em uma base regular.

E isso não inclui padrões administrativos e operacionais de utilização e gestão.

Confira este blog -. o programador de banco de dados

Ele descreve algumas padrões de banco de dados .

livros de Joe Celko são excelentes para este tipo de coisas, em particular "SQL para Smarties". Ele tem algumas soluções inovadoras para problemas comuns, a maioria dos quais são padrões de projeto reutilizáveis.

http://www.celko.com/books.htm

AskTom é provavelmente o recurso mais útil única sobre as melhores práticas no Oracle bancos de dados. (I geralmente basta digitar "AskTom" como a primeira palavra de uma consulta google sobre um determinado tópico)

Eu não acho que é muito apropriado falar de padrões de projeto com bancos de dados relacionais. Bancos de dados relacionais já estão a aplicação de um "padrão de design" para um problema (o problema ser "como representar, armazenar e trabalhar com os dados, mantendo a sua integridade", eo projeto sendo o modelo relacional). Outros approches (geralmente considerados obsoletos) são os modelos de navegação e hierárquica (e eu sou existem Nure muitos outros).

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

Depois de muitos anos de desenvolvimento de banco de dados que eu posso dizer há alguns não vai e alguma pergunta que você deve responder antes de começar:

perguntas:

Você quer utilizar no futuro outro DBMS? Se sim, então não usar para coisas SQL especial do SGBD atuais. Remover lógica na sua aplicação.

não usa:

espaços em branco em nomes de tabela e nomes de coluna
Caracteres não ASCII em nomes de tabelas e colunas
ligação a um caso específico mais baixo ou maiúsculas. E nunca usar 2 tabelas ou colunas que diferem apenas com minúsculas e maiúsculas.
não usa palavras-chave SQL para tabelas ou colunas nomes como "FROM", "entre", "delete", etc

Recomendações:

Use NVARCHAR ou equivalentes para suporte unicode, em seguida, você não tem problemas com páginas de código.
Dê a cada coluna um nome único. Este make ele easer em juntar-se para selecionar a coluna. É muito difícil se cada tabela tem uma coluna "ID" ou "Nome" ou "Descrição". Use XyzID e AbcID.
Use um pacote de recursos ou iguais para expressões SQL complexas. É torná-lo mais fáceis de mudar para outro DBMS.
Não elenco duro em qualquer tipo de dados. Outra DBMS não pode ter este tipo de dados. Por exemplo Oracle não DAEs ter um SMALLINT apenas um número.

Espero que este é um ponto de partida bom.

A sua pergunta é um pouco vago, mas suponho UPSERT poderia ser considerado um padrão de design . Para idiomas que não implementam MERGE, uma série de alternativas para resolver o problema (se fileiras adequados existe, UPDATE, senão INSERT). exist

Depende do que você entende por um padrão. Se você está pensando Pessoa / Empresa / Transação / Produtos e tal, então sim - há uma série de esquemas de banco de dados genéricos já disponível

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

Se você está pensando objeto de banco de dados de nomes, então é sob a categoria de convenções, não projetar per se.

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

Este livro parece interessante

Title: Data Patterns
By: Microsoft Corporation
Publisher: Microsoft Press
Pub. Date: December 21, 2004
Print ISBN-13: 978-0-7356-2200-5

Licenciado em: CC-BY-SA com atribuição

Não afiliado a StackOverflow