SQL Server – Difference Between Record and Row

There are a number of options and please don't limit yourself to my answer here. In particular you may find array-native databases to be of help. My answer is going to be specifically about your questions on SQL-based databases.

It sounds to me like this is a question of geospacial information. SQL-based databases are in fact used in such fields quite well, but this is also a specialist field within databases.

Among the SQL databases in this area, PostgreSQL, with the PostGIS add-on is considered one of the best. If I were you, this is where I would start. The primary advantage of SQL is that it preserves flexibility down the road regarding re-use of your data for uses you haven't thought of yet. Doing this with good geospacial support means that you can calculate distance across a large area without worrying about the specifics of spherical trig.

Of course this only becomes a factor with very large grids. For smaller grids, where the curvature of the earth can be disregarded, PostgreSQL also has a range of geometric types including points on a coordinate system which can be used. I mention this because it isn't clear how large of an area is being surveyed and whether one can assume plane geometry or not.

Even so PostGIS may still simplify things by allowing representations and calculations on 3- and 4-dimensional geometric coordinate systems.

Also note that you say your sites are not necessarily square. In PostgreSQL one thing you can do (either using the geometric types or PostGIS) is define a non-rectangular boundary to each site so you can check to make sure a point is inside the bounds of the site before saving the measurement.

Declarative Language Impacts

This concern I think is overblown. People can and do write SQL queries as if they are a part of the imperative language of the program they are calling them from. For most of your queries it won't matter.

What people mean by a declarative language is that within a query, the structure tells the database what information you want, not how to get it. This is important when you want complex information from the database because basically it means that if you can ask the right question (and your data is valid) you will get the right answer.

The big difference that occurs however is that long SQL queries are easier to debug than long imperative subroutines, simply because one can more quickly narrow down where in the query the malfunction occurs.

How this would work

Chances are if you go this route you'd have a database and a program written in a language of your choice. The program would send queries to the database and get the answers back. You can also (in PostgreSQL and many other relational DB's) put your queries inside functions which can then be called by the application, giving more of an imperative or functional interface. Data would be stored on disk and accessed from a separate piece of software than your program. You could also connect with another program (from MS Access to pgAdmin) and run queries or generate reports.

In essence you can think of the RDBMS as a "math engine" which manages your data, and your program interacts with it to do what you need.

Relational database theory does not include the use of the word Field. Dr. E.F. Codd, who wrote the series of papers that provide the theoretical basis for RDBMS's never used the term. You can read his seminal 1970 paper A Relational Model of Data for Large Shared Data Banks if you want to check.

Terms like Domain, Table, Attribute, Key and Tuple are used. One reason for this, is that his papers were largely concerned with relational algebra, and the way a particular implementation would define a table in a database wasn't considered by Codd to be important. Vendors would flesh that out later. People also have to understand that historically, RDBMS's evolved from existing hierarchical and network databases that predate them, AND the inner workings of an RDMBS still have to be concerned with data organization and storage.

In common use, and you can easily verify this by simply doing a bit of googling, Fields and columns are the same thing.

PC Databases like DBase, Access and Filemaker typically use "field" instead of "column". "Attribute" is another term that can be used interchangeably.

For example, here's a link to the MS Access manual on adding a "field" to a table. It's clear to see that in MS Access a "field" is equivalent to a "column".

The same holds for Dbase and Filemaker Pro.

Sometimes people will refer to a specific value in a specific row as being a "field" or more properly a "field value" but that does not make the use of "field" when referring to a column or column-equivalent-concept incorrect. This does tend to cause a level of confusion because people have used "field" to mean different things for many years. In relational theory -- a single atomic value is referred to as a "Datum".

If someone stated that a "field" is one value in a relational database and not the same as a column, that is their opinion, since "field" is not part of relational database vernacular. They are neither right nor wrong, however, throughout the database world, field is more often used to mean column.

With that said, projects and teams often have to work out an understanding of how they want to use particular terminology within the project to avoid confusion.

You aren't wrong, but you also might decide to simply go along with the convention being used, or avoid using the word field altogether in favor of "column". With relational databases, "Table" and "Column" are the building blocks that exist in DDL and it's best to just use those terms and avoid "field" which isn't used, nor clearly defined.