Note de lecture : SQL Antipatterns, par Bill Karwin

Note : 7 ; Au croisement des préoccupations du développeur et du concepteur de base de données

Le pluriculturalisme est un véritable problème en informatique. Prenons le cas qui nous intéresse aujourd’hui : comment concilier le point de vue (valide) du concepteur de base de données, avec les questions d’efficacité d’accès aux données, de normalisation du modèle et de requêtage SQL, avec le point de vue tout autant valide du développeur s’adossant à cette même base de données, pour qui celle-ci n’est qu’un support de persistance ? La réponse est : ces points de vue sont rarement conciliés. En cela ce livre est réellement intéressant car il considère ensemble ces deux points de vue tout au long de nombreux cas de figure de conception de modèles de données constituant autant d’antipatterns. On notera aussi au passage que les exemples sont toujours donnés avec MySQL, toutefois lorsque des spécificités de certains SQBD s’appliquent, l’auteur en fait part.

Le texte est articulé autour de 24 antipatterns constituant autant de chapitres. Leur structure est invariable : objectif, antipatterns, comment le reconnaître, usages légitimes et solution. Cette structure qui montre une bonne appréhension du principe des patterns s’avère très efficace, aussi bien dans le diagnostique du problème que dans l’émergence de la solution. Ces patterns se répartissent par ailleurs en 4 parties dans l’ouvrage.

La première partie est constituée de 8 antipatterns occupant 100 pages ! Elle traite de la structure logique de la base. On y parle de l’usage irraisonné de champs blob, du bon usage des contraintes et des cardinalités (entre autre lorsqu’il faut user de tables intermédiaires). Ces règles paraissent de bon sens aux vieux routiers de la modélisation, mais elles sont souvent enfreintes par les développeurs d’applications peu enclins à passer beaucoup de temps et d’attention sur le modèle et donc prêts à « couper les virages » !

La seconde partie traite de la structure physique de la base. Elle compte 135 pages et 4 antipatterns. On y évoque l’usage intelligent des différents types de champs, mais aussi de clés primaires et d’index secondaires pertinents. Là encore, il s’agit des éléments de base du DBA … qui devraient l’être aussi pour le développeur. Mais l’expérience montre…

Dans la troisième partie (6 patterns, 60 pages) on évoque les requêtes, le bon usage de la valeur « null », des regroupements, mais aussi de l’écriture des « requêtes à tout faire ».

La dernière partie est longue de 6 patterns couvrant 70 pages. On trouve ici diverses bonnes pratiques applicatives pour couvrir par exemple des problèmes de sécurité. Hélas les exemples sont développés en PHP, bien loin de ce que je ne saurais utiliser (aussi bien sur le langage que sur l’architecture). C’est donc le chapitre qui m’a le moins intéressé.

En lisant ce livre j’ai eu l’impression (non la certitude) de lire des choses que je connaissais déjà. Mais j’ai eu aussi l’impression de croiser des cas de figure que j’ai vu appliqués plus ou moins souvent, mais que j’ai tous vu ! J’en conclu que cette lecture devrait faire partie du bagage de tout développeur applicatif, aussi basique que semblent parfois ces concepts ! Le ciblage de l’ouvrage est clair : il s’adresse aux développeurs qui va souvent considérer la base de données comme un artefact de second ordre, un simple moyen de persistance des données qu’il va traiter dans son application.

La vérité est qu’appréhender l’association d’un développement objet (au hasard) et d’une base de données, c’est devoir faire face à la question des paradigmes multiples. Ce livre est original à ce titre car il fait face à cette réalité et va aider le développeur souvent peu sensibilisé à ce problème à monter en compétence.

De plus le texte est clair et bien écrit. Pourquoi se priver de cette lecture ?

sql-antipatterns-pragprog

Référence complète : SQL Antipatterns, Avoiding the pitfalls of database programming – Bill Karwin – Pragmatic Bookshelf 2010 – ISBN : 978 1 93435 655 5

SQL Antipatterns: Avoiding the Pitfalls of Database Programming

http://www.goodreads.com/book/add_to_books_widget_frame/1934356557?atmb_widget%5Bbutton%5D=atmb_widget_1.png&atmb_widget%5Bhide_friends%5D=on

Arthur P. Stern

joannastern:

My grandfather, Arthur P. Stern, passed away last night. He was 87 and had an enormous impact on my life, but also on yours. He was instrumental in inventing the color television and GPS.

I haven’t shared much publicly about his impact on me and my interest in technology, but this seemed like a good time to start. 

There’s more on his professional accomplishments here: http://www.ieeeghn.org/wiki/index.php/Arthur_P._Stern

Note de lecture : Patterns for Parallel Programming, par Mattson, Sanders & Massingill

Note: 5 ; Le grid computing sous forme de patterns, mais pas à l’usage des débutants!

Difficile de classer ce livre! De prime abord, il est destiné à aborder le grid computing sous l’angle conceptuel, plutôt que par le biais d’une technologie particulière. Cela dit, le texte s’appuie de façon extensive sur 2 environnements parallèles: OpenMP et MPI. Ils sont d’ailleurs introduits de façon conséquente en annexe, pour ceux qui (comme moi) n’ont pas une culture “parallèle” étendue. Pour mener à bien leurs propos, les auteurs proposent une démarche en 4 étapes:

  • Les “finding concurrency” patterns: il ne s’agit pas vraiment de patterns ici, mais d’étape d’analyse, tel qu’on peut les trouver dans une méthode prescriptive.
  • Les “algorithm structure” patterns: ressemblent eux d’avantage à des patterns et proposent des solutions architecturales de traitement, telles que le “divide & conquer”, le “pipeline” ou le “event-based coordination”
  • Les “supporting structure patterns” décrivent les constructions logicielles, les briques de conception permettant la mise en oeuvre des architectures parallèles. La plupart d’entre elles peuvent être utilisées dans le cadre de plusieurs architectures, bien qu’avec des adéquations inégales. Ce sont probablement les “vrais patterns” de cet ouvrage, ils se nomment “master / worker” ou “fork / join”. A ce niveau, les patterns sont illustrés par du code en C, et discutés de façon plutôt exhaustive sur les détails.
  • L’”implémentation mechanism design space” décrit les mécanismes élémentaires sur lesquelles les briques de conception précédemment décrites vont s’appuyer. Nous parlons ici de gestion de threads, d’exclusion mutuelle, de partage mémoire ou de passage de messages, entre autre. Ces mécanismes sont décrits séparément pour les environnements OpenMP et MPI.

En conclusion, j’ai trouvé le livre plutôt “dense”, ce qui est probablement normal vu le sujet traité. Toutefois, il est plus difficile qu’il ne devrait être pour les non initiés, car on plonge trop vite dans les détails de code, et la conceptualisation manque cruellement, ou elle est en tout cas insuffisante, car ce devrait être le propre des patterns.

patterns-parallel-programming

Référence complète : Patterns for Parallel Programming – Timothy G. Mattson, Beverly A. Sanders & Berna L. Massingill – Addison Wesley / Software Patterns Series 2004 – ISBN: 0-321-22811-1

Patterns for Parallel Programming


http://www.goodreads.com/book/add_to_books_widget_frame/0321228111?atmb_widget%5Bbutton%5D=atmb_widget_1.png&atmb_widget%5Bhide_friends%5D=on

In one inquiry, it was found that a successful team of computer specialists included an ex-farmer, a former tabulating machine operator, an ex-key punch operator, a girl who had done secretary work, a musician and a graduate in mathematics. The last was considered the least competent.

Hans Albert Rhee, Office Automation in Social Perspective, 1968