Question: This isn't a joke. ;)

I was working with a DBA to define a data model and he was pushing back against some of my suggestions by saying something like "well before we had 'loop based' programming" or "loop based data models"

My suggestions, because we are working with Entity Framework, a model == table schema based ORM, were to simplify some relationships.

I want to know what he meant by that?

---

Thanks for the answers so far but its definitely not a sql "set-based" vs cursor,while loop thing.

---

In response I said "I have no idea what that means" and he never provided an answer, just dropped some part of his objections.

Answer: 
I would infer that he means loop-based as distinct from set-based programming, which is a better way to code with SQL.

For example, in a loop-based mental model, you would change a bunch of rows by running a query, fetching the rows one-by-one, changing the value of a field, and post each row back to the database. This runs N+1 SQL queries to change N rows. It's often the consequence of using ORM tools like Entity Framework or Active Record.

In a set-based mental model, you'd use a single SQL `UPDATE` statement to change all the rows in one operation. You don't have to fetch any data back to the application, it all happens on the database server. And you only have to run a single SQL statement. This is more efficient, but most ORM tools fail to support this technique (except by allowing you to bypass the ORM and execute custom SQL directly).

---

Re comments from other folks: We can come up with answers for what *we* think "loop-based" means, but this will never answer what *your coworker* meant when he said it. If he backed off, then he might not know how to be more articulate about it. If so, you'll never know what he meant.

---

Re ORMs are smarter than that these days, I'd like to hear some examples. I'm not denying it -- I'm genuinely interested in an example of an ORM that can invoke an update against rows it hasn't fetched. That is, within the "ORMish" interface, not by breaking the abstraction.
"I'm genuinely interested in an example of an ORM that can invoke an update against rows it hasn't fetched."

I do have doubts whether such a possibility would actually be a good idea.

Modifying database values without the modifier *KNOWING* the actual content that he is modifying ?

That's like saying to someone, "Whatever it is you think you know (and I don't even really know what it is that you think you know), it's wrong."