Nous avons toujours des données statiques qui peuvent être stockées dans un fichier sous forme de tableau ou stockée dans une table de base de données dans notre projet Web. Alors, lequel devrait être préféré?
À mon avis, les tableaux ont quelques avantages:
Mais mon collègue a fait valoir qu'il préférait l'approche de la DB, car elle peut conserver une interface de persistance des données uniformes et être plus flexible.
donc qui devrait être préféré? Ou comment pouvons-nous choisir? Ou nous devrions préférer un dans certains scénarios et un autre dans d'autres scénarios? Quels sont les scénarios?
EDIT:
Permettez-moi de clarifier quelque chose. Vraiment, comme Benjamin a apporté la modification du titre, les données que nous souhaitons stocker dans un tableau (fichier) ne changent pas si souvent, ce qui signifie que le code ne modifiera pas la valeur du tableau en cours d'exécution. Si les données changent très souvent, j'utiliserai db sans aucun doute. C'est pourquoi j'ai fait un tel post.
Et parfois il est difficile de stocker des relations vraiment complexes telles que: comme l'échantillon de code ci-dessus (A Python dict ou vous pouvez le penser comme une matrice), le champ exigeant est difficile à stocker dans dB (stockez une structure comme un objet mariné directement dans dB? Pas si bon je pense). Donc, dans une telle condition, je préférerai les tableaux. Alors, quelle est votre idée? Dans ce scénario, nous devrions préférer des tableaux à DB, non? Cordialement.
6 Réponses :
Cela dépend du type de données que vous examinez et si elle doit être mise à jour régulièrement.
J'ai tendance à garder la plupart des choses (données de non-configuration) dans la base de données, même si les données ne vont pas répéter (par ex. thosands de lignes). Les bases de données s'élèveront tellement plus facilement qu'un fichier plat, si votre système commence à augmenter rapidement votre fichier plat pourrait devenir un fardeau de votre système.
Si les données ne changent pas très de l'arrière et de votre programmation en Java, pourquoi ne pas utiliser de ressort pour contenir les valeurs?
Ils peuvent être injectés dans votre haricot et changés facilement.
Mais c'est-à-dire si vous développez en Java.
Désolé, nous n'utilisons pas Java. Et nous utilisons Python à la place.
Le tableau "flexible" dans un fichier est semé d'une zillion de problèmes déjà delt avec en utilisant un DB. À moins que vous ne puissiez prouver que la base de données est vraiment plus lente que d'utiliser l'autre approche, utilisez un DB. Passer et commencer à résoudre les problèmes d'entreprise.
Commentaire de OP demande quelles sont les problèmes avec l'utilisation d'un fichier, voici une poignée (pause de prendre une respiration profonde).
Merci. Alors, quelles sont les problèmes de fichier? Pouvez-vous donner un exemple?
Cela compte vraiment si ce sont aussi des valeurs constantes. Si vous parlez d'États (c'est-à-dire Connecticut, New York, etc.) qui ne changent pas souvent, la solution en mémoire pourrait être meilleure. vraiment dépend de la situation et de la façon dont vous allez l'utiliser.
Salut, Anthony. Désolé pour la confusion dans le poteau. J'ai fait des éclaircissements. Donc, certains problèmes ne se produiront pas dans le scénario clarifié.Merci de la même chose.
La question de demander des "données statiques" et vous parlez de mettre à jour les données. Votre réponse semble répondre au fichier de questions générales vs dB, mais la question concerne les "données statiques" dans une matrice et non des données régulières ...
@Benjisail: C'est vrai que mon addition répond au commentaire est générale et tout n'est pas une préoccupation directe pour les données de déménagement lentes (bien qu'il soit reconnu que ces données changent et ne sont donc pas vraiment "statiques"). Cependant, je me tiens toujours à ma réponse initiale que, sauf décision prouvée pas d'utiliser la base de données, puis utilisez-la.
Votre collègue est correct, mais il y a là que vous devez mettre de côté le manuel Comp SCI et être pragmatique. À quelle fréquence allez-vous accéder à ces données de votre application? S'il est assez fréquemment, n'engagez pas les coûts des frais généraux d'accès. Au lieu de lire un fichier plat, vous pouvez toujours gagner les avantages d'une DB, mais utilisez une stratégie de mise en cache dans votre application. En fonction de votre langue de développement, vous pouvez regarder quelque chose comme MemCache ou Jtreecache.
Merci. Nous utilisons Python / Django. Les données seront statiques lorsque l'après le début du serveur (signifie que nous pouvons modifier la matrice manuellement mais ne se produira pas si souvent). Il peut donc arriver à une autre question, pouvons-nous cacher des matrices que j'ai apportées une nouvelle question. Stackoverflow.com/Questtions/1680349 / ...
Ouais Je suis d'accord avec votre évaluation implicite que les bases de données sont surutilisées et que les fichiers plats de base peuvent travailler dans la multitude de scénarios. Si votre application est en lecture seule (et les écrit sont effectués par l'administrateur lorsque l'application redémarre), je vais certainement aller avec le fichier. Même si l'application écrit au fichier, mais uniquement en mode ajoutant (VS inserts / mises à jour / mises à jour) dans un thread, je voudrais également utiliser le fichier. N'importe quoi d'autre - Besoin d'une vraie base de données avec des mises à jour, des requêtes, du contrôle de la concurrence, etc.
Tout argument sur le fichier préférant le fichier à dB? Depuis que je ne suis pas si clair.
permet d'être pragmatique / objettive:
Bien sûr, j'ai oublié d'autres points, mais je suppose que les bases sont là.