2010-06-29 15 views
1

Juste une petite question. Dois-je mettre le contenu HTML textarea dans une base de données ou un fichier plat? Le contenu de textarea peut être très long (comme un article ou un projet).DB ou fichier plat?

Merci de votre aide. Silvio.

+0

Faites-moi savoir s'il vous plaît la base de données que vous utilisez. 'Question' n'est pas un tag approprié –

+0

Quel type de contenu? Combien d'utilisateurs accèderont aux données? L'accès en écriture se produira-t-il simultanément? Qu'est-ce qui est "très long" en octets? – joschi

+0

Il y a des cas légitimes où un fichier plat peut avoir du sens, mais impossible à répondre sans connaître le but de l'application. – roryf

Répondre

2

Utilisez texte type au lieu de chaîne, varchar type en db.

Remarque: champs -Text dans mysql sont limités à 65kb

EDIT

OU Vous devriez envisager d'utiliser MySQL's LONGBLOB or LONGTEXT type de données. Ils peuvent stocker jusqu'à 4 gigaoctets de données binaires ou textuelles, respectivement.

+0

texte n'est pas nécessairement une bonne option, car il est obsolète [source MSDN] (http://msdn.microsoft.com/en-us/library/ms143729.aspx) – slugster

+0

@slugster vérifier modifier la partie .. Est-il bien? –

+0

mon mauvais, je n'aurais pas dû supposer SQLServer, votre mention d'autres DB et leurs types est parfaitement valide. +1 – slugster

1

Base de données sans aucun doute.

Il n'y a pas beaucoup de points dans les fichiers plats car lorsque vous commencez à développer ce que vous allez faire, vous devez créer plus de fichiers et il est plus facile de perdre la trace. Commencez avec une base de données et lorsque vous grandissez, vous pouvez faire des choses beaucoup plus rapidement et des sélections plus complexes en utilisant structured query language le nom dit tout.

+0

Une base de données relationnelle n'est pas toujours le marteau correspondant pour votre ongle ... – joschi

1

Voici quelques avantages et les inconvénients du haut de ma tête (je l'ai fait dans les deux sens avec différents niveaux de réussite):

Pros Base de données

  • modèle bien connu pour la lecture/écriture de données.
  • Si le reste de votre application est basée sur une base de données, cette solution convient parfaitement.
  • La base de données dispose déjà de mécanismes de concurrence.
  • Tant que vous sauvegardez votre base de données, vos documents sont sauvegardés (et synchronisés avec l'état de votre base de données).

Base de données Moins

  • En théorie, il est moins efficace de tirer un fichier à partir d'une base de données que directement à partir du système de fichiers. Le serveur db doit lire à partir du disque, traduire dans son protocole réseau, etc.
  • La diffusion de ces fichiers à partir de la base de données est un goulot d'étranglement potentiel lié à l'évolutivité si un seul serveur de base de données est utilisé.

Pros fichier plat

  • opérations simples Dirt: écriture, suppression, lecture.
  • Préférablement faible. Si vous utilisez Web, le serveur peut simplement être pointé vers les fichiers.

fichier plat Contre

  • vous devez traiter des opérations de concurrence (si un utilisateur veut écrire dans le fichier, tandis qu'un autre est en train de lire, etc.). Cela peut ou peut ne pas être un problème dans votre cas.
  • Il s'agit d'un autre type d'informations à sauvegarder/conserver en synchronisation/maintenance.
  • Vous devez traiter la sécurité des fichiers comme un problème distinct du reste des données de la base de données.
Questions connexes