如何通过 EF Core 支持获取和插入操作中的动态列？

Question

We have a configuration screen where fields can be defined and config is stored in a config table. In earlier version of the product we were calling SP to check for the columns and created them dynamically in table.

While calling get API, the stored procedure responsible was returning all columns and same was displayed on the blotter.

Now we are looking ahead to migrate to EF Core and we are using EF Core to store config information.

Here comes the Questions:

• We write stored procedure and pass meta info, which is then used to create columns directly in table, as is current scenario. Is there any other option in EF Core?
• Can we somehow get all the columns(dynamically created) using EF Core without using Stored Procedure. We do not want columns to be available in intellisense as no ops is performed on those columns. They have business use case, so required in return.
• If no to above, then if we write SP, how can same be achieved in EF Core, without creating any Model for the returned object.
• How to perform insert operation on said table from EF Core.

Please note one of the main reason to migrate to EF Core is to support multiple DB Server Types(MS SQL Server, MySQL mainly). Is there a common way to manage a single version of SP(Routines) across server types.

Just to clarify: EF is Entity Framework and SP is Stored Procedure.

Answer 1

One way to support customer defined properties would be to add an extra table rather than changing the database schema. You could for example have a pair of tables like

PropertyTypeTable

Id	Name	Type
1	Age	int32

AdditionalPropertiesTable

Id	ReferenceId	TypeId	Value
1	123	1	42

That way you could add additional properties to some table at runtime without actually changing the database schema. If the customer wants to add a new column he/she would just add a new row in the propertyTypeTable, and add corresponding rows to the AdditionalPropertiesTable whenever creating a new entry in the table. Any type of UI would need to be updated to accommodate arbitrary types. A potential downside with such a solution would be that type validation need to be done in the application layer rather than the database.