Table of Contents
Overview
In MATLAB, tables, structures, and cell arrays are three flexible container types that help you organize and work with different kinds of data. They become important once your variables are no longer simple vectors or matrices, and you need to keep track of names, heterogeneous types, or more complex relationships between pieces of information.
Each of these containers is suited to a different style of data organization. Tables are useful when your data looks like a spreadsheet or a data set with named columns. Structures are useful when you want to group related pieces of information under named fields, similar to records. Cell arrays are useful when you need indexed containers that can hold values of different sizes and types in each position.
This chapter gives you an overall picture of these three containers, how they differ from basic numeric arrays, and why MATLAB provides more than one such type. Details such as how to create, index, or modify each kind of container are discussed in later chapters within this section. Here the focus is on understanding the general role of each container type and how they fit into your workflow.
Why You Need Richer Container Types
Numeric arrays are the default way to store data in MATLAB. They are efficient and powerful, but they have two important limitations. All elements in a numeric array must have the same data type, typically double, and the array is organized purely by numeric indices without any meaningful names for rows or columns.
In practice, many data sets and programs involve collections of values that do not fit neatly into a single numeric matrix. You might have a mix of numbers, text labels, and logical flags. You might have measurements with associated metadata like subject ID or date. Or you might have results of varying sizes, such as vectors of different lengths from repeated experiments.
To handle these situations cleanly, MATLAB offers container types that relax one or both of these constraints. Tables let you combine mixed data types in a 2D, column oriented layout, with names for variables and often for rows. Structures group fields by name, so you can build records or configuration objects that refer to their contents with meaningful identifiers. Cell arrays store arbitrary types at each cell, so they give you a flexible, index based container that can still be nested inside other arrays.
The choice among these containers reflects the way you think about your data. If the natural view is a spreadsheet, tables are usually appropriate. If you think in terms of an object or record with properties, a structure is more suitable. If you need a generic box that holds anything at each index, cell arrays are often the right tool.
What Tables Represent Conceptually
Tables represent column oriented, heterogeneous data, similar to a spreadsheet or a data frame in other languages. Each column in a table is a variable, and each row is one observation or record. Unlike a numeric matrix, the entries in one column can be numeric, in another column logical, in another column strings, and so on, provided that each column itself remains internally consistent.
At a conceptual level, you can think of a table as a mapping from variable names to column data, with the extra structure that all columns share the same number of rows. MATLAB lets you refer to variables by their names, which promotes code that is easier to understand. For example, instead of writing data(:,3) and trying to remember that column 3 is age, you use something like patients.Age or T.Age using the variable name directly.
Tables keep track of metadata like variable names and optionally row names, descriptions, and units. This makes them especially suitable for real world data analysis tasks, where you import data from files, manipulate and clean it, compute new variables, and then export or plot the results. They bridge the gap between free form numeric arrays and more strongly typed data structures.
The central idea is that a table is aimed at working with rectangular, record oriented data, where each column can have its own type and meaning, and where column names are part of the structure of the data.
What Structures Represent Conceptually
Structures in MATLAB group related data fields together under a single variable name, using named fields instead of numeric indices. Conceptually, a structure is like a record or a simple object that contains a set of named components. Each field can hold any kind of value, including numbers, arrays, strings, other structures, or cell arrays.
You access the contents of a structure using dot notation, such as config.maxIter or user.name. This style of access emphasizes meaning rather than position. You do not need to remember that, for example, the tolerance value is the second column of a matrix. Instead, you store it as config.tolerance and refer to it explicitly by name.
Structures are particularly useful for grouping related parameters, options, or results. For example, the output of a function that computes several quantities can be packaged into a structure, with one field per output. This keeps the function interface simple and makes downstream code easier to read, because field names document what each value represents.
Unlike tables, structures are not inherently rectangular, and there is no requirement that different fields have the same size. This flexibility is powerful, but it also means that structures are better suited to representing individual records or collections of records where the shape of each field may differ, rather than large column oriented data sets.
What Cell Arrays Represent Conceptually
Cell arrays provide a general way to store collections of values where each element can be of any type and size. A cell array has a regular array shape, just like a numeric matrix, but each location in that shape is a cell that contains a separate piece of data. You can think of each cell as a box. The boxes are organized by numeric indices, and the content of each box can be anything that MATLAB can store.
Conceptually, cell arrays are useful when you want indexed access to heterogeneous contents. For example, you may have a list of file names as strings, a set of numeric vectors of differing lengths, or a series of matrices that are not all the same size. A numeric array cannot represent this situation because all elements must share the same size and type. A cell array solves this by letting each cell hold one of these items.
MATLAB gives cell arrays their own indexing syntax, which distinguishes between accessing the cell itself and accessing the content stored inside that cell. This dual nature is fundamental to how you use them. While the syntax details are covered in a later chapter, at the conceptual level it helps to remember that a cell array is really an array of containers, not an array of the contained values directly.
In many workflows, cell arrays act as intermediate or flexible data holders where uniformity is not guaranteed or not yet known. After processing, you might convert the contents into more structured forms such as numeric arrays or tables when dimensions become compatible.
How These Containers Differ from Numeric Arrays
Numeric arrays in MATLAB are homogeneous. Every element shares the same data type, and operations like addition or multiplication act on the whole array in a regular, elementwise or matrix-based fashion. The indexing uses only numeric indices, and there are no names associated with positions in the array.
Tables, structures, and cell arrays deviate from this model in different ways. Tables maintain a regular rectangular structure but permit heterogeneous types across columns. They also attach names to columns and optionally rows, so that you can refer to data pieces symbolically. Many operations on tables are specialized for columnwise manipulation, such as adding or removing variables.
Structures discard the requirement of a rectangular arrangement and instead center on named fields. The collection of field names, rather than the shape of an array, determines the structure. Operations with structures are usually about accessing, adding, or modifying fields rather than applying arithmetic operations across all elements at once.
Cell arrays keep the familiar array shape but treat each element as an independent container that may hold something of a different type or size. The language of indices still applies, but the semantics of operations are often about looping or mapping functions over cells, retrieving or assigning contents, and managing collections of heterogeneous items.
Another important difference lies in how MATLAB handles built-in operations. Many numeric computations work directly on numeric arrays. For these containers, computations are usually more explicit. You might iterate over table variables, fields of a structure, or cells of a cell array, or you may use dedicated functions that know how to operate on these higher level containers.
When to Choose Each Container Type
The choice between tables, structures, and cell arrays typically reflects both the nature of your data and how you intend to work with it.
Tables are a natural choice when you have observational data arranged in rows, with each column representing a variable that can have its own type. They are especially appealing when you will sort, filter, join, or summarize data by variables, and when you care about preserving or using variable names throughout the analysis.
Structures work well when you think in terms of an entity with attributes. Configuration settings, user information, or grouped function outputs map naturally to structures. The field names form part of the documentation of your code. Structures also provide a useful bridge between different parts of a program, since they can hold related pieces of information together under one variable.
Cell arrays are the tool of choice when you must manage ordered collections of items that are not uniform. If you have a list of data blocks from a loop, or you are handling multiple outputs from operations that do not produce the same shape each time, cell arrays provide a flexible container without imposing strong structural constraints.
In many real applications, you will combine these containers. For example, a table variable might itself be a cell array of strings, or a structure field might hold a table, or a cell array may contain several structures. The important point is to recognize which container is best suited to the main level of organization in your problem, then refine the internal representation as needed.
Interactions with Other MATLAB Features
These container types integrate with other parts of MATLAB. Functions for importing data from files often return tables when the data has a natural columnar form. Many higher level toolboxes work with tables as inputs and outputs, since they carry both data and labels. Structures are frequently used for optional arguments and for storing results from functions that return multiple related values.
Cell arrays are commonly used with functions that operate on collections, such as those that apply a given function to each element. They also interact with string handling, since historical MATLAB code often represented lists of character vectors as cell arrays, and some interfaces still expect that format.
Because these containers can hold arbitrary types, they also appear in contexts where data must be generic, such as user interface callbacks, application data, and flexible logging or configuration systems.
Being aware that tables, structures, and cell arrays exist and are designed for different patterns of use helps you read existing MATLAB code more effectively. You will often recognize them by their syntax, such as dot notation for structures and tables, or curly brace indexing for cell arrays. Understanding at a high level what each container represents will make it easier to follow and extend such code.
Tables are best for column oriented, rectangular data with named variables. Structures group related pieces of information under named fields without requiring a rectangular layout. Cell arrays are indexed containers where each cell can hold data of any type or size. Choose the container that matches how you think about and access your data, not just the one that happens to work.