Haruhiko Nishi

The use of OFFSET and LIMIT isn't recommended, and the recommended approach is very similar to pagination explained in the book!

As per this writeup by Markus Winand, he does not recommend the use of OFFSET and LIMIT for handling pagination in a relational database, although in chapter 16.3. the book mentions this is how SQL handles pagination. The approach he suggests is similar to how the book explains one should handle pagination in Dynamodb.
https://use-the-index-luke.com/no-offset




Like Comment

Is consolidating attributes into a 'M' structured value under a single attribute a good practice?

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. 

Details:
https://docs.google.com/spreadsheets/d/1GU4urcOvH2oDaMwjVO3mPqgOWDp02pXKDUPXSIjf25M/edit?usp=sharing

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?
Like Comment