We did a semi-successful demo this week at the client meeting I didn't attend (slept right through the damn thing). The demo showed a user selecting a symptom from a drop-down menu, which then accessed the database (MongoDB) and returned the relevant test/question to be posed to the user. It was kind of rough, but all of the pieces were there. My database query code seems to be working well, but I need to add some new features to it for the next week. In particular, there will be a couple updates to the database schema model:
#1: Symptom objects will now contain a list of possible entry states into a diagnostic chart, rather than only one. This will allow my database query code to find the most promising node to start at (by looking at vehicle history data). The change in the schema will be simple (as databases like MongoDB have no 'schema', per se), but the change in the code will be slightly more involved. I'm going to refactor a method that finds the maximum value child node so it can be used to find the maximum value entry state node for a Symptom object. I don't anticipate that being super difficult, though.
#2: The database schema needs to support more vague queries for a Symptom object or entry state node based on input from the text search box. I'm still thinking about the best data structure for this purpose. The current idea is something like storing a big list of "hint" strings (variations on exact ones like "won't start") which can be searched against, and that will map to Symptom objects. This has less to do with my query code and more to do with what's in the database for the server code to search against.
So much for spring break.
No comments:
Post a Comment