I understand that your API works with a database that is outside the scope of your project but that has to comply with your API requirements.
It's not clear to me if:
- you "own" the schema and just leave the responsibility of database management (including choice of DBMS) to the users of your API.
- your API is supposed to work on a third party schema and just has some requirements on this third party schema.
In addition, you're using Drapper. So you access the database via an IDbConnection but you may not be sure about the client used (e.g. Sql Client, ODBC, OleDB ...).
Case 1: You own the schema
If you have an SQL schema (you speak of "tables" and "columns"), the best approach would be to distribute an SQL script. Eventually you could provide several scripts to support major DBMS and their native clients;
As you're running an open source project, I'd not be surprised if some of your users would provide you with scripts adapted to other DBMS that you have not thought of.
Case 2: you don't own the schema
I understand then that your API is supposed to be used by third party developers, that will use it to add functionality to their own database.
There are two options:
- document your assumptions and requirements (i.e. the manual steps that you had to do) and let your users adapt their schema. After all it's their responsibility, if they want to use your API.
- provide some API functions or an admin tool to adapt the schema automatically, analyzing the objects in the database and sending commands to update it.
The second would be much nicer. But as you only have and IDbConnection
, you could be somewhat constraint about the access you have to the database. I'd therefore suggest to start with the documentation approach, and provide as experimental faclility the admin tool using an SqlClient. Again, with the princpile of open source, you could expect some feedback and adaptations of this tool for other DBMS.