Consider moving SQL module to start of course

[illicitonion]

We discussed in the syllabus team meeting today the idea of moving the SQL module to be much earlier in the course - probably between HTML/CSS and JS1.

This discussion is for exploring that idea.

The key motivations are:

1. SQL is a really good venue for exploring problem solving and breaking down problems, e.g. "I need to do this join before I can select the right set of information".
2. For our trainees who leave the course before the end, SQL, and data-thinking, is a really useful stand-alone skill; much more so than basic JavaScript.
3. General SQL doesn't have any dependencies on other things in the course (though some parts of the current module do, e.g. the "calling SQL from Node" parts).

[illicitonion]

Open question: When exactly would we want this module? We're currently thinking after HTML/CSS and before JS1 - after HTML/CSS because a lot of the time of HTML/CSS is spent faffing around with other things (cohort building, admin, getting used to new environments, etc).

[SallyMcGrath]

Just going to put what's in my head and let you see it

stateDiagram-v2
    ITD --> Fundamentals
    Fundamentals --> ITD
    Fundamentals --> Interfaces(HTML)
    Interfaces(HTML) --> Data
    Data --> ITD
    Data --> Programming(JS123)
    Programming(JS123) --> Frameworks(React)
    Programming(JS123) --> Systems
    Frameworks(React) --> Databases
    Systems --> Databases
    Databases --> Applications
    Databases --> Deployment
    Applications --> Products
    Deployment --> Products
    Products --> Portfolios

Loading

[illicitonion]

Open question: How should we introduce the "SQL in JavaScript" part? (It presumably needs doing after SQL has been introduced, and after at least some of Node has been introduced). How do we want to split the two parts, and how long will we need for the Node+SQL part?

[sztupy]

Why not move it between React and Node? There's hardly any use for SQL until the Node part comes in. I would worry if we move SQL too early they forget about it by the time it will become useful

Alternative suggestion: Interleave the DB module with the Node module. We are effectively already doing that as the DB module is interleaved with getting it working inside a node app

[SallyMcGrath]

Yes, we discussed this option as well!

I also think it would be good to think about splitting out Node into Node+DB and Node+APIs. But this doesn't address Daniel's point about SQL being useful on its own terms, which I think is a powerful argument.

[sztupy]

I guess the discussion is how much we want to streamline the modules so they lead into one another and how much we want to make sure that modules are useful on their own, as the two are sometimes opposing each other. It might be okay however to move the DB module much earlier - it is a useful skill outside of web development as well - but in that case we might want to update later modules to keep the trainees refreshed in their SQL skills. If there are 4-5 months between SQL and Node I'm fairly certain a couple of them will struggle as they would need to re-learn a module the same time they are asked to learn a new one.

On the other hand the persistence part of our Node module is pretty bad and doesn't apply to a lot of features. I'm just trying to see how a serverless module would look like in terms of Full Stack Assessment and for obvious reasons all of our non-database based persistence suggestions (global variables, file storage) are non-existent options over there, and some of the viable alternatives (use a key/value store like redis or memcached) just add complexities

[SallyMcGrath]

I wonder can we find a thread to keep SQL alive? We have the Codewars thread and the Bandit thread, keeping those tiny bits of practice going. There's not a lot of SQL on Codewars, but is there a similar game? What do people think of Select Star SQL? (I've never played it/read it.)

[KeithBremer]

Here are a few thoughts (apologies for the length):

If we move the SQL (just SQL, no node component) to before JS1 that gives us two significant advantages and one significant downside. We gain the chance to show students the rudiments of data modelling, which could be useful for designing data structures in JS as well as for DB design. The students also gain SQL skills that are valuable in themselves at an early stage in the overall course. The disadvantage is that we introduce a long gap between learning SQL and its implementation in Node meaning that some students will have forgotten those skills.

If we delay the SQL until just before the Node module then we lose some of the benefits of doing it early but don't suffer the problems of skills retention. In any case I don't think the content needs to be significantly different in whichever of these approaches we take.

To overcome the big gap between SQL and its use in Node we could recap the SQL by using some of the basic query problems as part of the Node implementation (we do this anyway at present - most of the early queries from Node are very simple. By providing, perhaps, a bit more guidance to reintroduce SQL concepts at the start of the Node module we would, I hope, alleviate some of the problems.

The Node module could be restructured to largely remove the local file based storage solution to persistence and instead use a database. This, in turn, would require databases to be pre-created to cater for all the exercises that currently use file storage. Students would probably struggle with that and, in any case, we maybe want them to concentrate on Node rather than DB design so we should provide them with scripts to build these databases. I would like, however, for the students to be faced with at least one extended exercise where they are required to design a DB, implement the tables and build a node API to access them, This would be a sound precursor to the project work which would be approaching fast at this stage,

I'm hoping that the restructuring will release some additional space for covering further important SQL features (e.g. transactions, locking, calling stored procedures, etc, etc...) that we don't have time for at present. These extra features are probably best covered as part of the Node+SQL topics since, for example, transactions require a slightly different approach than basic SQL in their Node implementation.

The earlier purely SQL module could include the data modelling component as maybe an extra week or so, to include table design and definition (something I have previously been uncomfortable about but have been persuaded by some cogent arguments). This will need some careful and considered design. Having been a significant contributor to Oracle's Database Design course offerings (I make no excuses - there are none) I am at least aware of the issues. Ours will by necessity be much simplified in comparison.

I suggest that the data modelling component follows the SQL queries. By having used queries the students are aware of the kinds of structures they are going to be creating. Reversing that sequence would probably be a mistake, a bit like asking a novice driver to design a car before they've ever driven one...

Ok, that's it for now. All comments gratefully received - shoot me down in flames...

[KeithBremer]

PS - does anyone have any preferences for data modelling tools? Do we need any data modelling tools, could we not just use paper & pencil (or whiteboard & marker, etc...)? I was thinking in terms of Visual Paradigm or something similar but haven't yet had time to try them out.

[SallyMcGrath]

I really rate sketching with paper and pencil. I just sat down with some trainees and taught them CSS grid with paper and pencil and it is so much simpler and clearer that way. Sometimes getting them off the keyboard is the best way to engage our brains.

[wai-t]

Thanks, Daniel, for referring me to this discussion. I see it's aged a bit, but I might as well leave some thoughts.

With my "Concepts-before-Commands" hat on, the two important quotes that leapt out at me here were:

• "data-thinking, is a really useful stand-alone skill" - Daniel
• "show students the rudiments of data modelling" - Keith

I think these are important, because they are standalone facts without dependencies. You can do databases without knowing any other form of programming, and most JS developers who end up working on regular sized projects won't actually do much SQL. So I'm wondering whether (although the course delivery has to be serialised) we're getting a bit too bogged down in thinking in terms of what comes after what. GCSE Computer Science students can manage nine other subjects in the course of a week, maybe we can do the same here. We already do with PD in tandem. My point is, writing something like a book requires you to serialise, but delivering knowledge doesn't. Should you learn classical thermo before relativity? Does it matter? But one of the risks I can see is that we deny the possibility that a student might discover a keen interest in DB and no interest whatsoever on clicking colourful things on a screen. Does everyone have to be fullstack? In the projects I've worked on, fullstack is a red flag, because it suggests to me they haven't worked much on large systems.

On the data modelling issue: Data models have been around for thousands of years ever since we started leaving marks on walls. I imagine that one of the outcomes of the <> and the <> module (Sally's diagram above) is that the student realises they've been doing a lot of data modelling all the time and can map their shopping lists and diaries to the IT terms and spreadsheet techniques they have been introduced to. What you don't want to do is to throw SELECT statements at them without re-engaging the concepts they already mostly understand under a more rational structure. Whether it's DB, Excel, process-memory, site-maps: "data-thinking, is a really useful stand-alone skill". AND there are plenty of database development jobs out there, not to mention data science. (At this point I'd like to tentatively rebut something Keith said a while ago. You said you'd never actually done DB normalisation in a work project. I would suggest that you have - you just didn't do it consciously! I bet the end result looked as though you had :) )

My "Concepts-before-Commands" philosophy is at odds with Keith's final paragraph, but on reflection, in practice it's a bit of both, making a bit of progress on one side then over to the other and back again. However, concepts provide a framework into which you can project your understanding and discover gaps in your knowledge to encourage further enquiry. Whether they realise it or not, when you teach them about the SELECT statement there is already a model of a table of rows and columns in mind. You might as well take the opportunity to reinforce it as a formal concept, so that the student isn't left wondering "are they thinking what I'm thinking?". It is a communication device.

I agree with Sally that pen and paper is often the best teaching method. We can teach DSA with a pack of playing cards. Did anyone ever do that radix sorting experiment with a stack of rolodex cards with holes and slots cut out of them and a knitting needle?