Data Structures — Arrays, Linked Lists, Trees & Graphs

Data structures are ways to organize data so common tasks such as lookup, insertion, deletion, and traversal become easier. If you want to understand arrays, linked lists, trees, and graphs, the fastest approach is to ask two questions: what shape does the data have, and what operation needs to feel cheap?

If the data is a sequence, an array is often the starting point. If each item mainly points to the next item, a linked list may fit. If the data has levels, use a tree. If items can connect in many directions, use a graph.

Here is the shortest useful rule:

• Array: best for indexed order.
• Linked list: best for chained local links.
• Tree: best for hierarchy.
• Graph: best for networks.

What arrays, linked lists, trees, and graphs actually do

An array stores items in a fixed order and lets you refer to a position directly, such as "item $7$". In the usual contiguous implementation, that direct indexing is $O(1)$.

A linked list stores items as nodes, where each node points to another node. You can move from node to node, but to reach the $n$th item you usually have to traverse through earlier nodes, so access by position is typically $O(n)$.

A tree stores data in levels. Each node can have children, so the structure naturally represents nesting such as folders inside folders. Search and update costs depend on the kind of tree and whether it stays balanced.

A graph stores nodes and edges. Unlike a tree, a node can connect to many others in arbitrary ways, and cycles are allowed. That makes graphs the natural model for roads, social networks, and dependency maps.

Quick comparison: when each data structure fits

Structure	Best mental model	Usually good at	Common limitation
Array	A numbered row of items	Direct access by index	Middle insertions and deletions often require shifting items
Linked list	A chain of nodes	Inserting or removing near a known node	Random access is slow
Tree	A branching hierarchy	Representing levels and parent-child relationships	Behavior depends heavily on tree type
Graph	A network of connections	Reachability, paths, and relationships	Algorithms are often more complex

Worked example: choosing structures in one campus app

Suppose you are building one campus app with a schedule screen, a course catalog, and a walking map. The easiest way to choose a data structure is to match each feature to the shape of its data.

The weekday tabs for a schedule screen are naturally an array:

$$[\text{Mon}, \text{Tue}, \text{Wed}, \text{Thu}, \text{Fri}]$$

The key feature is direct access by position. "Show me tab $3$" makes sense, and the order matters.

The course catalog is naturally a tree:

$$\text{Department} \rightarrow \text{Course} \rightarrow \text{Section}$$

Each level contains the next level. That is a hierarchy, so a tree is the cleanest model.

The walkways between buildings are naturally a graph. A building can connect to several others, and paths can loop back. If you want the shortest route from the library to the lab, you are solving a graph problem, not a tree problem.

A linked list fits a narrower part of the same app: a chain of recently visited screens, if the main operation is moving forward or backward one step at a time. In that case, each screen mainly needs links to nearby screens rather than fast access to the $20$th screen.

The lesson is that "best" depends on the job. One product can use several data structures because different parts of the data have different relationships.

How to tell them apart quickly

Many students first learn these as vocabulary words. That makes the topic feel abstract, but the practical question is simpler.

Ask: what operation should feel cheap?

If you want "jump to position $i$" to be cheap, arrays are strong. If you want "follow the next connection" to be cheap, linked structures help. If you want "move down a hierarchy," trees fit. If you want "find whether two things are connected," graphs fit.

Common mistakes when learning data structures

Assuming one structure is always fastest

There is no universal winner. "Fast" depends on what you do most often and on the implementation.

Treating trees as automatically efficient

Some trees support very efficient search, but that depends on the tree type and on structural conditions such as balance. A badly shaped tree can perform much worse than a balanced one.

Choosing a linked list just because insertion sounds cheap

Insertion can be cheap once you already have the right node. Finding that node may still cost time.

Using a tree when the data is really a graph

If an item can have several parents, cross-links, or cycles, forcing the data into a tree can hide the real structure and make later operations awkward.

Confusing an abstract structure with a language feature

"Array," "list," "map," or "tree" in a programming language may come with implementation choices that affect memory use and speed. The abstract idea and the concrete container are related, but they are not identical.

When arrays, linked lists, trees, and graphs are used

Arrays are used for ordered collections, tables, buffers, and any case where position matters.

Linked lists appear in specialized implementations where local pointer updates matter more than random access.

Trees are used for hierarchical data such as file systems, document structure, expression trees, and many search indexes.

Graphs are used for routes, dependency analysis, network modeling, recommendation links, and connection problems in general.

How to choose the right data structure

Start by asking two questions:

1. What relationship does the data have: sequence, hierarchy, or network?
2. What operation matters most: indexing, local update, hierarchical traversal, or path-finding?

Those two answers usually narrow the choice quickly.

If you are still unsure, sketch a tiny version of the data on paper. The picture often reveals the structure before the code does.

Try your own version

Pick three familiar examples such as a playlist, a folder system, and a transit map. Identify whether each one is mainly a sequence, a hierarchy, or a network, then choose the structure that makes the main operation easy. If you want another case to test yourself on, GPAI Solver can generate similar classification examples.