Comment gérez-vous les petits ensembles de données?

Question

Avec de très petits ensembles de données, la politique dans laquelle je travaille est généralement de les coller dans des fichiers texte, mais dans mon expérience cela peut être un casse-tête de développement. Les données proviennent généralement de la base de données et quand ce n'est pas le cas, le processus impliqué dans le paramétrage/stockage est généralement caché dans le code. Avec la base de données, vous pouvez généralement voir toutes les données à votre disposition et les façons dont il se rapporte à d'autres données. Parfois, pour de très petits ensembles de données, je les stocke simplement dans une structure de données interne dans le code (comme un hachage Perl), mais lorsqu'un changement est nécessaire, c'est entre les mains d'un développeur.

Alors, comment gérez-vous les petits ensembles de données rarement modifiées? Avez-vous défini des critères d'utilisation d'une table de base de données ou d'un fichier texte ou ..?

Je suis tenté d'utiliser simplement une table de base de données pour absolument tout mais je ne suis pas sûr qu'il y ait des implications à cela.

Edit: Pour contexte:

On m'a demandé de mettre un nouveau formulaire de contact sur le site pour une poignée d'entreprises, plus à ajouter de temps en temps à l'avenir. Sauf, les entreprises n'ont pas d'adresses e-mail de contact .. les utilisateurs à l'intérieur de ces entreprises font (comme ils postent des emplois à travers leurs propres comptes). Maintenant, cependant, nous voulons une fonctionnalité de type "application spéculative" et le formulaire a besoin d'une adresse e-mail pour envoyer ces applications. Mais nous ne voulons pas non plus mettre une adresse e-mail en tant que propriété dans le formulaire, sinon les spammeurs peuvent simplement l'utiliser comme une passerelle de messagerie ouverte. Donc clairement, nous avons besoin d'une relation de type ID -> contact_email avec les entreprises. Donc, je peux soit ajouter une colonne à une table avec des millions de lignes qui seront utilisées, littéralement, environ 20 fois OU créer une nouvelle table qui, au plus, va contenir environ 20 lignes. Généralement, la façon dont nous gérons cela dans le passé consiste simplement à créer un fichier texte désagréable et à le lire à partir de là. Mais cela crée des cauchemars de maintenance et ces fichiers texte sont fréquemment examinés lorsque les données dont ils dépendent sont modifiées. Peut-être est-ce une faute dans le processus, mais je suis juste intéressé à entendre des points de vue là-dessus.

Answer 1

S'il s'agit de petites données de type config, j'utilise un format simple et commun. ini, json et yaml sont généralement ok. Les fans Java et .NET aiment aussi XML. en bref, utilisez quelque chose que vous pouvez facilement lire dans un objet en mémoire et oubliez-le.

Answer 2

Mettez le dans la base de données. S'il change rarement, mettez-le en cache dans votre niveau intermédiaire.

Answer 3

L'exemple qui vient immédiatement à l'esprit est ce qu'il est approprié d'avoir stocké comme une énumération et ce qui est approprié d'avoir stocké dans une table de base de données "recherche". J'ai tendance à "tracer la ligne" avec la règle que si cela aboutit à une colonne dans la base de données contenant un "nombre magique" mappé à une valeur d'énumération, alors l'énumération devrait vraiment exister en tant que table de recherche. Si elle n'est pas liée aux données stockées dans la base de données (par exemple, les données de configuration de l'application plutôt que les données générées par l'utilisateur), il s'agit d'une énumération complète.

Answer 4

Cela dépend de l'utilisateur de l'outil logiciel que vous avez développé pour consommer l'ensemble de données, indépendamment de la taille? Il se peut qu'ils connaissent Excel, donc votre outil devrait analyser un fichier .csv qu'ils créent.

Si c'est écrit pour les développeurs, alors qui se soucie de ce que vous utilisez. Cependant, je ne suis pas un fan des bases de données encombrantes avec des données mineures ou transitoires.

Answer 5

Nous avons un format de fichier de configuration standard (clé: valeur) et une classe pour le gérer. Nous utilisons simplement cela sur tous les projets. La plupart du temps, nous ne faisons que définir des propriétés persistantes pour nos applications (développement de téléphones mobiles). C'est donc une bonne chose à faire.YMMV

Answer 6

Dans les cas où le programme accède à une base de données, je vais y stocker tout: plus facile pour la sauvegarde et le déplacement des données.

Pour les petits programmes sans accès à la base de données, je stocke mes données dans les paramètres .net, qui sont stockés dans un fichier xml - bien sûr, c'est une caractéristique de C#, donc cela pourrait ne pas s'appliquer.

Quoi qu'il en soit, je m'assure de stocker toutes les données en un seul endroit. Habituellement une base de données.

Answer 7

je l'ajouter à la base de données dans le tableau principal:

1. de sauvegarde et de récupération (vous ne voulez récupérer ce fichier texte, non?)
2. interrogation Adhoc (puisque vous pouvez le faire sera Si la colonne de la base de données est vide, les exigences de stockage doivent être minimes (rien si c'est une colonne NULL à la fin de la table dans Oracle).
3. être plus facile si vous voulez avoir plusieurs serveurs d'applications car vous n'aurez pas besoin de o conserver plusieurs copies de certains fichiers de configuration supplémentaire autour
4. Mettre dans une petite table de l'enfant ne fait que compliquer la conception sans donner de réels avantages

Vous pouvez bien être déjà aller à cette même ligne dans la base de données dans le cadre de votre traitement de toute façon, donc la performance ne risque pas d'être un problème. Si ce n'est pas le cas, vous pouvez le mettre en mémoire cache.

Answer 8

Avez-vous considéré sqlite? Il est basé sur des fichiers, ce qui répond à votre sentiment que "juste un fichier pourrait faire" (configuration zéro), mais c'est une base de données parfaitement bonne et évolue remarquablement bien. Il supporte un certain nombre d'API et il y a numerous front ends pour l'administrer.