Article de fond: DBAs?! Pour quoi faire?

Aujourd'hui la réponse (bien méritée) de Ralph suite à l'article sur les DBA.

Notre projet était sensé replacer un vieux Framework d’édition de rapport datant de dix ans qui commençait vraiment à montrer ses limites. Le développement de notre produit avançait correctement depuis quelques mois jusqu'a que ma société achète une start-up concurrente avec un bon système de reporting.
Une nouvelle équipe de développement se forma autour du développeur vedette de la société nouvellement rachetée (appelons le « Maître du C# ») qui réussit à convaincre la direction du projet que les raisons du succès de leur système était

1. L'utilisation des technologies Microsoft.
2. L'utilisation des méthodes de développement "agile".
   

Ainsi, la nouvelle équipe se lança dans l'aventure des nouvelles technologies pendant que je continuais d’utiliser les technologies préhistoriques qu'étaient le Java et le C++.

Deux ans plus tard, le projet avait explosé toutes les dates limites, sa couverture fonctionnelle n'était plus que l'ombre de celle initialement prévue. A chaque demande d'amélioration des responsables du produit, la réponse du Maître du C# était toujours la même : « Techniquement Impossible à implémenter ».

Finalement (après une autre date limite piétinée), le Maître du C# démissionna et l'on m'appela pour faire l'inventaire des dégâts. Après une brève introduction à l'"Architecture" du système, je fus en mesure de distinguer les parties prioritaires dans ma nouvelle mission de "pompier".

Je n'avais jamais travaillé sur ce projet, pourtant, un point m'avait toujours étonné. Jamais aucun DBA n'avait participé de près ou de loin au projet. Le Maître du C# avait apparemment fait tout le travail SQL dans son ancienne société, ainsi, aucun DBA n'était utile. De plus, les DBA n'étaient pas assez "Agile" pour une équipe qui avançait si rapidement.

L'un des premier "feu" que je dus éteindre fut une méthode qui semblait très étrange. Elle convertissait des listes d'objets ID en chaîne de caractère CSV sans AUCUN commentaire dans le code (pas assez "agile"). Quand je vu la longue liste d'ID passés comme paramètre à la fonction String.Format() (l'équivalent C# de sprintf) puis envoyé à la couche de gestion de la base de données, le signal d'alarme se déclencha dans ma tête :

StringBuilder idBuilder = new StringBuilder();
foreach (object id in idList)
{
	idBuilder.Append(id.ToString() + ",");
	if(idBuilder.Length >7500)
	{
			command = String.Format(queryBase, new object[]{TableName, workSetId, idBuilder.ToString(), userId});
			[snip-- exécute la chaîne comme une commande SQL]
			idBuilder = new StringBuilder();
	}
}

Craignant le pire, le regardait plus précisément la définition de "queryBase".

private const string queryBase= @"
	DECLARE @ids varchar(8000)
	SET @ids = '{2}'
	DECLARE @commapos int
	CREATE TABLE #t( i int )
	WHILE( 1 = 1 )
	BEGIN
	SET @commapos = CHARINDEX( ',', @ids )
	IF @commapos = 0 BREAK
	INSERT INTO #t (i) VALUES(LEFT( @ids, @commapos - 1 ))
	SET @ids = STUFF( @ids, 1, @commapos, null )
	END
	insert into {0} 
		select {1},i,{3}, getDate() from #t
	drop table #t
	";

Quand j'ai montré ce code à l'un de nos DBA pour être bien sur qu'il faisait ce que je pensais, son seul et unique commentaire fut : "Je t'en prie, dis moi que tu n'as pas trouvé ça dans notre produit".

Beaucoup de projet aujourd'hui maintenant un Framework d'ORM comme hibernate, quel dommage ! On trouvait de si belles perles lorsque les développeurs comme notre Maître du C# se sentaient investi d'une mission divine pour "simplifier" les accès aux basses de données.