[12thwonder]

but do you want, for example, a file system where you have to define what kind of files you can store?

This folder can only contain JPEG and PNG files, this folder can contain only A or B ....etc.

useful in some cases but I don't think this is not what you want as a default.

[tored]

Interesting concept, but a guess that a file system is at a lower abstraction level than a database.

Only argument that I can sort of understand for flexible types is that it is easier to get started or for smaller projects, like some batch script, but as soon as you have a large system you want strict control of what data you write to the database. Otherwise your schema migrations will be a nightmare.

[12thwonder]

I think what you are saying makes sense for a lot of projects. but point I was trying to make is that there are projects that have to deal with highly dynamic and complex data structures. I used file system as an example but any trees/graphs are pretty hard to express as a simple type.

[tored]

I guess another scenario could be if you need to import massive amount of schemaless data, like csv imports, then types can be a problem if the sender does not have clear definition of what type the data has, common problem when dealing with non-engineers that hands you something from excel.

Thus too much of strict types can be a problem, if I compare PHP to Java, Java has a tendency to become type bureaucracy, where I find PHP to be a sane middle ground where you specify types on your functions , i.e. your api, but not within.

But writing data is not equivalent of passing data around in your application, as soon you have stored something it is hard to go back and change it because you have usually lost all context from when you wrote it, where as changing type in program code can almost always be done.

As a frequent user of sqlite I'm looking forward to try out STRICT tables, it will be interesting if that actually improves anything from an application perspective or if it becomes more cumbersome.