Cette page vise à discuter des proposition de stockage des données de configuration fonctionnelle de
WikiNi.
Ce sujet est indépendant :
- de la réalisation ou non des groupes d'utilisateurs
- de la réalisation de l'architecture de gestion des droits d'accès aux actions et handlers
Lieux de stockage
Proposition 1 : sur le système de fichier
(Situation actuelle.)
Avantages :
Inconvénient :
- écriture plus délicate
- solutions de modèles physiques de stockage plus délicates
Proposition 2 : en base de données
Avantages :
- manipulation plus facile des données (lecture, mais surtout écriture)
- la sauvegarde de la base permet également de sauvegarder la configuration du wiki : un wiki peut donc être réinstallé très rapidement en cas de problème
Inconvénients :
- oblige à des accès supplémentaires à la base de données (négligables par rapport à l'accès à un fichier ?)
Modèle conceptuel de stockage
Proposition 1 : dans le cas d'une base de données : des triplets
Du type RDF : ressource, propriété, valeur. Exemple : <ce wiki> <a pour nom> <
WikiNi>.
Avantages :
- évolutivité de la table pour stocker d'autres informations
- usage de vocabulaires normalisés pour décrire les données (exemple : le Dublin Core, FOAF, etc.)
Inconvénients :
- certaines données seront redondante par rapport à des couples propriété/valeur
Modèle physique de stockage
Proposition 1 : dans le cas de triplets : des URI
Exemple : <
http://wikini.net/voc/CeWiki> <
http://purl.org/dc/Title> <"
WikiNi">
Avantages :
- permet un export direct en RDF
- un URI étant un identifiant unique, il n'y a pas de risque de confusion
Inconvénients :
- redondance d'informations