Hacker News Reader

Comment by ganonm | Hacker News Reader

I'd highly recommend reading SQL Antipatterns. It's a very approachable book that illustrates how to design a database schema by taking commonly encountered scenarios and first showing you the naive approach. After explaining why this is bad, it then shows you the recommended way of doing it and why this way works better.

I think 'learning from how not to do something' is a really powerful pedagogical technique that should be more widespread.

View on HN

I tried that in a class I taught. The students were very frustrated and considered it a waste of time.

I agree it’s a FANTASTIC way to learn. I was very disheartened I didn’t effectively communicate that to the students.

Just a guess, your students probably didn't have the frame of reference or perspective to appreciate good design nor bad design.

Someone who's been in the trenches for several years, they'd probably get A LOT out of this technique as they would have many experiences to pull from.

Beginners often lack the experience to appreciate "critical thinking" based learning. At first they just want (need?) to know the steps to get something right, especially when they are still not particularly fluent in the very basics.

Once you've got some experience (which usually means getting things wrong a few times, seeing wrongness promoted to production because there isn't time to refactor, and having to fix the wrongness later once more layers or wrong are piled on top) you appreciate this sort of analysis much more as it helps you get things right first time more often, and/or helps you spot the actual problem (rather than chasing symptoms) in more complex situations.

It's like humans have to learn how to extract features before they can make efficient use of straightforward supervised learning...

> Beginners often lack the experience to appreciate "critical thinking" based learning.

I don't think that is it. _Beginners_ being the critical word.

Most learning is part of a negative feedback loop, if we only ever succeeded we wouldn't know why we succeeded, failure has such bad connotations in our society that it blinds students from deeply understanding a subject. Maybe replace it with experience?

Back to the subject of _Beginners_, we really should be teaching students from a very young age, philosophy, cognitive science, and epistemology. They should embrace experience, it shouldn't be up to the database schema instructor to teach both data modeling and learning by failure. Students should be fully versed in how to care and feed their brains by the time they arrive in the GPs class.

Generally yes, the general learning and problem solving mindset is going to help more than teaching "do this to do that" by rote.

But in any specific subject you need a certain level a basic knowledge taught that way before you can be expected to use the tools available (and potentially discover more) to problem solve.

I should have been more clear. My conjecture is that if we trained students on learning theory specifically and directly, they would understand the "suffering and pointlessness" of duplicating failed solutions. They would more openly embrace experience (failure) as necessary didactic tool.

Destigmatize not #winning and embracing experiential learning.

Also the "right" way often changes, in technology, and if you only learned the "right" way, when a better way comes out, you'll miss it because you only ever learned the "right" way and it's all you know.

In a work related context recently, I saw this approach used to attempt to describe how to achieve something. The problem for me was that I didn't understand the context well enough to understand why I'd initially even choose the wrong approach, let alone how that then related to choosing the correct approach. Making sure that the fundamentals are important here.

> SQL Antipatterns

I'd definitely second that recommendation, both for relative beginners and those of us who have been at it long enough to have learned and forgotten these things a few times over...

https://pragprog.com/book/bksqla/sql-antipatterns or your favourite [e]book seller, for those wanting a copy.

> why this is bad, it then shows you the recommended way of doing it and why this way works better

He also takes the time to mention when the anti-pattern might be OK to use.

SQL Antipatterns

Saw this thread and just acquired and read this. The book's premise is a great one, I just don't like the execution. Years of my life were dedicated to SQL CRUD and schema evolution before dabbled briefly in NoSQL (meh), random caching systems, then had my aha moment and upgraded to files on unix (awesome caching! great compatibility!) and occasional use of SQLite (easy backup and parallelism! no RDBMS master/slave complexity!).

While there are a few core issues raised, and all struck a chord, I was not a huge fan of the book overall because it was needlessly verbose. I found its authoritative tone grating. Ultimately with so many dialects and projects, SQL style is personal, organizational or project level preference. One issue I felt was undertreated was clarity of syntax. For example, I personally absolutely loathe any use of JOIN as needlessly obtuse cognitive baggage. An untreated issue was (over/mis)use of stored procedures.

How the hell do you deal with locks properly on files? Or each file is a row?

Right tool for the job. If you have a write-heavy, rapidly evolving dataset with short publishing times, critical contention considerations, and absolute referential integrity requirements, or a huge dataset where memory efficient access is an issue, SQL may be your friend. But try SQLite before a full-blown RDBMS. See also https://yourdatafitsinram.net/

In the real world, however, most systems do not have this type of requirement.

I'm sorry can you help me understand how to stop using Join? Some examples or articles on the subject? I can't wrap my head around such a concept.

Your approach sounds sensible! Do you have some blog posts, pointers which further explains the approach and factors to consider?

I've started reading, and already the second anti-pattern, "Naive trees", is something I've been dealing with at work recently. Hey, how'd he know?!? Cool book.

THANK YOU!!!! This is a fantastic reference, and helps me put some teeth behind my instincts when it comes to SQL.

Thanks for the SQL Antipatterns book recommendation. Just ordered it.

Reply on news.ycombinator.com