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.
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.
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.
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).
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 are not logged in. However you can subscribe from another Fediverse account, for example Lemmy or Mastodon. To do this, paste the following into the search field of your instance: !programming@programming.dev
Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!
Cross posting is strongly encouraged in the instance. If you feel your post or another person’s post makes sense in another community cross post into it.
Hope you enjoy the instance!
Rules
Rules
Follow the programming.dev instance rules
Keep content related to programming in some way
If you’re posting long videos try to add in some form of tldr for those who don’t want to watch videos
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”?
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???
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.
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.
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.
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).
Why would I, an embedded developer working on devices with at most a couple of mb of flash, need to learn SQL?
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.
The devil is obviously in the details but SQL is still so pervasive I’d never not recommend it.