[_a_a_a_]

@pessimizer, @SuperCuber - So educate me. Let's base it on something I've actually done, a code analyser. For this you parse the code into an AST, and to deal with lexical scopes of declarations of procedures/variables etc. you have a stack of symbol tables.

So we've got a tree (the AST), we've got a symbol table for the current scope (a hash table of <id, info> pairs), and we have a stack of symbol tables (a stack).

A tree, a hash table and a stack. Those are data structures. What more needs to be added to this definition to turn it from "data structures" into a "data model"?

Firstly this is a serious question, secondly I have a great deal of experience of defining data structures to solve problems, so I can't see what adding an abstract term is doing.

You could say that the extra something is the specification/maintenance of the correct interrelationship between those data structures (and I'd agree), and there's a word for that: it's called 'code'. I genuinely don't understand what you're getting at and I'd genuinely like to know.

[_a_a_a_]

And no answer :-( It does rather defeat the point of discussion here if people say things they won't back up. I don't know if I've changed your mind, you certainly haven't given me any reason to change mine, so why post?

[SuperCuber]

Unfortunately HN doesn't notify of replies need to go digging for then in "threads"

I'll give you an example from a ongoing side project of mine: https://github.com/SuperCuber/facto_rs/blob/master/src/model...

Hopefully the Rust syntax is not too much of a distraction here, but enough to focus on the `struct` and `enum` parts (an enum in rust can be "one of" the variants, like tagged union or sum type in other languages, or | operator in typescript). The project is a live wallpaper/screensaver that is a simulation of something like a combination of the games Factorio and Mini Metro.

I had in mind what I wanted to happen - a grid containing a rail network with trains running between different nodes.

What I call the model is the representation of the things in the code: I could store the train's position in terms of [float,float] and a facing Direction, but instead I choose to store it in terms of List<[int, int]> of grid tiles that it plans to go through, then an int for its current position in the list, and then a single float between 0 and 1 representing how far into the tile it's moving.

The two possible solutions have pros and cons, and there are other solutions as well that are equally valid I'm sure. In my mind, the process of "modeling your domain/problem space" is about deliberately thinking about these things and choosing what you think is the best.

[_a_a_a_]

I completely, fully get what you're saying and I've done this trade off between various data structures for a very long time, but my question wasn't about that, but the difference between data structures and data models. Put simply, it was a question of terminology used rather than technique applied.

[SuperCuber]

I guess in the way I use it, choosing a data structure is about the complexity/performance of operations you're going to do with a collection of objects, and choosing a data model is more about the meaning of fields, and what entities and relations between them you have in the first place, sort of like `CREATE INDEX` vs `CREATE TABLE`