Structure BDD de folie

[leosw]

Salut les techos,

Je suis en train de retourner dans ma tête l'architecture SQL parfaite pour ce site.
On part de l'hypothèse qu'on n'utilise pas de framework (phpBB par exemple...).

On a ici plusieurs types de contenus : page wiki, message de forum principal (les réponses peuvent être vues comme des commentaires), point d'intérêt.

Dans tous ces types on a des points communs : nom, auteur, date de parution, numéro de version (si on part d'une architecture avec des révisions), archivé (ou censuré)...
Mais aussi des divergences : coordonnées (pour les POIs), catégorie (pour les messages forums)...

Est-ce qu'on pourrait pas utiliser un table commune à toutes ces données, et en fonction du type, joindre une deuxième table ?
Est-ce que ça passerait avec l'utilisation faite de postGIS ?

Léo

[Dominique]

Quel avantage pour les utilisateurs, la maintenabilité, fonctions supplémentaires, ... ?

[leosw]

Principalement l'historique des révisions, l'absence de code étranger, le multilinguisme et une homogénéité.

[sly]

Je suis en train de retourner dans ma tête l'architecture SQL parfaite pour ce site.
On part de l'hypothèse qu'on n'utilise pas de framework (phpBB par exemple...).

A la lecture de ton post, ça m'a eu l'air tellement utopique et délirant* que je me suis dis que je n'allais pas répondre pour économiser mon temps. Et puis après je me suis dis que ça n'était pas poli au regard du taf que tu as réalisé
alors je répond que :
-> ça m'a l'air tellement utopique et délirant*... d'imaginer se débarrasser de phpBB.
Pour faire un forum qui marche bien, c'est quand même pas mal phpBB

Bon, mais à supposer qu'on mette de coté la partie forum :

Est-ce qu'on pourrait pas utiliser un table commune à toutes ces données, et en fonction du type, joindre une deuxième table ?

On peut. tu peux aussi tout faire en NoSQL ou dans un fichier texte et ça marchera. ça ne sera pas forcément plus lisible, et en tout cas, je peine à voir le gain du "tout refaire pour factoriser le coding de 2 fonctions"

Est-ce que ça passerait avec l'utilisation faite de postGIS ?

Sûrement

Conclusion : je ne suis pas convaincu d'investir du temps là dessus.


* : en terme de temps passé sur gain apporté

[leosw]

Merci à tous les deux pour vos réponses héhé,

J'ai pu faire un peu le point de mon côté, je vais essayer de faire une petit preuve de concept.
Face à la possibilité de gérer les révisions, je suis convaincu que vous vous joindrez à moi haha !

Joyeux printemps à vous !

Léo

[Dominique]

C'est sûr qu'historiser les révisions serait un plus.

C'est drôle, j'aurais tendance à tout mettre dans phpbb comme j'ai fait sur chemineur.fr. Ce n'est pas si compliqué et ça évite de réécrire tout un tas de fonctions comme la saisie, l'interface avec la bdd ou l'identification, il y a un templaiteur, ...

Le nosql : c'est comme ça que j'avais écrit chemineur v1 mais ça rame terriblement sur une grosse base. Pourquoi se passer d'une base indexée alors que ça marche très bien. .. ça me dépasse. .. et puis, comment on calcule l'appartenance à un massif en nosql ?
On peut aussi coder en assembleur ou en binaire... php, c'est vendu au diable et plein de bugs

Dernier point : est ce qu'un site largement connu et stable est le bon sujet pour des expérimentations de technos sans un impérieux besoin ?

Peut être peux tu commencer par un site qui reprend les données sous un autre angle : un chemineur II par exemple ?
C'est une bonne façon de résoudre son purit de codage et un bon labo pour tester des améliorations de WRI

Bon courage en tout cas.

[sly]

Le nosql : c'est comme ça que j'avais écrit chemineur v1 mais ça rame terriblement sur une grosse base. Pourquoi se passer d'une base indexée alors que ça marche très bien. .. ça me dépasse. .. et puis, comment on calcule l'appartenance à un massif en nosql ?

Juste pour être sûr de préciser ma pensée : je faisais de l'ironie avec NoSQL. A part éventuellement la partie où la table des points présente de champs mutants, une base en SQL+GIS répond parfaitement aux besoins actuels (et sûrement à venir) de refuges.info

Dernier point : est ce qu'un site largement connu et stable est le bon sujet pour des expérimentations de technos sans un impérieux besoin ?

Disons quand même que le besoin d'historisation des révisions est fort et nous aiderait bien la modération et le suivi. Toutefois, il n'est pas impérieux et ne nécessite, selon moi, pas une refonte complète de l'architecture SQL, du passage à full-phpBB ou d'une remise en cause complète du code actuel.
Mon avis est que refuges.info a "subit" ses utilisateurs dans leurs demandes, leur remarques et leurs débats pendant des années, et plus que toutes les technos, ou méthodes sous le capot, c'est ça qui en fait son ergonomie valable, adapté au besoin des refuges de montagne et qu'il faut préserver devant tout choix technique supposé nous faire gagner du temps. Je n'ai pas chronométré, mais au total je pense avoir passer 5 fois voir plus de de temps en débats sur le forum pour savoir si la question anti robot de la capital de l'isère, du cheval blanc d'henri IV, si "manque un mur" ne pouvait trouver appellation plus pertinente, si les anonymes pouvaient être contributeurs qu'a coder du php. Donc si une techno me faisait gagner 20% de temps à coder, cela resterait dérisoire sur le temps total passé.