Creation/drop de spip_urls ... c'est vraiement obligatoire l'id autoincrement ?
A priori il sert à rien cet id_url ?
* Fil tapotait, le 13/05/2007 17:01:
Creation/drop de spip_urls ... c'est vraiement obligatoire l'id autoincrement ?
A priori il sert à rien cet id_url ?
C'est toujours une bonne pratique d'avoir un id auto incrémenté dans une table, même s'il n'est pas utilisé habituellement.
Ne serait-ce que parce que {doublons} ne sait travailler qu'avec ce type de champ.
--
RealET
C'est toujours une bonne pratique d'avoir un id auto incrémenté dans une
table, même s'il n'est pas utilisé habituellement.
Ah bon. L'important c'est quand même d'avoir une clé primaire
invariante dans le temps (ex: spip_referers.referer_md5).
Ne serait-ce que parce que {doublons} ne sait travailler qu'avec ce type
de champ.
Si c'est un problème de {doublons}, il faut améliorer {doublons} 
-- Fil
* Fil tapotait, le 13/05/2007 18:17:
C'est toujours une bonne pratique d'avoir un id auto incrémenté dans une
table, même s'il n'est pas utilisé habituellement.Ah bon. L'important c'est quand même d'avoir une clé primaire
invariante dans le temps (ex: spip_referers.referer_md5).
Disons que mon expérience en terme de base de données en général m'a montré qu'un champ clef primaire auto est *toujours* pratique à utiliser sans alourdir de manière sensible la table.
En particulier, dans les relations, ça évite de se demander quel type pour utiliser pour les clef étrangères.
Et puis, ça permet généralement d'avoir un nombre entier de mots machines ==> optimisation processeur.
Ne serait-ce que parce que {doublons} ne sait travailler qu'avec ce type
de champ.Si c'est un problème de {doublons}, il faut améliorer {doublons}
-- Fil
--
RealET
RealET a écrit :
* Fil tapotait, le 13/05/2007 18:17:
C'est toujours une bonne pratique d'avoir un id auto incrémenté dans une
table, même s'il n'est pas utilisé habituellement.
Ah bon. L'important c'est quand même d'avoir une clé primaire
invariante dans le temps (ex: spip_referers.referer_md5).
Disons que mon expérience en terme de base de données en général m'a montré qu'un champ clef primaire auto est *toujours* pratique à utiliser sans alourdir de manière sensible la table.
+1
Concretement, on peut imaginer :
- que c'est plus simple pour quelqu'un qui ne sait pas ce qu'est une base de données, et encore moins une clé double, de manipuler un ID (notion plus generale, qu'il a en plus apris à manipuler dans les boucles), en particulier pour generer des attribut id (pour les css ou jquery)
- on peut imaginer aussi un systeme qui réutilise les URLs (je sais, c'est mal, mais sur un Intranet, ca peut avoir des applications), ca peut etre important de savoir que ca correspond à un autre objet (dans le cas les insert/update sont géré en consequence)
- si je branche un systeme externe sur cette table (par exemple un moteur d'indexation externe), il ne faut pas que tous mes developpements soient à jeter si demain Spip change le systeme de primary keys.
- d'une maniere generale, un systeme externe utilisant la base sera plus simple à mettre en place avec une clé simple (d'ailleurs il y a pas mal d'outils à base d'iterateurs qui gerent assez mal les clés doubles dans les frameworks java. idem pour certains systeme type factory qui commencent par créer l'objet en base avant de connaitre les données à y implanter).
- si demain on veut mettre en place un systeme de verrou generique (et avec de l'ajax partout, ca pourra rapidement etre utile), un systeme gérant les clés simples nous suffira largement, et la gestion des URLs pourrait alors en profiter
- ...
en y reflechissant 3mn, je vois deja ca... donc j'imagine qu'il y a pas mal de bonnes raisons d'avoir un auto increment sur cette table.
mes 2 sous.
@++