As it stood, I figured creating a database was a fairly basic operation. Of course, there's a reason companies are looking for backend or full-stack developers that know what they are talking about. Their job descriptions talk of years of experience, Computer Science (or relevant) degrees and a love? for making Saas (software as a service) applications.
Please.
A more descriptive question would be,
"What do you keep in mind when creating a database?"
It seems to me that this sole question would weed out a lot of people and adequately separate the wheat from the chaff (to get all biblical). Honestly, it would have weeded me out of several jobs - more importantly, it would have clued me in to what I actually needed to be learning.
The point. I had a misconception about how Users and their information were being related to one another within the actual database. As MongoDB is a NoSQL database, I understood the idea that Schema's were not Models, and therefore as SO-AND-SO puts it, a Collection does not require Models to possess all the same BLAAH. Having just started learning MEAN, I don't pretend to be a guru, but it looks like NoSQL provides more fluidity and flexibility when building these 'relationships'. Again, I'm not talking about Relational Databases (e.g. SQL), I'm talking about how the data within these different 'Documents' (instances of Models which are compiled versions of Schemas) relate to one another.
My big question, while doing Thinkster's Node.js tutorial, was why would did the User Schema need a Boolean field called 'following', and yet the API would manipulate that field using a DELETE request instead of a PUT request.
If you know nothing, that may have sounded like nonesense. Don't worry. If you know something it probably sounded like nonesense, too! Read as, big ol' run-on, programmer sentences. I'll explain.
In the tutorial, a user should be able to 'following another user's post. Thus, teh User Schema was given a field 'following' with the default value false.
That seemed to make sense to me. I figured, if user A following user B's post, that would be accomplished by updating (making a PUT request) said Boolean field to True. Yeeeeeah...
As it turns out, that could make sense if there were only (2) users. The Boolean field would be keeping track of 'yes' following or 'no' not following. The thing is, in a larger database (one with more users than...2) the relationship falls apart. How do you keep track of user A and B liking user C's post at the same time?
Yeah, yeah, I'm sure there's a way. But the point is, I was not thinking clearly. I think that's rooted in my misconception of how database 'stuff' relates to one another. That's probably because I learned DB stuff using SQLite, a Relational Database, and was thinking that each 'following' field was just an Instance of...wait. That's confusing, isn't it? Exactly.
Alright, this example is a bit simple, cos there are so many possible iterations of this (apparently basic) concept, but the point is to answer why we're manipulating data in a boolean field with a POST/DELETE request. Just run with it.
You create the 'following' field in the User Schema as a Boolean because it is a 'yes' or 'no' question. The User Schema is telling the database what it needs to expect. In this case, a User can be 'following' or not.
When some user is 'following' or 'unfollowing' another user's post, you use a POST or DELETE request (respectively) to create or delete totally different objects - these different objects would probably be stored on the current user's .... Thus, and here's the clench, the API request is not manipulating the Boolean value stored on the database but is instead referencing the current user's Boolean field in respect to whichever user is being 'followed' or 'unfollowed'. The API request is doing a calculation for the current user and nothing else.
Sure, there's several ways to skin the proverbial cat, ladies. My point is, there's a fundamental misconception amongst Junior Developers as to what we're actually doing when we create a database. Not looking to point fingers but what the hell? This stuff isn't rocket science, y'all senior devs should be able to explain it more readily.
The way these tutorials are taught is similar to learning a foreign language (in the most inefficient way). You're given a slue of weird words and a pep talk, then you're expected to write a 1,500 word essay on a cocked up subject you've barely heard of. Oh, by the way, you can't make any mistakes because then nothing works.
#Y'all don't teaching so good
Published: 2017-04-20