←back to thread

SQL Design Patterns (2010)

(vadimtropashko.wordpress.com)
149 points mci | 1 comments | | HN request time: 0.218s | source
Show context
alphazard ◴[] No.45077668[source]
I always tell people to worry about the data structures that you want the database to maintain for you, and not worry about the SQL. You can always use Google to look up the SQL, or now ChatGPT to generate it for you. SQL is a not-that-great language and it intentionally hides what's going on. It is also different enough between databases that you need to pay attention. So learning to design/think in terms of SQL is probably not worth doing.

The set of data structures that you use to model and index a dataset is worth understanding, and designing in that space is a skill worth learning.

replies(4): >>45078199 #>>45078627 #>>45078711 #>>45081027 #
yakshaving_jgt ◴[] No.45078199[source]
For posterity, how would you recommend the average working programmer should go about doing that?
replies(2): >>45078239 #>>45079355 #
alphazard ◴[] No.45079355[source]
An intro data structures course is worth watching if you haven't taken one. There are plenty of them on YouTube. Try to follow along with a language that has an explicit pointer type. Go is a good choice. Java and Python are worse choices (for this particular thing) IMO.

Assuming you are familiar with trees and hashmaps, you have all the important building blocks. You can imagine a database as a bunch of trees, hashmaps and occasionally other stuff, protected by a lock. First you acquire the lock, then you update some of the data structures, and maybe that requires you to update some of the other data structures (like indexes) for consistency. Then you release the lock.

By default, most data will live in a BTree with an integer primary key, and that integer is taken from a counter that you increment for new inserts. Indexes will be BTrees where the key is stuff you want to query on, and the value is the primary key in the main table.

Using just those data structures you should be able to plan for any query or insert pattern. It helps to figure this out yourself in a programming language for a few practice cases, so you know you can do it. Eventually it will be easy to figure out what tables and indexes you need in your head. In the real world, this stuff is jotted down in design docs, often as SQL or even just bullets.

That's really all you need, and that's where I recommend getting out of the rabbit hole. Query planners are pretty good. You can usually just write SQL and if you did the work to understand what the tables and indexes should be, the planner will figure out how to use them to make the query fast.

replies(1): >>45079772 #
1. belfthrow ◴[] No.45079772[source]
Java is a bad language for this compared to go? Is this legitimate advice on a serious programming blog. Pretty unbelievable honestly.