I prefer to have my objects written in a literate style. My first thought was a structure more like the following. You could add other fields to each question, like a "tags" field containing a...
I prefer to have my objects written in a literate style. My first thought was a structure more like the following. You could add other fields to each question, like a "tags" field containing a list of tags. Alternatively you could store the index of the answer in the options list, or store it as a tuple index/text pair.
{
"data" : [
{
"prompt": "What kind of language is Python?",
"options": [
"Compiled",
"Interpreted",
"Parsed",
"Elaborated"
],
"answer": "Intepreted"
},
{
"prompt": "Who invented Python?",
"options": [
"Rasmus Lerdorf",
"Guido Van Rossum",
"Bill Gates",
"Linus Torvalds"
],
"answer": "Guido Van Rossum"
}
]
}
This is also my preferred approach. @pyeri if you're hell bent on minimizing disk space, you could order the options to have the correct one first returning.
This is also my preferred approach. @pyeri if you're hell bent on minimizing disk space, you could order the options to have the correct one first returning.
Premature optimization is the root of all evil. Given modern disk capacities, the storage space required for a few dozen extra characters of text per record is negligible. The more important...
This is very much readable when viewed as a JSON file also. However, what I am thinking is that once the data-bank grows in size into hundreds/thousands of QA, a lot of space will be wasted by those keys (q,a,b,etc.) isn't it? In this case, an array like this is more efficient from storage perspective:
Premature optimization is the root of all evil.
Given modern disk capacities, the storage space required for a few dozen extra characters of text per record is negligible.
The more important question is which format is easier to understand and easier to extend when requirements change? That's the one you should use.
Thanks. Regarding the extensibility, I'm still unable to decide whether or not to include a "topic" container key or not. For example, "Core Python" can contain the basic Python Q/A, "Web...
Thanks. Regarding the extensibility, I'm still unable to decide whether or not to include a "topic" container key or not. For example, "Core Python" can contain the basic Python Q/A, "Web Development" will have questions on frameworks like flask, etc. A simpler way is to use the file-system (directory and file names) as topic and include separate JSON files for storing topic meta-data. What do you suggest?
I prefer to have my objects written in a literate style. My first thought was a structure more like the following. You could add other fields to each question, like a "tags" field containing a list of tags. Alternatively you could store the index of the answer in the options list, or store it as a tuple index/text pair.
This is also my preferred approach. @pyeri if you're hell bent on minimizing disk space, you could order the options to have the correct one first returning.
Or just compress it. Any reasonable algorithm will give those repeated keys a very short representation in the output file.
Added benefit is that you have something of a checksum since you a question where the answer isn't in the list of options can be considered invalid.
Premature optimization is the root of all evil.
Given modern disk capacities, the storage space required for a few dozen extra characters of text per record is negligible.
The more important question is which format is easier to understand and easier to extend when requirements change? That's the one you should use.
Thanks. Regarding the extensibility, I'm still unable to decide whether or not to include a "topic" container key or not. For example, "Core Python" can contain the basic Python Q/A, "Web Development" will have questions on frameworks like flask, etc. A simpler way is to use the file-system (directory and file names) as topic and include separate JSON files for storing topic meta-data. What do you suggest?
instead of all keys or all arrays, you should have 2 keys: a question key, which is a string, and an awnser key, which is an array of strings.