Comment by allenu
You're right about the data model. I built my own flashcard app [1], so I've had to understand the database schema that Anki uses and a lot of it seems very inelegant, but on the other hand, I can see how it was purpose-built and probably grew over time and things were tacked on. (For instance, there's one table that has a single row, where several fields are simply JSON dictionaries.)
On the other hand, how templates work and how cloze deletions work are really nice. With the flashcard app I built, I didn't have templates, but did have a very basic cloze deletion system where you could mark text to be "hidden" on the front. It was very limited in that you'd only ever get one front/back combination. You could hide multiple bits of text, but they'd all be hidden at the same time. With Anki, you can create multiple groups of hidden text, so that you end up with multiple flashcards from the same note (i.e. you hid three separate groups of text, so you now have three different cards to test with).
I've been working on an update to my app to incorporate templates and cloze deletions like how Anki does it, so now I appreciate that aspect to it.
For my own database, at least in the new version I'm working on, I've ended up creating a schema where the individual attributes for each card are thrown into their own tables, but this is mostly because I needed to support updating individual attributes separately since I use a very simple journaling system to sync across devices. With Anki's schema, I can see why sync was complicated (at least in earlier versions) since it wasn't really built for it.