4 ms·

I'm of the firm opinion that you can have a very successful career purely as an SQL genie.

by reedf1 5y ago

pantulis 5y ago
SQL wizards are a rare bunch. It's not like the golden era of DBAs is going to come back, but as an upside SQL is the lingua franca of data engineering. So, yes. Disclosure: I write SQL queries just like Tarzan spoke English.
Cthulhu_ 5y ago
DBA's definitely used to have - still have? - a reputation as being paid big. They likely have a decent job in modern-day "big data" as well. Personally, unless there's a compelling reason, I'll stick to SQL for 'core' data storage. NoSQL is cute, but changing data structures over time is horror.
bob1029 5y ago
We are trying to revive the art in our shop. Just got done building a really clean 3NF model for our problem domain and we are in the process of moving 100% of our custom configuration needs to SQL queries. From a biz strategy perspective, we can scale up a lot faster if all we need to do is find people who know (or can be taught) SQL. Consider the amount of time it would take to ramp someone on 1 SQL schema vs the entire C# ecosystem. For us, the application is quickly turning into a dumb funnel that just gets data and requirements (queries) into SQLite databases for eval. We put a web interface around all this so it can be easily managed on a per-customer basis. When everything is a SQL query, you can trivially export/import/clone customer configurations to rapidly bootstrap new ones.
- JamesSwift 5y ago
  This is great if you have highly-connected client apps. Its not as doable when you can't guarantee connectivity. In those cases, you need to ship/duplicate business logic to the clients to work around the network issues. Its a hard problem.
  - bob1029 5y ago
    We do 100% of our processing server-side. All the hard stuff happens there. Spreading biz state across multiple computers would be a massive mistake for our application. Our client devices are effectively dumb terminals that just send user events to the server and display whatever view model is returned.
Akronymus 5y ago
I feel fairly confident that I can write SQL queries for basically any result set (On a well designed DB). But the project I am working on is close to breaking me (VERY bad DB design, in progress) Also: I think knowing your way around triggers and such is quite important too though. I should learn them properly some day.
- rrrrrrrrrrrryan 5y ago
  Triggers can be an absolute nightmare to debug, and basically impossible to retroactively determine why a particular trigger did or didn't fire. I've had the displeasure of working with databases with triggers that fire other triggers, and all that logic should've been moved into the application itself. They're a powerful tool to have in your toolbox, but should be used sparingly, and should be kept as simple as possible.
- arethuza 5y ago
  I remember looking at a MS Dynamics AX database, not hugely complex by ERP standards with about 5000 tables, and realising it didn't use foreign keys. That was fun.
  - Akronymus 5y ago
    I can, sadly, one up you on that: The same table stores: Addresses (primary, secondary), sex, names (up to 3), date of birth, what currency, and many MANY more values. Yes, that's one table. Also: Another table literally stores full tables in it. (Basically some kinda key with which to identify the subtable so you can select on it.) Progress has no real concept of set based queries, instead it accesses all tables like a cursor. And that's not even scratching the surface. The DB is bad and should feel bad. Just yesterday I went into a 2 hr rant about it with some people I often talk to. Foreign keys, too, are a foreign concept to progress. But hey, work is work.
    - hu3 5y ago
      > The same table stores: Addresses (primary, secondary), sex, names (up to 3), date of birth, what currency, and many MANY more values. Some denormalization is sometimes warranted. As for the rest I agree with you. Sounds like madness.
dspillett 5y ago
Not purely, I do other data related dev & admin work, and other infrastructure & security stuff[†], but I do fairly well out of being the senior[‡] around here who gets passed the nasty SQL problems (which usually turn out to be a missing index, or complex statements entirely consisting of non-sargable predicates that can be easily rearranged with a little thought, but are sometimes more interesting). [†] I used to be considered completely “full stack” but that was numerous years ago, and I enjoy my non-techie hobbies too much to have time to keep up-to-date with everything! [‡] “senior” as in citizen…

I'm of the firm opinion that you can have a very successful career purely as an SQL genie.

by reedf1 5y ago

I'm of the firm opinion that you can have a very successful career purely as an SQL genie.

SQL wizards are a rare bunch. It's not like the golden era of DBAs is going to come back, but as an upside SQL is the lingua franca of data engineering. So, yes. Disclosure: I write SQL queries just like Tarzan spoke English.

Cthulhu_ 5y ago

DBA's definitely used to have - still have? - a reputation as being paid big. They likely have a decent job in modern-day "big data" as well. Personally, unless there's a compelling reason, I'll stick to SQL for 'core' data storage. NoSQL is cute, but changing data structures over time is horror.

bob1029 5y ago

We are trying to revive the art in our shop. Just got done building a really clean 3NF model for our problem domain and we are in the process of moving 100% of our custom configuration needs to SQL queries. From a biz strategy perspective, we can scale up a lot faster if all we need to do is find people who know (or can be taught) SQL. Consider the amount of time it would take to ramp someone on 1 SQL schema vs the entire C# ecosystem. For us, the application is quickly turning into a dumb funnel that just gets data and requirements (queries) into SQLite databases for eval. We put a web interface around all this so it can be easily managed on a per-customer basis. When everything is a SQL query, you can trivially export/import/clone customer configurations to rapidly bootstrap new ones.

JamesSwift 5y ago
This is great if you have highly-connected client apps. Its not as doable when you can't guarantee connectivity. In those cases, you need to ship/duplicate business logic to the clients to work around the network issues. Its a hard problem.
- bob1029 5y ago
  We do 100% of our processing server-side. All the hard stuff happens there. Spreading biz state across multiple computers would be a massive mistake for our application. Our client devices are effectively dumb terminals that just send user events to the server and display whatever view model is returned.

Akronymus 5y ago

I feel fairly confident that I can write SQL queries for basically any result set (On a well designed DB). But the project I am working on is close to breaking me (VERY bad DB design, in progress) Also: I think knowing your way around triggers and such is quite important too though. I should learn them properly some day.

rrrrrrrrrrrryan 5y ago
Triggers can be an absolute nightmare to debug, and basically impossible to retroactively determine why a particular trigger did or didn't fire. I've had the displeasure of working with databases with triggers that fire other triggers, and all that logic should've been moved into the application itself. They're a powerful tool to have in your toolbox, but should be used sparingly, and should be kept as simple as possible.
arethuza 5y ago
I remember looking at a MS Dynamics AX database, not hugely complex by ERP standards with about 5000 tables, and realising it didn't use foreign keys. That was fun.
- Akronymus 5y ago
  I can, sadly, one up you on that: The same table stores: Addresses (primary, secondary), sex, names (up to 3), date of birth, what currency, and many MANY more values. Yes, that's one table. Also: Another table literally stores full tables in it. (Basically some kinda key with which to identify the subtable so you can select on it.) Progress has no real concept of set based queries, instead it accesses all tables like a cursor. And that's not even scratching the surface. The DB is bad and should feel bad. Just yesterday I went into a 2 hr rant about it with some people I often talk to. Foreign keys, too, are a foreign concept to progress. But hey, work is work.
  - hu3 5y ago
    > The same table stores: Addresses (primary, secondary), sex, names (up to 3), date of birth, what currency, and many MANY more values. Some denormalization is sometimes warranted. As for the rest I agree with you. Sounds like madness.

dspillett 5y ago

Not purely, I do other data related dev & admin work, and other infrastructure & security stuff[†], but I do fairly well out of being the senior[‡] around here who gets passed the nasty SQL problems (which usually turn out to be a missing index, or complex statements entirely consisting of non-sargable predicates that can be easily rearranged with a little thought, but are sometimes more interesting). [†] I used to be considered completely “full stack” but that was numerous years ago, and I enjoy my non-techie hobbies too much to have time to keep up-to-date with everything! [‡] “senior” as in citizen…