In addition, or maybe this is also what typing and structure means, organizing data to eliminate duplicated or derived info and determining the keys or indexes needed to access it and the rules governing access and update: that’s half your app specification right there and how well you do it makes a big difference to the speed and flexibility of implementing the other half.
It teaches you to think about data in a different way. Even if you never will use it in your products, the mental facilities you have to build for it will definitely benefit you.
I see what you are getting at (and I actually do know the basics of SQL), but for embedded developers, i think it’s much more important to know about the storage medium. Is it EEPROM or flash? What are pages and blocks? Do you need wear leveling? Can you erase bytes or only entire pages at a time? What is the write time og a page, a block and a byte? There are so many limitations in the way we have to store data, that I think it can be harmful to think of data as relational in the sense SQL teaches you, as it can wreck your performance and the lifetime of the storage medium.
You could be onto something. On of my first language was “dBase” (early 90s) which, through it’s style, enabled you to build complex user interfaces with data storage very quickly. I only built small things with it at the time, but it influenced my desire for some better solutions than we have to today.
Learning SQL on an enterprise database is what started my journey into coding. It really forces you to think about what you’re doing because of how structured the language is. It’s also very immediate in that you do x and you get y.
It also makes you think more about data models which I’d argue is why we ended up with the garbage that is MongoDB. Developers not thinking about their data and how it relates enough.
For anyone with their rankles up. 99.9999999% of the time you want an RMDBS. That remaining 0.00000001% you want NoSQL. So any project you spin up? Guess what? You want an RMDBS.
Completely agree. I really love SQL, but I hate it’s syntactic limitations. SQLAlchemy was my band-aid with an after-burner to make it bearable (and maintainable).
dBASE was not my first language, but learning normalization and modelling completely transformed my user interface design. Starting with dBASE, every UI I built used all available data to do some combination of reducing the potential for error and reducing user effort.
For example, choosing “Tesla” as the make of car should obviously hide “F-150” from the list of models and hide all fuel types except “Battery Only”. This seems obvious to pretty much everyone, but there are a lot of UI designs that completely ignore analogous data relations. Less obviously, but just as important, having reduced the list of fuel types to one possibility, it should be automatically filled in.
I find web forms, especially government ones, to be particularly bad at this stuff.
SQL is the core language that everyone should be required to learn first and foremost.
SQL does an entirely different thing than other languages though, in what sense do you mean “core”?
In addition, or maybe this is also what typing and structure means, organizing data to eliminate duplicated or derived info and determining the keys or indexes needed to access it and the rules governing access and update: that’s half your app specification right there and how well you do it makes a big difference to the speed and flexibility of implementing the other half.
It’s strongly typed and structured and for people new to programming it helps enable the change in mindset.
Interesting theory
It’s strongly typed, which is why if you want to store a list or object in a column, you have to encode it as JSON???
Why would I, an embedded developer working on devices with at most a couple of mb of flash, need to learn SQL?
The devil is obviously in the details but SQL is still so pervasive I’d never not recommend it.
It teaches you to think about data in a different way. Even if you never will use it in your products, the mental facilities you have to build for it will definitely benefit you.
I see what you are getting at (and I actually do know the basics of SQL), but for embedded developers, i think it’s much more important to know about the storage medium. Is it EEPROM or flash? What are pages and blocks? Do you need wear leveling? Can you erase bytes or only entire pages at a time? What is the write time og a page, a block and a byte? There are so many limitations in the way we have to store data, that I think it can be harmful to think of data as relational in the sense SQL teaches you, as it can wreck your performance and the lifetime of the storage medium.
You could be onto something. On of my first language was “dBase” (early 90s) which, through it’s style, enabled you to build complex user interfaces with data storage very quickly. I only built small things with it at the time, but it influenced my desire for some better solutions than we have to today.
Learning SQL on an enterprise database is what started my journey into coding. It really forces you to think about what you’re doing because of how structured the language is. It’s also very immediate in that you do x and you get y.
It also makes you think more about data models which I’d argue is why we ended up with the garbage that is MongoDB. Developers not thinking about their data and how it relates enough.
For anyone with their rankles up. 99.9999999% of the time you want an RMDBS. That remaining 0.00000001% you want NoSQL. So any project you spin up? Guess what? You want an RMDBS.
Completely agree. I really love SQL, but I hate it’s syntactic limitations. SQLAlchemy was my band-aid with an after-burner to make it bearable (and maintainable).
dBASE was not my first language, but learning normalization and modelling completely transformed my user interface design. Starting with dBASE, every UI I built used all available data to do some combination of reducing the potential for error and reducing user effort.
For example, choosing “Tesla” as the make of car should obviously hide “F-150” from the list of models and hide all fuel types except “Battery Only”. This seems obvious to pretty much everyone, but there are a lot of UI designs that completely ignore analogous data relations. Less obviously, but just as important, having reduced the list of fuel types to one possibility, it should be automatically filled in.
I find web forms, especially government ones, to be particularly bad at this stuff.