Ao usar um ORM, quais são algumas das coisas a serem observadas no design do banco de dados

Quais são algumas dicas de design de banco de dados a serem observadas quando você sabe que o banco de dados será acessado usando uma Wikipedia do Object Relational Mapper (ORM) ? Consulte também Entity Framework NHibernate ou LLBLGenPro.

Como exemplo, observarei o limite de 2100 parâmetros na chamada RPC do SqlServer. Esse é um problema ao usar o LLBLgen e unir tabelas quando chaves primárias compostas foram utilizadas, consulte o artigo MSDN para chaves compostas .

Siga as técnicas de normalização padrão, principalmente para a 3ª forma normal. Alguns ORMs podem entender os relacionamentos definidos no nível do banco de dados, para que você não precise fazer isso manualmente.

Eu realmente iria para o outro lado e perguntaria o que devo saber sobre ORMs. Verifique se você sabe: - Como perfil as consultas? - Como posso substituir o ORM e escrever minha própria consulta? - Posso usar procs armazenados?

O banco de dados deve ser independente do ORM, pois, mais do que provável, ele durará mais que o aplicativo.

1. Nunca deixe o ORM criar ou atualizar o esquema. Sempre use o SQL gerado como modelo, mas passe por ele antes de fazer a alteração (vi nosso ORM criar índices redundantes, usar tipos de dados incorretos ... todas essas coisas ruins)

2. Esteja ciente do que seu ORM não pode fazer. Por algum tempo, o Django não apoiou o grupo através do ORM, o que foi uma dor (ainda é divertido para os sistemas legados!). Portanto, estar ciente das limitações do ORM é uma obrigação para o DBA, mesmo que não seja ele quem escreve o código para o ORM

3. Periodicamente, pegue seus logs lentos, agregue-os através do mysqlslowlog e veja os 10 primeiros. Basicamente, ele mostrará as consultas que levaram o tempo mais agregado geral. Uma consulta que demorou em média 1 segundo, mas foi executada 50 mil vezes no mês passado, destacaria esse relatório agregado como um polegar dolorido;)

Eu não diria que vá tão extremo quanto despejar o ORM completamente. Se seus desenvolvedores que usam o ORM não são DBAs, provavelmente escreverão SQL tão ruim ou pior que o ORM. Então, eventualmente, caberá ao DBA assistir o que acontece.

Há algumas coisas que noto imediatamente sobre um banco de dados herdado que difere de um banco de dados criado por ORMs como Sequel e ActiveRecord for Ruby.

1. O uso de uma chave primária em todas as tabelas chamadas 'id'. Sim, isso pode ser substituído, mas idé o padrão.
2. O uso de nomes no plural para as tabelas.
3. O uso de sublinhados ("snakecase") para separar as palavras, criando o nome descritivo das tabelas e campos.
4. O uso de _idanexado a chaves estrangeiras: o layout geralmente é semelhante referenced_table_id.

Escrevi meu SQL manualmente há anos porque não confiava em um ORM, mas nos últimos dois ou três comecei a usar os dois ORMs mencionados anteriormente e estou impressionado com a integração deles com os bancos de dados existentes, e quão bem eles podem decifrar um banco de dados se suas convenções forem seguidas, ou eu dedico um tempo para fornecer as dicas necessárias para entender um banco de dados herdado.

Não sei se existem diretrizes comuns para o design de esquemas que funcionem bem com ORMs, mas acho que todos nos beneficiaríamos por ter alguns padrões. Definitivamente, existe uma hora e um local para um ORM, especialmente se você estiver usando uma boa linguagem OO e com um cronograma apertado.

Depende (:)) um pouco do mapeador OR que você está usando, portanto, dedique algum tempo pesquisando quais bancos de dados o mapeador OR oferece suporte / não suporte.

Por exemplo, os mapeadores OR da Microsoft não suportam todos os tipos de dados internos do SQL Server, não suportam alguns dos recursos TSQL mais novos / avançados (consultas recursivas, dicas do otimizador etc.).

Em teoria , um bom mapeador de OR deve ser flexível o suficiente para superar (e permitir mapear) um esquema de banco de dados relacional bem projetado para um bom modelo de objeto. Na realidade, ainda temos um pouco a percorrer antes que todas as peças do quebra-cabeça estejam no lugar; embora muitos mapeadores de OR ofereçam suporte ao mapeamento avançado, isso geralmente ocorre às custas de consultas complexas e problemas de desempenho.

Para um bom desempenho do banco de dados (e para preservar a sanidade do dba :)), você ainda deve seguir as práticas recomendadas quando se trata de design de esquema do db; normalize primeiro e desnormalize onde [/ se] for necessário. No lado do código, não exagere no modelo de objeto ; mesmo se o mapeador OR oferecer suporte a modelos de herança complexos e entidades que mesclam muitas tabelas, essas também são as áreas em que você corre o risco de ter problemas com consultas excessivamente complexas que atingem o banco de dados, etc. Perfil, perfil, perfil e não apenas use o ORM consultas geradas como garantidas. Lembre-se de que as consultas geradas pelo mapeador OR geralmente podem ser ajustadas como as consultas SQL normais e que duas consultas funcionalmente equivalentes no lado do objeto (por exemplo, consultas linq) às vezes podem resultar em consultas SQL muito diferentes.