Ik ben het eens met @marc_s en @KM dat dit grootse ontwerp vanaf het begin gedoemd is te mislukken.
Miljoenen ontwikkeluren van Microsoft zijn gestoken in het bouwen en verfijnen van een robuuste en krachtige database-engine, maar u gaat het allemaal opnieuw uitvinden door alles in een klein aantal generieke tabellen te proppen en alles opnieuw te implementeren wat SQL Server al is ontworpen om voor u te doen.
SQL Server heeft al tabellen met namen van entiteiten, namen van kolommen, enzovoort. Het feit dat u normaal gesproken niet rechtstreeks met deze systeemtabellen communiceert, is een goede zaak:het wordt abstractie genoemd. En het is onwaarschijnlijk dat u die abstractie beter kunt implementeren dan SQL Server.
Aan het eind van de dag, met uw aanpak (a) zullen zelfs de eenvoudigste vragen monsterlijk zijn; en (b) u zult nooit in de buurt komen van optimale prestaties, omdat u alle zoekoptimalisatie die u anders gratis zou krijgen, achterwege laat.
Zonder iets meer te weten over uw toepassing of uw vereisten, is het moeilijk om een specifiek advies te geven. Maar ik zou willen voorstellen dat een goede oude normalisatie een lange weg zou gaan. Elke goed geïmplementeerde, niet-triviale database heeft veel tabellen; tien tafels plus tien xtab-tafels zouden je niet moeten afschrikken.
En wees niet bang voor het genereren van SQL-code als een manier om gemeenschappelijke interfaces in verschillende tabellen te implementeren. Een beetje kan een lange weg gaan.