Jag håller med @marc_s och @KM om att denna storslagna design är dömd från början.
Miljontals av Microsofts utvecklartimmar har gått åt till att bygga och finjustera en robust och kraftfull databasmotor, men du kommer att återuppfinna det hela genom att stoppa in allt i ett litet antal generiska tabeller och implementera om allt som SQL Server redan är konstruerad för att göra åt dig.
SQL Server har redan tabeller som innehåller namn på entiteter, namn på kolumner och så vidare. Det faktum att du normalt inte interagerar direkt med dessa systemtabeller är bra:det kallas abstraktion. Och det är osannolikt att du kommer att göra ett bättre jobb med att implementera den abstraktionen än vad SQL Server gör.
I slutet av dagen, med ditt tillvägagångssätt (a) kommer även de enklaste frågorna att vara monstruösa; och (b) du kommer aldrig att komma i närheten av optimal prestanda, eftersom du avstår från all frågeoptimering som du annars skulle få gratis.
Utan att veta något mer om din ansökan eller dina krav är det svårt att ge några specifika råd. Men jag skulle föreslå att en gammal bra normalisering skulle räcka långt. Varje välimplementerad, icke-trivial databas har många tabeller; tio bord plus tio xtab-bord borde inte skrämma bort dig.
Och var inte rädd för generering av SQL-kod som ett sätt att implementera gemensamma gränssnitt över olika tabeller. Lite kan räcka långt.