> Variable number of rows that have all the same type.

Why do they need to have the same type? In sqlite a field can have a different type in every record/row. (https://www.sqlite.org/datatype3.html). Is having a fixed typed fields fundamental to the concept of a table, or just a property of most SQL implementations?

How do you aggregate without field types? You'd end up writing custom code for untyped map-reduce...

How can you code know what data to expect without typed field? Your code size can grow up even 10x if you need to assume that any record can have any shape...

You could have more complex and user defined types in an ideal super-SQL, like "int or map:string->bool" etc., but you WANT types. They reduce complexity at all levels! You want them in you code, you want them in your data!

Sure, go ahead, just use MongoDB with no constraints on collections structure... You'll end up with 5x more code in you application and 5x more bugs.

SQL and the relational model help you think more, code less (and slower - but this is an advantage) and have less bugs with less effort! If you're lazy and prefer thinking deeper to "working harder", you'll always prefer properly typed SQL :P (Unless you're working with stuff that's naturally shaped as graphs or tensors.)

None of your remarks come close to answering my question (is having a type definition in the field/schema fundamental to a table, or just a way that most SQL databases decided to implement them)?

Regarding your questions, in case of sqlite3, a _value_ is typed, but a _field_ is not. sqlite3 only has a very small number of types (numbers, text and nulls) and functions (both aggregation and non-aggregation) that expect either number or text do standard SQL casts before evaluation.

In practice the type systems of all common SQL implementations are so weak that their "guarantees" are worth very little for the user/programmer anyway. (I have a hunch that they're really mostly for internal optimizations). All your code need to handle nulls anyway (and if you only use non-nullable fields, users are just going to use their own placeholders/adhoc sentinal values).

Back to the discussion: sqlite3 don't impose any type homogeneity on fields/columns, while Pandas / R dataframes do. So why should that be a characteristic of a "table", let alone one that distinguishes a "table" from a "dataframe"?

Who's to say who gets to write the formal definition? And just because the formal definition claims or doesn't claim something, why does that mean every single implementation has to behave exactly that way?

I think u both complete each other as a full argument with a pro and contra arrangement. Lovely af to read you both honestly.

Interestingly, the tables i know from random access machines are basically of type

bin -> bin,

So what were saying here that random data is stuff we cant meaningfully into a table?

I think thats a good statement.

Tables are non random data. (Crypto keys are again data, because they are bin -> bin in terms encrypt and decrypt, but the number itself isnt a table)

Oh interesting, because i wanted to say “everything is a tensor” before i write the long post

So generics and mixed types is where it hits a wall with tables? Though those mixed structured can just be broken down to collections of tables and enumerated, no? Then call the table of tables a table again?

Also why is a matrix not a table? Because its a super type ?

A matrix is not a table because all the columns need to be the same type. While you can convert a matrix to a table, the converse is not true.

(I assume this is what he meant, as it is the case in R.)