Zarówno Doktryna, jak i Propel korzystają z pojedynczego i konkretnego dziedziczenia tabeli do mapowania relacji między obiektami. Pierwsza z nich widzi wszystkie możliwe pola w drzewie klas odwzorowane na pojedynczą tabelę, podczas gdy druga z nich mapuje każdą klasę do konkretnej tabeli, powielając wspólne pola w hierarchii dziedziczenia.
Chociaż ułatwia to aparat ORM, sugeruje mi zły projekt bazy danych. Czy te złe wzorce projektowe wymuszają na bazie danych?
Odpowiedzi:
Nie można powiedzieć, czy konkretny projekt bazy danych jest zły, nie wiedząc, co robi aplikacja, kształt danych, oczekiwania dotyczące wydajności itp. Podczas gdy ogólnie normalizacja (do pewnego stopnia) jest postrzegana jako najlepsza praktyka, dość często zdenormalizowano obszary baz danych ze względu na wydajność, więc dobre i złe są bardzo otwarte na dyskusję bez większej ilości danych niż większość ludzi ma na początku.
Dodaj wiele podejść, które można zastosować, aby sprzeciwić się mapowaniu relacyjnemu, a sprawy staną się jeszcze bardziej złożone, ponieważ „najlepsza” struktura bazy danych będzie zależeć od konkretnego modelu obiektu, poziomu dziedziczenia i tak dalej.
Przyjmując jeden rozmiar, który pasuje do wszystkich metod, biblioteki trwałości ORM prawie zawsze wytwarzają nieoptymalną strukturę bazy danych dla każdej sytuacji i wykorzystują pewne rzeczy, które mogą być postrzegane jako zła praktyka w tej sytuacji .
Z pewnością możesz napisać normalną metodę ORM, ale zobaczysz dość znaczące konsekwencje dla wydajności, ponieważ dla każdej wstawki do głównej tabeli trzeba skanować różne tabele wyszukiwania, aby sprawdzić, czy istnieją wartości, czy otrzymali swoje klucze, a jeśli nie. nie wykonywać odpowiednich wkładek.
(Kiedy robisz to ręcznie, możesz skrócić niektóre z nich, ponieważ wiesz, że zaprezentowałeś im listę rozwijaną zawierającą tylko prawidłową wartość, więc nie musisz wykonywać tych przeglądów, możesz po prostu użyć klucza szczęśliwego, że idzie aby być prawidłowym, ORM nie mógł przyjąć tego założenia, ponieważ nie kontroluje interfejsu użytkownika.)
Należy jednak pamiętać, że nie mają one na celu optymalizacji wydajności bazy danych ani integralności danych, lecz optymalizację pod kątem szybkości programowania . Jeśli konkretna struktura danych jest dla Ciebie ważna, musisz albo ręcznie zakodować mapowanie obiektu / RDBMS, albo przynajmniej dokonać szczegółowej oceny wszystkich dostępnych bibliotek i wybrać tę, która najbardziej odpowiada Twoim potrzebom ( jeśli taki istnieje).
Zasadniczo sprowadza się to do wymagań i kompromisu między dobrze ustrukturyzowanymi danymi, wydajnością bazy danych i szybkością programowania. Podobnie jak w przypadku wielu kompromisów, nie możesz wybrać wszystkich trzech.
Zasadniczo nigdy nie modeluj swoich danych, aby zaspokoić potrzeby programisty (możesz do tego użyć Widoku lub Sp, ale nie Modelu danych).
Model danych powinien opierać się na regułach biznesowych dotyczących potrzeb aplikacji i wydajności.
Nie zgadzam się, że ORM promuje dezormalizację lub zły projekt bazy danych. W rzeczywistości najgorzej zaprojektowane bazy danych, jakie widziałem, powstały bez ORM. Ułatwiając właściwe relacje oparte na identyfikatorze wiersza zamiast tworzenia relacji opartej na wartości losowego pola, promuje raczej dobry projekt bazy danych.
Być może nie promuje normalizacji, ale z drugiej strony ORM, w którym łatwo jest stworzyć tabele / obiekty i relacje, które można by prawie tak promować. W ORM nie jest dużo więcej pracy przy tworzeniu tabeli „lokalizacji” z adresami i łączeniem pracowników z lokalizacją zamiast dodawania adresu do tabeli pracowników. Ale bez ORM oddzielenie lokalizacji oznacza, że za każdym razem, gdy chcesz uzyskać dostęp do lokalizacji, musisz dołączyć.
Więc moja odpowiedź brzmi: nie, nie sądzę . Być może w rzeczywistości jest odwrotnie, dobre ORM-y zachęcają do dobrego projektu bazy danych, przynajmniej dla tych, którzy mają niewielkie doświadczenie.