Case study: Variable content
Another feature of dovcument database systems is the ability to have different content in different records. Relational databases have a schema that defines what fields are in the record in what format. But you can throw any data in any order to a document system and it will simply store it for you.
That flexibility is too much for mose commercial applications. You need to know what to expect when you read a record. So my compromise is to create a fixed and variable part of the record. The variable part is made up of any number of sections, each of which is defined by its own schema. These schema sections are stored in a file that can be edited at any time. I call them 'sub-schemas'.
The implementation is rather primitive at this stage. The sub-schema/s are defined by text fields containing a JSON definition.
Given that this is still at the proof-of-concept stage the test data has been simplified. Each subject has its own sub-schema with a set of results fields. Ideally you select subject and the system will provide the results fields in real time. But that code isn't written. So the procedure is a bit messy
- Select the subjects
- Save the record and then re-edit
- Enter the results
See this here. Click 'edit' to see how results are entered. Click on 'Sales and Marketing and submit to add new fields. The schema for this is here (the magic happens on line 22). Click on 'Admin home page' to get access to the subschemas for students.
I will be the first to admit that this feature needs work. But it is potentially the start of a new direction for SUDSJS. If part of the schema can be 'soft', then why not all of it. And why not a user-friendly method of input. Something for a future project.