Zgadzam się z @marc_s i @KM, że ten wspaniały projekt jest skazany na porażkę od samego początku.
Miliony godzin programistów firmy Microsoft poświęcono na zbudowanie i dostrojenie solidnego i wydajnego silnika bazy danych, ale zamierzasz to wszystko wymyślić na nowo, wpychając wszystko do niewielkiej liczby ogólnych tabel i ponownie wdrażając wszystko, co już jest w SQL Server. zaprojektowany, aby zrobić dla Ciebie.
SQL Server ma już tabele zawierające nazwy jednostek, nazwy kolumn i tak dalej. Fakt, że normalnie nie wchodzisz w bezpośrednią interakcję z tymi tabelami systemowymi, jest dobrą rzeczą:nazywa się to abstrakcją. I jest mało prawdopodobne, że implementacja tej abstrakcji wykona się lepiej niż SQL Server.
W ostatecznym rozrachunku przy twoim podejściu (a) nawet najprostsze zapytania będą potworne; oraz (b) nigdy nie zbliżysz się do optymalnej wydajności, ponieważ rezygnujesz z całej optymalizacji zapytań, którą w przeciwnym razie otrzymasz za darmo.
Nie wiedząc nic więcej o Twojej aplikacji lub wymaganiach, trudno jest udzielić jakiejkolwiek konkretnej porady. Ale sugerowałbym, że jakaś stara, dobra normalizacja poszłaby daleko. Każda dobrze zaimplementowana, nietrywialna baza danych zawiera wiele tabel; dziesięć stołów plus dziesięć stołów xtab nie powinno cię odstraszyć.
I nie bój się generowania kodu SQL jako sposobu implementacji wspólnych interfejsów w różnych tabelach. Odrobina może zajść daleko.
