XML/JSON works best if you write the entire document at once, trying to append data may also be ok, but at some point you will probably want to insert/update partial data in the middle of the document/file, and that is when it gets hairy.
If you can live with a solution that reads the data into memory (at once or partially by querying) and then at some later point writes it all back to the file, then it works well with a single XML/JSON file. As long as you do not need to periodically update/insert/delete partial data from the file, a file should do it (although performance could be an issue).
One way that I have used many times is to define a XSD Schema, including constraints, data types etc. to your liking, then set up a pre-build step that automatically generates a serializable C# class hierarchy for you (using for example XSD.exe). Using normal XML serializing funcationality it is then very easy to load (and optionally validate the XML via your XSD document) the entire document into memory, read/manipulate it (query/update/insert/delete) and later serialize the entire object hierarchy back into XML.
See this page for info on XSD.exe.
This approach quickly gives you a pretty useful and solid foundation to build upon. It should be sufficient for a while, but you may have to re-write quite a bit of it if you are later moving on to a database-based solution, if you do not abstract away the data access internally from the beginning.
If an pure file-based solution is not sufficient, go for some kind of database-oriented solution, preferably some kind of embedded database, for example SqlLite or BerkeleyDb.
