A database stores organized information so an application can retrieve the records it needs. Unlike a language model, a traditional database returns the specific information that was stored; it does not generate a probabilistic answer. That predictability makes it the durable source of questions, answers, tasks, and other application data. section 1.5.1 section 3.7.1
Start with the information the application must preserve. A HAM radio practice-test app needs a question pool containing each question, its multiple-choice options, and its correct answer. The question selector draws from that pool, while the interface presents questions and the grading component evaluates responses. section 3.6 section 3.7.1
For a small question database, use a direct import workflow:
- Download the comma-separated question data and inspect its columns before importing. section 5.3.1
- Create an SQLite database, then import the CSV as a questions table with column names, comma field separation, quote handling, UTF-8 encoding, and trimmed fields. section 5.3.1
- Write the changes, then make the ID column unique and primary-keyed so it can support indexing and links to later tables. section 5.3.1
- Browse the imported rows visually before building code that connects the application to the database. section 5.3.1
Question pool for a practice test
A questions table can map one row to one exam question: id, correct answer, question text, and answer choices a through d. From this stored pool, an application can select randomized sets of 35 questions, present the choices, and calculate a final score. Keep the stored fields aligned with the behavior the application needs. section 3.6 section 5.3.1
Choose the database design deliberately rather than accepting generated suggestions unreviewed. A design may use SQL or a NoSQL option such as MongoDB depending on data structure and volume; a TODO application plan, for example, uses a schema and task columns before connecting CRUD operations through Flask and a frontend. Verify generated code and factual claims, because an LLM predicts text rather than looking up authoritative stored answers. section 3.6 section 1.8.1 section 1.5.1
Table 5.1 Format of our questions data. It maps directly to a database table with this information.
| id |
correct |
question |
a |
b |
c |
d |
| T1A01 |
2 |
Question? |
possible answer |
possible answer |
possible answer |
possible answer |
Use the field layout to check that each CSV column has a clear destination in the questions table before import. section 5.3.1
