De bonnes données Niveau Dev & Design: Quelles sont les mauvaises pratiques communes en matière de développement de niveau de données?

Question

Je fais des recherches actuellement les meilleures pratiques (à un niveau raisonnablement élevé) pour la conception d'applications pour les systèmes hautement maintenables qui se traduisent par un frottement minimal au changement. Par « données Tier » Je conception de base de données moyenne, objet (relations cartographes ORM) et des technologies d'accès aux données générales.

D'après votre expérience, qu'avez-vous trouvé être les erreurs les plus courantes et les mauvaises pratiques en matière de développement de niveau de données et quelles mesures avez-vous prises / mises en place / ou peut recommander à rendre le niveau de données un meilleur endroit pour être du point de vue de développeur?

Un exemple de réponse peut inclure: Qu'est-ce que causes les plus courantes d'un tiers de données lentes, mal évolutives et prorogeables? + Quelles mesures peuvent être prises (que ce soit dans la conception ou refactoring) pour remédier à ce problème?

Je cherche des histoires de guerre ici et quelques vrais conseils du monde que je peux construire dans des documents et des échantillons d'orientation accessibles au public.

Answer 1

Magie.

J'ai utilisé Hibernate , que les objets automatiquement stocke et va chercher à partir d'une base de données. Il prend également en charge le chargement paresseux, de sorte qu'un objet associé n'est récupéré à partir de la base de données lorsque vous le demandez. Cela fonctionne d'une certaine façon magique je ne comprends pas.

Tout cela fonctionne bien aussi longtemps que cela fonctionne, mais quand il tombe en panne, il est impossible de le suivre vers le bas. Je pense que nous avons eu un problème lorsque nous avons combiné avec Hibernate AOP , qui en quelque sorte l'objet était pas encore initialisé par Hibernate lorsque notre code a été exécuté. Ce problème a été très difficile à déboguer, car Hibernate fonctionne dans de telles manières mystérieuses.

Answer 2

mapping objet-relationnel est une mauvaise pratique. Par cela, je veux dire qu'il tend à produire des données des schémas qui ne peuvent être vaguement décrits comme « relationnelle », et donc ils mal échelle et présentent l'intégrité des données pauvres.

Ceci est parce que les schémas correctement relationnelles ont été à travers le processus de normalisation, alors que les résultats de O-R Mapping sont normalement classes d'objets mis en œuvre sous forme de tables de base de données. Ceux-ci ne sont pas normalement été normalisées, mais ils ont plutôt été conçues pour la commodité immédiate du développeur OO.

Bien sûr, dans les cas où les exigences de données persistantes sont minimes, cela est sans importance.

Cependant, j'ai déjà travaillé pour une compagnie maritime qui avait grandi en prenant en charge plusieurs autres entreprises, et avait sous-traité le développement d'un système opérationnel intégré (pour remplacer les différents systèmes spécifiques à l'entreprise dont elle avait hérité) à une entreprise en utilisant un OO méthodologie, avec un schéma de données produit par la cartographie OR. Les caractéristiques de performance du système en cours d'élaboration étaient si pauvres, et le schéma de données si complexe, que la compagnie maritime a chuté après quelque chose comme deux années de développement - avant même a été mis en

est une conséquence directe de la mise en correspondance O-R; la pire complexité dans le schéma (et par conséquent une mauvaise performance) a été causé par l'existence de tables créées uniquement comme des objets du processus de conception OO - ils reflètent les dispositions d'écran, pas de relations de données

.