2010-02-05 10 views
15

Je souhaite utiliser Markdown pour le système de commentaires de mon site Web mais je suis tombé sur le problème suivant: Que dois-je stocker dans la base de données - le commentaire original dans Markdown, le commentaire analysé en HTML ou les deux?Comment stocker les commentaires Markdown

J'ai besoin de la version HTML pour la visualisation et de la version Markdown si l'utilisateur a besoin de modifier son commentaire. Si je stocke la version Markdown, je dois analyser les commentaires lors de l'exécution. Si je stocke la version HTML, j'ai besoin de convertir le commentaire à Markdown lorsque l'utilisateur a besoin de le modifier (j'ai trouvé Markdownify pour cela, mais ce n'est pas sans faille). Si je stocke les deux versions, je double l'espace utilisé.

Quelle serait la meilleure option? Aussi, comment Stack Overflow gère-t-il cela?

+3

* (indice) * Recherchez ou demandez sur meta.stackoverflow.com pour savoir comment SO gère cela. – Gordon

+0

Merci! Je ferai ça. – liviucmg

Répondre

16

Stockez les deux. Cela va à l'encontre des règles de normalisation de la base de données, mais je pense que cela vaut la peine pour l'optimisation de la vitesse dans ce cas - l'analyse de grandes quantités de texte est une opération très lente.

Vous avez seulement besoin de le stocker deux fois, mais vous devrez peut-être le servir des milliers de fois, c'est donc un compromis spatio-temporel.

+3

Pourquoi stocker la version analysée? La mise en cache du côté de la présentation devrait annuler toutes les implications en termes de performances dues à la nécessité de l'extraire de la base de données. – Chris

+0

Je suis d'accord avec @Mark et @Chris. D'une part, le stockage est bon marché. Mais, si vous avez un tel volume de données qu'il n'est pas trivial de stocker les deux, alors vous avez assez de données que vous devriez probablement mettre en cache dans votre couche de présentation, auquel cas @Chris a raison. –

+0

Pour un site tel que SO qui reçoit des hits par des milliers d'utilisateurs, y compris des robots qui analysent la quasi-totalité du site tous les jours, vous avez besoin d'énormes quantités de cache. Bien sûr, cela pourrait être possible avec juste un cache mémoire et pas de cache db ... Je ne sais pas de combien d'espace vous auriez besoin pour presque 500 000 questions ... J'imagine pas mal de choses. Mais je comprends votre point. Bien sûr, vous devriez mettre en cache les pages et parties de pages en mémoire. Mais un cache mémoire rend-il complètement redondant un cache de base de données ou est-ce logique d'avoir les deux? –

4

Rendez simplement le Markdown au format HTML lors de l'exécution.

Si votre site rencontre des problèmes de performances, le Markdown sera l'un des dernières choses que vous chercher à peaufiner. Et même alors, je doute que cela ait un sens.

Jetez un coup d'œil au moteur de rendu JavaScript en temps réel que SO utilise. C'est rapide.

Editer: Désolé, j'aurais dû être plus clair. Je voulais juste rendre en PHP. Vous vous épargnerez beaucoup de maux de tête - et vous avez probablement des choses plus importantes à s'inquiéter.

+0

Sur des pages plus complexes, j'ai souvent dû attendre une seconde ou deux pour que le rendu se termine afin que je puisse taper. Et pourquoi pensez-vous qu'ils font que le client le fasse au lieu de le faire sur le serveur? Probablement parce qu'ils ne veulent pas gaspiller les ressources du serveur à analyser le texte. –

+1

J'allais suggérer de tout faire en JavaScript à la place. Il est parfaitement logique de faire tout ce que vous pouvez sur le client. Les clients deviennent plus rapides, JavaScript devient plus rapide. C'est comme l'informatique distribuée gratuite. Pourquoi pas toi? –

+6

@Earwicker: Les moteurs de recherche n'interprètent pas Javascript, et beaucoup de navigateurs ordinaires ont Javascript désactivé par défaut. Je pense qu'il est correct de désactiver partiellement les fonctionnalités avancées si JavaScript est désactivé, mais je pense que montrer aux gens une marque au lieu de HTML s'ils ont désactivé Javascript ne serait pas une bonne idée. –

12

Stockez la démarque d'origine et analysez au moment de l'exécution. Il y a quelques problèmes avec le stockage de la version convertie dans la base de données.

  1. Si l'utilisateur veut modifier leur commentaire, vous devez en arrière convertissent analysable démarquage d'origine
  2. espace dans la base de données (allez toujours par la règle que si vous n'avez pas besoin de le stocker, ne pas)
  3. Les modifications apportées à l'analyseur de démarques doivent être exécutées sur chaque commentaire de la base de données, au lieu de s'afficher au moment de l'exécution.
+2

3 est un très bon point donc +1 pour cela. Mais si un utilisateur a fait un commentaire en utilisant une ancienne version de markdown et que vous modifiez l'analyseur, vous ne souhaiterez peut-être pas que la modification se propage automatiquement à tous les commentaires, car cela pourrait casser le formatage de certains commentaires plus anciens. –