Although it’s easy to forget, Org tables have another life besides their obvious textual representation. It’s obvious when you think about it because you can operate on those tables either through the built-in Org table operators or directly with Elisp. But what, exactly, is the data structure that Elisp operating on a table sees?
The secret to dealing with Org tables is understanding that they’re held as a list of lists. Each of the inner lists represents a row with its elements being the column values. The outer list is the list of rows. That can make the code dealing with a table a little fiddly.
Ben Smith has a nice post that illustrates the best way I know of dealing with the data in each row in turn. The TL;DR is that you use on of the map functions (-map in Smith’s case) to look at each row and then use cl-destructuring-bind to name each column’s data. After that you can operate of each column’s data as needed.
Most of the time, the built-in Org table operators give you all the functionality you need but sometimes it’s necessary to write some Elisp to get the job done. Best’s post shows that this needn’t be hard. The code snippet that Best shows is short and easy to understand so there’s no reason not to take a look if you ever have to deal with Org tables using Elisp.