To, z czym walczysz, to pionowe partycjonowanie. Jest to technika projektowania fizycznej bazy danych w celu poprawy wydajności. Podobnie jak w przypadku każdej techniki projektowania fizycznej bazy danych, jej zastosowanie zależy od konkretnych zapytań, które próbujesz zoptymalizować i czy ta technika je zoptymalizuje. Z logicznego punktu widzenia, jeśli te nowe pola zależą od klucza kandydującego dla twojego bytu, to są to fakty na jego temat. Najpierw upewnij się, że w pełni rozumiesz funkcjonalną zależność tych nowych pól od kluczy kandydatów, aby sprawdzić, czy naprawdę są to fakty dotyczące codziennych odsłon. Jeśli tak, decyzja o podzieleniu ich na inną tabelę jest optymalizacją wydajności, którą należy wykonać tylko wtedy, gdy osiągnie założone cele.
Ogólnie rzecz biorąc, partycjonowanie pionowe jest przydatne, jeśli rzadko i wyraźnie odszukujesz te nowe kolumny w stosunku do innych kolumn w oryginalnej tabeli. Umieszczając te kolumny w innej tabeli, która ma tę samą PK co twoja istniejąca tabela, możesz zapytać ją bezpośrednio, gdy chcesz te nowe kolumny i uzyskać znacznie większą przepustowość, ponieważ będziesz mieć o wiele więcej wierszy na stronie na dysku dla tej nowej tabeli ponieważ wszystkie kolumny z oryginalnej tabeli nie będą siedziały w tych rzędach. Jeśli jednak zawsze będziesz sprawdzać te kolumny wraz z kolumnami w oryginalnej tabeli, partycja pionowa nie miałaby większego sensu, ponieważ zawsze będziesz musiał je połączyć zewnętrznie, aby je uzyskać. Strony z tabel na dysku trafiają do puli buforów DBMS niezależnie, nigdy wcześniej nie łączone, i tak, że dołączenie będzie musiało nastąpić przy każdym wykonaniu zapytania, nawet jeśli dane zostaną przypięte do puli buforów. W tym scenariuszu uczynienie ich kolumnami NULLABLE w oryginalnej tabeli umożliwiłoby silnikowi pamięci DBMS efektywne przechowywanie ich, gdy NULL, i wyeliminowałoby potrzebę dołączania przy pobieraniu.
Wydaje mi się, że twój przypadek użycia jest tym drugim, a dodanie ich jako NULLABLE do oryginalnego stołu jest dobrym rozwiązaniem. Ale tak jak w przypadku wszystkich innych elementów związanych z projektowaniem baz danych, zależy to od tego, a aby podjąć właściwą decyzję, musisz znać spodziewane obciążenie pracą i od tego, jaki będzie dobry wybór. Dobrym przykładem właściwego zastosowania partycjonowania pionowego może być panel wyszukiwania osób, w którym aplikacja zawiera bardzo rzadko wypełniane informacje o osobie, którą ktoś może chcieć wyszukać, ale rzadko. Jeśli umieścisz te informacje w innej tabeli, masz kilka dobrych opcji wydajności. Możesz napisać wyszukiwanie, dzięki czemu będziesz mieć 2 zapytania - jedno, które wykorzystuje główne, zawsze wypełnione informacje tylko do wyszukiwania (takie jak nazwisko lub ssn), i zewnętrzny, który dołącza do bardzo rzadko wypełnianych informacji tylko wtedy, gdy są one wymagane do wyszukiwania. Lub możesz skorzystać z optymalizatora DBMS, jeśli jest wystarczająco inteligentny, aby rozpoznać dla danego zestawu zmiennych hosta, że zewnętrzne połączenie nie jest potrzebne i nie wykona go, a zatem musisz utworzyć tylko 1 zapytanie.
Z jakiej platformy DBMS korzystasz? Sposób, w jaki platforma obsługuje przechowywanie NULL w kolumnie, optymalizuje zapytanie, a także dostępność rzadkiej obsługi kolumn (SQL Server ma to) ma wpływ na decyzję. Ostatecznie zaleciłbym wypróbowanie obu projektów w środowisku testowym z danymi o wielkości produkcyjnej i obciążeniem oraz sprawdzenie, które z nich lepiej osiągają cele wydajnościowe.