I have developed a C# front end app for management of an SQL Database for the purposes of document control. The project this database is for has several consultants and a client spread in a variety of geographic locations. Security concerns mean that probably finding an internet connected database will not be a good solution. I am looking for a way to provide the ability for the client and other consultants to have access to the data, for browsing purposes more than anything, but am interested in perhaps being able to sync changes made by others back into the main database down the road.
The firm I am with is an Architecture firm and we use Revit for our modeling and production of drawings. Revit is interesting as an application because the documents are used as relational databases. So it occurred to me that perhaps I can have my application create a document that is really a relational database, and can provide an application to read and manipulate the data, and provide the data as a document, to the other players. Then they won't need access to the actual SQL Server database, but can see the data as it was when the "data document" was created.
Then I considered serialization. Basically, if I just write a serialized form of the data from my application to a document, and then provide a similar application that simply populates the model from the document rather than the database, it accomplishes the same thing. Since I am using ObservableCollections, Linq, and MVVM practices, I can even reuse much of the code between the two applications.
So what are the advantages with the portable relational databases that I would lose with the serialized data? And does anyone know how Revit manages to do this? I don't think it is an SQLLite or NoSQL solution, as I don't see any of the databases associated with that installed on the Revit machines.