Comment stocker des articles ou d'autres textes volumineux dans une base de données
Je suis en train de concevoir moi-même un site Web basé sur une base de données. La raison principale est à des fins d'apprentissage, mais je ne mentirai pas, il y a une petite quantité de vanité incluse!
Bien que je pense que la conception de ma base de données est assez bonne jusqu'à présent, je ne suis pas encore entièrement sûr de la meilleure façon de stocker des articles ou d'autres gros textes. Je sais que la plupart des SGBD ont le type de données TEXT ou équivalent et peuvent contenir une énorme quantité de texte. Cependant, le stockage d'un article complet sous la forme d'une longue chaîne rend la lecture malheureuse, donc le formatage sera nécessaire.
Dois-je stocker le texte de l'article avec toutes les balises HTML ou BBcode - ou est-il préférable de simplement créer la page dans un document HTML ou XML et de stocker le chemin d'accès à ce fichier dans la base de données?
J'aime bien l'idée de stocker des articles en tant que document XML car je peux facilement baliser un article avec des balises personnalisées et utiliser les fonctions XML et XSLT de PHP pour transformer le XML en HTML [ou en fait, tout autre format]. Il permet également à l'auteur de dicter quand créer des sauts de ligne/page. Cette approche nécessiterait bien sûr un codage supplémentaire [dont je n'ai pas peur] mais elle pose un problème pour rendre les articles consultables.
Je sais que MySQL, par exemple, a une syntaxe SQL pour rechercher des termes/phrases spécifiques à l'intérieur de chaînes contenues dans un champ de texte. Si je devais stocker du texte dans des fichiers séparés, comment pourrais-je envisager de rendre ces articles consultables?
Il y a beaucoup de choses que j'ai écrites ici sur une question aussi simple, je vais donc la détailler:
1: Existe-t-il une "meilleure" façon de stocker de grandes quantités de texte formaté directement dans une base de données ou
2: est-il préférable de conserver les chemins d'accès à ce texte sous la forme de documents HTML/XML/Quels que soient les documents.
Si 2, existe-t-il une manière élégante de rendre ce texte consultable?
Merci pour votre temps :)
Stockez tout dans un grand champ de texte comme l'a suggéré Alex. Pour la recherche, ne martelez pas votre base de données, utilisez Lucene , ou htdig pour créer un index de votre sortie. De cette façon, les recherches sont très rapides. L'effet secondaire est que vous rendez vos recherches un peu plus conviviales pour les moteurs de recherche; vous prenez votre champ de mots-clés (comme suggéré la barre oblique inverse) et les collez dans l'attribut meta-keywords.
Éditer
À moins que vous ne recherchiez que des mots clés, faire effectuer les recherches par la base de données sera horriblement lent (avez-vous déjà cherché sur un forum et cela prend FOREVER?) Il n'y a aucun moyen pour la base de données d'indexer un
select.. where FULLTEXTFIELD like '%cookies%'.
Il est frustrant de rechercher un article et la recherche ne renvoie pas les résultats que vous recherchez car ils ne se trouvaient pas dans le champ mot-clé! Htdig vous permet de rechercher efficacement le texte intégral de l'article. Vos recherches reviendront instantanément et CHAQUE terme de l'article est entièrement consultable. Mettre les mots clés dans les balises META fera augmenter les recherches sur ces termes sur la page de résultats.
Un autre avantage est la correspondance floue. Si vous recherchez "activer", htdigg correspondra aux pages qui ont actif, activation, activité, etc. (configurable). Ou si l'utilisateur mal orthographié un mot, il sera toujours mis en correspondance. Vous voulez que vos utilisateurs aient une expérience similaire à Google, pas une expérience ennuyeuse. :)
Vous avez besoin d'un script pour créer une liste de liens vers toutes vos pages à partir de votre base de données. Demandez à htdig de l'explorer automatiquement et vous n'aurez plus jamais à y penser.
De plus, htdig explorera vos pages non liées à la base de données afin que tout votre site soit consultable via la même interface simple.
Quant au champ de mots-clés, vous devrait avoir une table distincte appelée mots-clés avec l'id de l'article et un champ de mot-clé (1 mot-clé par ligne). Mais pour simplifier, avoir un seul champ dans la base de données n'est pas une idée terrible, cela rend la mise à jour des mots clés assez facile si vous le mettez sous forme.
Si vous ne voulez pas vous soucier de tout cela, vous pouvez essayer d'utiliser recherche personnalisée Google . c'est beaucoup moins de travail, mais vous n'avez aucune garantie que toutes vos pages seront indexées.
Bonne chance!
Les champs TEXT, BIGTEXT, LONGTEXT et autres types de données ont été créés afin de stocker une grande quantité de texte (64 Ko à 4 Go selon le SGBDR). Ils créent simplement un pointeur binaire pour localiser le texte dans la base de données et il n'est pas stocké directement dans la table. Il s'agit presque de la même procédure si vous stockez un chemin dans un champ varchar pour localiser le document, mais l'avoir dans la base de données facilite la maintenance car si vous supprimez la ligne, le document disparaît avec lui sans qu'il soit nécessaire de le supprimer dans une autre procédure (comme si vous l'aviez stocké sous forme de fichier). Logiquement, cela rend votre base de données plus grande et parfois pas plus facile à sauvegarder et à transporter, mais transporter les documents un par un serait fastidieux et lent.
Comme vous le voyez, cela dépend du nombre de documents et de lignes dans la base de données.
Pour la procédure de recherche, je recommande de créer un nouveau champ "mots-clés" afin d'accélérer vos recherches. Vous pouvez également rechercher dans les n premiers caractères des documents, en les convertissant en CHAR ou VARCHAR et localiser le titre et le sous-titre dans ces montants s'ils n'ont pas déjà un champ spécifique.
Selon la façon dont vous avez tout arrangé et installé, il peut être difficile d'accéder à des fichiers externes à partir de clients distants qui peuvent très bien accéder à la base de données - alors pourquoi ne pas enregistrer tout le XML dans un champ TEXTE à la place? Vous pouvez refactoriser les choses pour optimiser cela plus tard si le moteur de base de données ne peut pas bien gérer cette charge, mais c'est la façon la plus simple de commencer.
Jetez un coup d'œil aux bases de données XML natives. Il y en a plusieurs, et certains très bons sont gratuits.
Recherche eXist, Document xDB, Oracle Berkeley.
Si vous persistez, interrogez et mettez à jour du texte semi-structuré et si la structure a une profondeur quelconque, vous le faites presque certainement à la dure si vous vous en tenez au RDB des pointeurs ou au stuff-it-in-a- techniques de blob - bien qu'il existe de nombreuses raisons extérieures pour lesquelles ces architectures peuvent être nécessaires et réussies.
Faites une petite lecture sur XPath et XQuery avant de vous engager dans une conception. Voici un bon endroit pour commencer: https://community.emc.com/community/edn/xmltech