In general, I follow an MVC or MVVM pattern for the general architecture. Whether the data lives in a flat file or in a database doesn't have much of a bearing on the design, other than choosing one, the other, or both from the get-go.
over the years, i've discovered that perhaps as many as half of the major data structures in a game tend to be some sort of implementation of some type of relational database system.
a player "record" in the player "database" for CAVEMAN has links to the following databases: models, animations, animation players, textures, and entity types. one field in the player record is an entire inventory database.
the animation player record links to the model and animation databases.
the entity type record links to the model database.
an inventory item record links to the object types database.
an object type record links to the mesh and texture, or model and animation databases.
a model record links to the mesh, texture, and material databases.
Storing binary information (like audio or images) can get a little hinky unless its a fixed size shared in common with other files of its type
this is where i combine C and C++ syntax. i'll usually use a static C array of COM object pointers, big enough to get the job done. i use DirectX, and it stores audio, meshes, and textures as COM objects.