Presque tout dans les logiciels fonctionne sur la quantité. C'est ce que font les structures de données : elles fournissent un moyen de contenir la quantité. Différentes structures ont des caractéristiques de performance différentes.
De loin, la plus souvent rencontrée est le tableau. Les tableaux sont traditionnellement statiques. Cela signifie que leur taille est connue à l'avance et qu'un nouveau tableau doit être créé pour contenir une plus grande quantité. La plupart des langages proposent une sorte de tableau dynamique, parfois appelé vecteur, liste, liste de tableaux, etc. Il s'agit d'une structure de données qui abstrait les détails du redimensionnement d'un tableau lorsque cela est nécessaire. Cela donne l'impression que vous pouvez continuer à ajouter/supprimer des éléments sans avoir à gérer la mémoire directement.
Les langages dynamiques comme Python, PHP, JavaScript implémentent en fait un tableau comme une DoublyLinkedList sous le capot, et optimisent la sémantique des tableaux si et seulement si les index sont des nombres séquentiels.
Lorsque vous utilisez des API système de bas niveau dans Windows/Linux, vous rencontrerez souvent le besoin d'utiliser des pointeurs vers ce qui sont manifestement des listes liées (plutôt que des tableaux). Dans le très ancien temps, je suppose que les LinkedLists étaient préférables probablement parce qu'elles économisaient de la mémoire par rapport à de grandes allocations de mémoire comme un tableau le nécessiterait.
La prochaine structure de données la plus couramment rencontrée que j'ai rencontrée est le Stack. Les piles sont follement utiles pour laisser des miettes de pain, des traces de pile, etc.
Et puis je dirais la file d'attente. Mais je ne rencontre pas souvent une Queue en mémoire, mais plutôt une Queue de messages pour gérer les communications distribuées. Ces Queues écrivent dans le système de fichiers ou le réseau plutôt que dans la mémoire.
Un système de fichiers sur le disque dur, la carte flash, le CD-ROM, etc sont tous des arbres. L'idée d'une hiérarchie de dossiers et de fichiers... est un arbre. En interne, c'est une sorte d'arbre B*. Mais techniquement, c'est un arbre non ordonné.
La seule fois, en dehors de la préparation d'un entretien, où j'ai rencontré un graphe, c'est lorsque j'ai dû en écrire un, en utilisant un Tri topologique, pour construire un compilateur C# distribué afin de réduire un temps de construction de 49 minutes (pour plus de 500 projets C#) à 20 secondes. Le graphe suivait les dépendances et leur niveau afin de déterminer le niveau de parallélisme et le moment où il fallait construire quoi, ainsi qu'un système de fichiers distribué pour que les autres nœuds n'aient pas à construire la même dépendance. Dans les jeux, vous rencontrerez beaucoup de graphes aussi pour définir un chemin d'ennemis pour vous trouver.