While databases like MongoDB don't require a formal schema, there's still a schema somewhere. It might be merely implied by validation rules in the code. Or, there might be a more formal representation. In some cases, the lack of strict schema creates a dynamic flexibility that creates value rapidly. Other times, the lack of formal structures leads to chaos. How can we find a balance?
What a schema is and why we need it? How does the SQL database three-schema concept apply to MongoDB? Consequences of database schema not matching the application programming schema. Especially in a more flexible NoSQL context.
Ways to represent a schema: Code v. Metadata. There are really five cases here. On one hand there's pure code, including completely ad-hoc in the code, via Python class definition. One the other hand there are more formal metadata: packaged with the code, in separate files, or in the database.
Common Use Cases for apps that use a schema definition. We'll look at Python code for a persistent object that serializes itself to MongoDB. This relies on a formal schema definition using the JSON-Schema structure. This includes a simple Python Metaclass to add features to Python's base class definition
Schema version management and Schema migration. Some techniques that can help with schema and data migration.