Hacker News Reader

Comment by reedf1 | Hacker News Reader

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

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.

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.

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.

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.

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 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.

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.

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.

> 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.

Denormalization implies having it thought out

This DB is many things, but most definitely not thiught out.

Basically nothing is normalized.

I distinguish that practice as “Abnormalization” (HaHaOnlySerious).

In some cases, we aren't in a position to normalize the database due to legacy situations.

However, one thing that could be done is to use views (maybe scoped in their own schema) to make the database look normalized (Facade the database). This would help with writing future SQL.

It is then possible to iteratively normalize the underlying tables by pointing legacy code at the normalized views until the denormalized tables are no longer in use. Finally, "convert" the views into tables and drop the denormalized tables.

That is actually basically what we are doing. Except the whole application gets replaced too.

(I have to write the sync code from the new system to the old one)

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.

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.

Reply on news.ycombinator.com