I would approach this from the opposite direction. Instead of having a graphics scene update a database, have the database update the graphics scene. The user interactions add entries to the database model, which then issues signals to cause updates to the scene as displayed on screen.

I've done something similar in my current application - everything that is displayed onscreen is implemented as a class derived from QAbstractItemModel, and there are "glue" classes that listen for model signals and invoke updates to the graphics.

If you derive a class from QGraphicsScene and add slots to connect it to the SQL model's signals (modelReset(), dataChanged(), etc.) as well as storing a pointer to the model, then you can use the model's signals to update the scene. The QGraphicsView instances attached to the scene will automatically update with changes to the scene.

Your database will also have to keep track of the parent-child relationships between graphics items, unless your design has all objects as top level members of a scene.