Inherited classes returning different values

This is more of a conceptual question than anything.

I have a base class called "RawReader".

It sets up the framework for classes to inherit it and read in specific data systems.

For example, I want an app read in a known format of FoxPro database, a CSV file, or a SQL database (there is about 8 more formats currently), then transfer it over a webservice and create a SQL database from it.

I have everything working with CSV, FoxPro, Access, Excel, etc... Easy enough.

The classes that inherit RawReader, like RawCSV, RawFoxPro, RawAccess all return a struct that contains a dataset as one of the members. The dataset contains the data from the raw system. The webservice receives this struct and creates sql tables and loads the data into it. This has already been coded and works great.

My issue now comes to reading in SQL. Obviously, I could follow the same path, read the remote SQL DB into a dataset, transfer the dataset as above, etc... My "issue" comes in where I feel like it doesnt make much sense to transfer a SQL db开发者_运维技巧 to a dataset, transfer it through the webservice, and then try to programmatically recreate the SQL database. I feel like I lose a lot of the granular details from the SQL database (field sizes, extended info, etc..) It seems easier in practice to just create a backup of the database, convert it to a stream object and transfer the backup over to the webservice. But this is where the problem lies...

Since all of the classes inherit from the base class, they are set up to return a DataSet. The hack-ish way would be to just add a stream object to the return struct and in my webservice add other code to make a special case for SQL sources, but I was trying to avoid that.

Any thoughts on the "proper" way to go about something like this?

I don't really see the problem, DataColumn, DataTable and DataSet have an ExtendedProperties member that allows you to attach arbitrary metadata. Your RawXxx readers can all assume that the data is eventually going to end up in a SQL database so they can all agree on naming these metadata items. On the receiving end, you would only have to deal with a missing metadata item.