What's the use case for it? If you don't know the meta field name (because it's been removed or changed daily), how will you be able to access it from the frontend code? If it's just for storing, or your purpose is to display all added meta fields somewhere, without knowing which exists), I'd say serialize it to JSON in one meta field. But perhaps I'm not understanding the use case :)

The meta fields will have additional properties (stored in a different place) like "Web Enabled" and "Sort Order". Based on these properties we will display the value of those meta-fields on the PDP in a specifications section.

Our initial recommendation was to go with the JSON field too, but the client wants to leverage the Meta Data for valid reasons: on their current website (not Episerver) they have feeds and reports that they want to continue using. Those are running against the DB and they want to only change the scripts that query the product data. It is much easier to query rows than JSON.

Another reason is that they want to migrate to In River PIM in the future and in case the InRiver connector uses the Meta Classes / Meta Fields in its sync process, they don’t want to re migrate from JSON to Meta fields.

Anyway, are you aware of any issues changing the product meta-data daily or is there anything that we need to consider? We did it in the past and did not see any obvious issues, but the meta-data didn't quite changed daily. For this project we expect it to change often.

Thanks

But my point there still stands, if you want to integrate Inriver PIM, you have to define what meta fields you have, so you know what to map to? 

But my skepticism aside, I am not aware of any issues modifying meta classes daily. The only thing I can think of is that meta field names are unique across all meta classes, so either be sure they have the exact same data type (even same nullable or non nullable), or prefix them with the class you're supposed to use them on :)

I haven't used InRiver yet, but my guess is that they allow similar dynamic meta-data create/update. In my head, the import process we build right now into Episerver will be moved to InRiver and then InRiver will be responsible for pushing the products into Episerver, along with the meta-data (I expect parts of this process to be custom).

Yes, you are correct. It shouldn't be the case to have 2 or more attributes with same name but different data type. All attributes will actually have the same type.

Thank you very much for your answer!

Having too many fields and metaclasses is gonna hurt the performance when your site starts, and likely hurt when you access the catalog contents. However it should be no problem if you just keep adding and removing metafields so the number does not change much, for example.