I would like to have hints on the best way to organize my dataset (I am working with ArcGIS 10.1, advanced license). I would like to build a points layer, each point being a weather station in the study area. For each weather station, I wish to store some data, consisting in the winds speed, average direction, air temperature, and the like. My main issue is that each set of variables is repeated for each month of the year. I am not managing to get my head around the best way to arrange the attribute table. May be I should only build a layer of points with the attribute table storing only the station name, and a sub-table with further data.... But I would like to have feedbacks on this, and possibly practical examples (i.e., URLs) of a good strategy to tackle the issue.
The 'best' way depends on your intended use and the data itself. PolyGeo's comment and my answer at your follow-up question both suggest reviewing Join vs Relate. Your data can make use of a Relate, but doesn't have to. Some data sets don't have that choice. It's all about columns and rows.
You have a set number of points. As long as each point has one and only one row in the table, a Join is fine if even necessary at all. This is because one-to-one relationships are easy to deal with. In your case, you can arrange your data such that each station has one row, and each row has however many columns to account for the months and different readings of weather (up to a little over 65k columns). In such a case you don't even need two tables - one would suffice. Or you could have a table per month/per year/etc - however you want to break it down and the number of joins you'd want to make or manage.
The problem is when you have more than one row for each point. Now we're talking one-to-many, and ArcGIS can't handle that without a Relate or Query Table duplicating points. If you have a column for each data reading and a row for each station and month, there's more rows than there are points and it won't know which row you want to look at. It'll just take the first one with a matching station ID and return that value, ignoring the rest.
Sometimes you don't have a choice. Consider a house inspection table. Each house is an ID. But inspections can occur any day of the year. An attribute field for every day of the year would be really inefficient for 500 houses where only three or four are inspected on any given day. So you set your data up so that each house is a point/row in one table, and your other table has a list of inspections with house ID. A Relate will let you look up all the matching rows in the inspection table for a selected house ID. But geoprocessing tools can't really do this so far as I know - they need geometry for every record they work with. Relates can create selections, so it may be possible to use that setup with some intermediate steps to create a subset/layer that you can feed to a geoprocessing tool, but that's beyond me.
For this reason, given you want to do point interpolation, I suggest a single table. Each station gets one row. Each row has (readings x month+year) columns. If you have four readings taken once a month for five years, you'll have 240 columns. If you don't want to deal with that many columns, then break it down by year and use 1+x tables. One, your geometry, will have the points and station ids. The other tables will have station ID, and a field for each reading each month of a given year. Then you can use a Join to pull in one year at a time. Depending on how much data you're working with, the next thing you'll want to look at is Models and iteration so you can automate the process.
This is admittedly a simplistic/brute force approach to the data. There may be more advanced tools and or methods out there that can do more at once.