Czy to „poprawny” projekt bazy danych?

Pracuję z nową wersją aplikacji innej firmy. W tej wersji struktura bazy danych ulega zmianie, mówią „w celu zwiększenia wydajności”.

Stara wersja DB miała ogólną strukturę:

<code>TABLE ENTITY
(
    ENTITY_ID,
    STANDARD_PROPERTY_1,
    STANDARD_PROPERTY_2,
    STANDARD_PROPERTY_3,
    ...
)

TABLE ENTITY_PROPERTIES
(
    ENTITY_ID,
    PROPERTY_KEY,
    PROPERTY_VALUE
)
</code>

więc mieliśmy główną tabelę z polami dla podstawowych właściwości i osobną tabelę do zarządzania niestandardowymi właściwościami dodanymi przez użytkownika.

Nowa wersja instancji DB ma taką strukturę:

<code>TABLE ENTITY
(
    ENTITY_ID,
    STANDARD_PROPERTY_1,
    STANDARD_PROPERTY_2,
    STANDARD_PROPERTY_3,
    ...
)

TABLE ENTITY_PROPERTIES_n
(
    ENTITY_ID_n,
    CUSTOM_PROPERTY_1,
    CUSTOM_PROPERTY_2,
    CUSTOM_PROPERTY_3,
    ...
)
</code>

Teraz, gdy użytkownik doda własność niestandardową, do bieżącej dodawana jest nowa kolumnaENTITY_PROPERTY stół domaksymalna liczba kolumn (zarządzany przez aplikację), a następnie tworzona jest nowa tabela.

Więc moje pytanie brzmi: czy jest to właściwy sposób projektowania struktury DB? Czy to jedyny sposób„zwiększ wydajność”? Stara struktura wymagała wielu złączeń lub podselekcji, ale ta struktura nie wydaje mi się zbyt mądra (a nawet poprawna) ...

questionAnswers(5)

yourAnswerToTheQuestion