Blogounage

Aller au contenu | Aller au menu | Aller à la recherche

Mot clé - oracle

Fil des billets - Fil des commentaires

vendredi 26 octobre 2007

Limitation Oracle antédiluvienne

Par batmat le vendredi 26 octobre 2007, 11:06 - Technique

Je découvre avec une relative stupeur que la taille maximale des noms de tables, de colonnes, de contraintes est limitée sur Oracle à 30 caractères seulement !

Imaginez que vous ayez une contrainte d'intégrité référentielle entre deux tables :

  • PRODUIT
  • CATEGORIE_PRODUIT

Par convention, on préfixe souvent ces contraintes de clés étrangères par FK (voire C_FK par exemple, pour Constraint et Foreign Key). Ça me donne quelque chose comme ça :

  • FK_PRODUIT_CATEGORIE_PRODUIT

Là, j'ai 28 caractères, je passe limite. Si je rajoute "C_", je suis à fond...

Imaginons maintenant que votre fonctionnel vous indique qu'il y a une relation de réflexivité sur CategorieProduit. Les catégories de produit forment en effet un arbre avec des catégories, des sous-catégories, etc. Ben là, vous oubliez le nommage ci-dessus :

  • FK_CATEGORIE_PRODUIT_PRODUIT_CATEGORIE_PRODUIT, ça passe pas...

Autre cas, si vous avez deux relations entre deux mêmes tables. Par exemple, Adresse et Client : un client peut avoir une adresse de facturation et une adresse de livraison. En base, on doit donc retrouver deux contraintes d'intégrité. La première idée qui vient est de concaténer par exemple le rôle au nommage ci-dessus. Euuu, ça commence à exclure pas mal de cas.

Franchement, à l'occasion du passage de la mise à jour de Oracle v10, Oracle aurait pu supprimer ou au moins augmenter cette limitation antédiluvienne !!! Pour la petite histoire, cette limitation n'existe pas sur les autres SGBD que nous pouvons utiliser : HSQLDB, MySQL, PostgreSQL... Je comprends mieux pourquoi les schémas d'entreprise sont truffés de noms absolument incompréhensibles. L'auto-documentation du nommage est impossible avec une limitation aussi importante.

À l'heure de l'auto-complétion omniprésente, il est courant d'avoir des variables qui atteignent 30 caractères. Je ne dis pas qu'il faut forcément des noms de variable à rallonge, mais si la longueur apporte en clarté, en maintenabilité, en compréhension, ne vous en privez surtout pas !

Très très déçu par Oracle sur ce coup là.

3 commentaires aucun rétrolien

lundi 14 mai 2007

Toplink better than Hibernate?

Par batmat le lundi 14 mai 2007, 23:20 - Technique

Today, we received Oracle. They were coming to speak about their business Intelligence offer, Oracle Application Server and so on.

When speaking about Toplink, the guy said something like: "We could say Toplink is kind of a father to Hibernate. Obviously, it's already almost 15 years of existence." Well, why not. Though I didn't see any article interviewing Gavin King confirming that, but apart from reusing their ideas or not, Toplink was here before, OK.

The assertion that surprised me was another one, something like: As Toplink is older than Hibernate, it's obviously more robust and has more functions.

Well, I'm not sure I would agree with this one. In fact, as Toplink Essentials was only released in the OpenSource world very recently (may 2006 in Glassfish, so the JPA implementation even more, if I'm right), and experts seems to agree that about 90% of the projects today use Hibernate for the persistance layer (Didier Girard says it in the TV4IT Webcast. I think this is more of a feeling for him, so if anybody has some statistics about, I'm very interested. I should also ask Sami Jaber for his feeling about it.).

Webcast (in french, see about 9/10 of the video for the Hibernate is 90% of the current projects) :

So, what is the right indicator about software robustness?

Is this the software that's been released fifteen years ago, used by 10 people around the word since this time, or is this this other one, that's been released 6 years ago, used by 90 people since then? Who was the most testable? The one that only few people could download to give it a try, or the one that's been downloaded and tested tons of time by a lot different people?

In my opinion, but I also agree I only know Hibernate, I'm pretty sure Hibernate has already been thoroughly tested. At least, as much as Toplink has. My point is that the maturing of Hibernate was a lot quicker than Toplink's one. Once more, it would be very interesting to put numbers in the debate. Hibernate has been opensourced since its start, so it always benefited from code reviews, patches and so on, and evolved very quickly.

To sum up, because of the fundamental differences between both development styles, I'm not sure that today Hibernate is still behind Toplink speaking about robustness, functions scope and so on. Though I'd be delighted to learn about interesting differences, if you know about it.

un commentaire aucun rétrolien