Haruhiko Nishi

I am still learning Single Table Design, (Yes, I bought the book and video! and they are fantastic! 🤩  ) and I have been trying to apply design patterns I learned in my Facebook Ads project, an app that uses Facebook's Marketing API and all of its items are in a single table. 


For attributes that are only applicable to certain items, such as AccessToken for  User and System User in the table above, is it not encouraged to have them consolidated into the Settings attribute if this attribute applies to all other items(or most of them) in the table to minimize the number of attributes defined for this Table? For Settings, I use an M structured data that is meaningful to the context of the item represented by the row to which it belongs. They do not necessarily have the same key/value pair for different items.
Or since each item can have its own distinct attributes, trying to make these attributes look column-wise arranged in the right place (since it is not an RDBMS) and look more normalized as a table definition is discouraged?
Thank you for your insightful comments and opinions. I haven't watched the playback of Rick Houlihan's you are referring to, so I will. 😄
For an attribute like AccessToken, which is indispensably significant for functions that app won't work without, I agree that it deserves its spot as a distinct attribute by itself; therefore, it shouldn't be a part of the Settings. 
It would be nice to know when to use a Map vs. when not to use a Map.
By the way, I just noticed the AccessToken together with its adjacent attribute ExpiresIn can be represented as a Map, because these two attributes are almost always fetched together as the validation process of the AccessToken precedes the app restoring it in memory for use.
Maybe I should rename this attribute to AccessGrant and make AccessToken and ExpiresIn as key/value pair entries of a Map. 
As per the video playback, I guess there is nothing wrong with having an attribute as a Map.