Comment gérez-vous de 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 selon mon expérience, cela peut être un casse-tête pour le développement. Les données proviennent généralement de la base de données et, dans le cas contraire, le processus impliqué dans sa configuration / stockage est généralement masqué dans le code. Avec la base de données, vous pouvez généralement voir toutes les données dont vous disposez et leur lien avec 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, il est entre les mains d'un développeur.

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

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

Modifier: pour le contexte:

On m'a demandé de mettre un nouveau formulaire de contact sur le site Web pour une poignée d'entreprises, avec d'autres à ajouter occasionnellement à l'avenir. Sauf que les entreprises n’ont pas d’adresses de courrier électronique de contact. C’est ce que les utilisateurs à l’intérieur de ces entreprises ont (comme ils affichent des offres via leurs propres comptes). Mais maintenant, nous voulons une "application spéculative". tapez la fonctionnalité et le formulaire nécessite une adresse e-mail pour envoyer ces applications. Mais nous ne souhaitons pas non plus définir une adresse électronique comme une propriété du formulaire, sinon les spammeurs peuvent simplement l’utiliser comme passerelle de messagerie ouverte. Alors clairement, nous avons besoin d'un identifiant - > contact_email type relation avec les entreprises.

SO, 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 contiendra tout au plus environ 20 lignes. En général, la façon dont nous gérons cela par 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 consultés lorsque les données dont ils dépendent dépendent des modifications. C’est peut-être une faute dans le processus, mais j’aimerais seulement entendre des opinions à ce sujet.

Answer 1

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

Answer 2

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

Answer 3

L’exemple qui me vient immédiatement à l’esprit est ce qu’il est approprié d’avoir stocké comme énumération et ce qui est approprié d’avoir stocké dans une "recherche". table de base de données.

J'ai tendance à "tracer la ligne". avec la règle que s'il en résulte une colonne dans la base de données contenant un "nombre magique" mappant sur une valeur d'énumération, l'énumération devrait réellement exister en tant que table de recherche. S'il n'a aucun lien avec les 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 alors d'une énumération complète.

Answer 4

Cela dépend sûrement de l'utilisateur du logiciel que vous avez développé pour consommer l'ensemble des données, quelle que soit leur taille.

Il se peut simplement qu'ils connaissent Excel, votre outil devrait donc analyser un fichier .csv qu'ils ont créé.

Si cela est écrit pour les développeurs, alors qui se soucie de ce que vous utilisez. Je ne suis cependant pas fan de l'encombrement de bases de données contenant 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 ne l'utilisons que pour tous les projets. La plupart du temps, nous ne faisons que définir des propriétés persistantes pour nos applications (développement de la téléphonie mobile), c'est donc une bonne chose à faire. YMMV

Answer 6

Dans les cas où le programme accède à une base de données, je stocke tout ce qui s'y trouve: il est plus facile de sauvegarder et de déplacer 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 entendu, il s'agit d'une fonctionnalité de c #, de sorte qu'elle risque de ne pas s'appliquer à vous.

Quoi qu'il en soit, je m'assure de stocker toutes les données au même endroit. Généralement, une base de données.

Answer 7

Avez-vous envisagé de sqlite ? Il s’agit d’un fichier, ce qui vous permet de penser que "seul un fichier peut suffire". (configuration zéro), mais c'est une base de données parfaite et évolue remarquablement bien. Il prend en charge un certain nombre d'API et de nombreux frontaux permettent de l'administrer.

Answer 8

Je l'ajouterais à la base de données dans la table principale:

1. Sauvegarde et récupération (vous voulez récupérer ce fichier texte, non?)
2. Interrogation ad hoc (vous pouvez le faire à l'aide d'un outil SQL et le joindre aux autres données de la base de données)
3. Si la colonne de la base de données est vide, la configuration de magasin requise doit être minimale (rien s'il s'agit d'une colonne NULL à la fin de la table dans Oracle)
4. Cela sera plus facile si vous souhaitez avoir plusieurs serveurs d’applications car vous n’aurez pas besoin de conserver plusieurs copies d’un fichier de configuration supplémentaire
.
5. Le placer dans une petite table enfant ne fait que compliquer la conception sans donner de réels avantages

De toute façon, vous allez peut-être déjà accéder à cette même ligne de la base de données dans le cadre de votre traitement. Les performances ne risquent donc pas de poser problème. Sinon, vous pouvez le mettre en cache dans la mémoire.