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
fonte
Respostas:
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
fonte
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.
fonte
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 .
fonte
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:
Não usa:
recomendações:
Espero que este seja um bom ponto de partida.
fonte
Sua pergunta é um pouco vaga, mas suponho que
UPSERTpossa ser considerado um padrão de design. Para idiomas que não são implementadosMERGE, existem várias alternativas para resolver o problema (se existir uma linha adequada;;UPDATEoutroINSERT).fonte
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.
fonte