Data Structures — Arrays, Linked Lists, Trees & Graphs

Choosing a data structure is less about memorizing arrays, linked lists, trees, and graphs, and more about following a short procedure: name the shape of your data, name the operation that has to feel cheap, then match. Data structures are ways to organize data so common tasks such as lookup, insertion, deletion, and traversal become easier.

Use this method whenever you are deciding how to store something and you want the most common operation to be fast. The procedure narrows four candidates down to one without guesswork.

The Procedure For Picking A Structure

1. Identify the shape of the data. Ask whether your data is mainly a sequence, a hierarchy, or a network of relationships.
2. Identify the important operation. Decide whether fast indexing, local insertion, hierarchical search, or path-finding matters most.
3. Match the structure. Arrays fit ordered sequences, linked lists fit chained nodes, trees fit hierarchies, and graphs fit general connections.
4. Check the condition. Performance depends on implementation details such as whether a tree is balanced or whether an array must resize.

The shortest useful version of step 3 is:

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

To run the procedure well, you need to know what each candidate actually does. 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, so to reach the $n$th item you usually traverse earlier nodes, making access by position typically $O(n)$. A tree stores data in levels, where each node can have children, naturally representing nesting such as folders inside folders; costs depend on the kind of tree and whether it stays balanced. A graph stores nodes and edges, and unlike a tree a node can connect to many others in arbitrary ways with cycles allowed, which makes graphs the natural model for roads, social networks, and dependency maps.

Running The Procedure On One Campus App

Suppose you are building one campus app with a schedule screen, a course catalog, and a walking map. Apply the procedure feature by feature.

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

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

The course catalog is naturally a tree:

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.

Where The Procedure Breaks Down, And How To Self-Check

Step 2 stalls: "everything seems important"

Ask the sharper question: what operation should feel cheap? If "jump to position $i$," arrays are strong. If "follow the next connection," linked structures help. If "move down a hierarchy," trees fit. If "find whether two things are connected," graphs fit.

Assuming one structure is always fastest

There is no universal winner. Self-check: name the operation you do most often before declaring anything "fast."

Treating trees as automatically efficient

Some trees support very efficient search, but that depends on tree type and balance. A badly shaped tree can perform much worse than a balanced one. Self-check: confirm the balance condition before relying on tree speed.

Choosing a linked list just because insertion sounds cheap

Insertion can be cheap once you already have the right node, but finding that node may still cost time. Self-check: count the search step, not just the insert.

Forcing graph-shaped data into a tree

If an item can have several parents, cross-links, or cycles, a tree hides the real structure. Self-check: does any item have more than one parent? If yes, it is a graph.

Confusing an abstract structure with a language feature

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

Where Each Structure Shows Up

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.

When you are unsure, sketch a tiny version of the data on paper. Pick three familiar examples, say a playlist, a folder system, and a transit map, label each as sequence, hierarchy, or network, and the right structure usually reveals itself before any code does.