Osadzanie struktury danych w polu może działać w prostych przypadkach, ale uniemożliwia korzystanie z relacyjnych baz danych. Relacyjne bazy danych służą do wyszukiwania, aktualizowania, usuwania i ochrony danych. Z osadzonym polem zawierającym własne dane wad-o (tablica, JSON, xml itp.), kończysz pisanie całego kodu, aby zrobić to samodzielnie.
Są przypadki, w których osadzone pole może być bardziej odpowiednie, ale dla tego pytania jako przykładu użyję przypadku, który podkreśla zalety powiązanego podejścia do tabeli.
Wyobraź sobie przykład użytkownika i posta na blogu.
W przypadku wbudowanego rozwiązania postowego, miałbyś tabelę podobną do tej (psuedokod - prawdopodobnie nie jest to prawidłowy ddl):
create table Users {
id int auto_increment,
name varchar(200)
post text[][],
}
Z powiązanymi tabelami zrobiłbyś coś takiego jak
create table Users {
id int auto_increment,
name varchar(200)
}
create table Posts {
id auto_increment,
user_id int,
content text
}
Narzędzia do mapowania relacyjnego obiektów (ORM) :Z osadzonym postem będziesz pisać kod ręcznie, aby dodawać posty do użytkownika, przeglądać istniejące posty, zatwierdzać je, usuwać itp. Dzięki oddzielnemu projektowi tabeli możesz wykorzystać ActiveRecord (lub jakikolwiek inny system obiektowo-relacyjny są używane) narzędzia do tego, które powinny znacznie uprościć kod.
Elastyczność :Wyobraź sobie, że chcesz dodać pole daty do posta. Możesz to zrobić za pomocą osadzonego pola, ale będziesz musiał napisać kod, który przeanalizuje twoją tablicę, waliduje pola, aktualizuje istniejące osadzone posty itp. Z osobną tabelą jest to znacznie prostsze. Ponadto powiedzmy, że chcesz dodać do swojego systemu redaktora, który zatwierdza wszystkie posty. Z relacyjnym przykładem jest to łatwe. Jako przykład, aby znaleźć wszystkie posty edytowane przez „Boba” za pomocą ActiveRecord, wystarczy:
Editor.where(name: 'Bob').posts
W przypadku strony wbudowanej musiałbyś napisać kod, aby przejść przez każdego użytkownika w bazie danych, przeanalizować każdy z jego postów i poszukać „Bob” w polu edytora.
Wydajność :Wyobraź sobie, że masz 10 000 użytkowników, z których każdy ma średnio 100 postów. Teraz chcesz znaleźć wszystkie posty wykonane w określonym dniu. Dzięki osadzonemu polu musisz przejść przez każdy rekord, przeanalizować całą tablicę wszystkich postów, wyodrębnić daty i sprawdzić z tym, który chcesz. Spowoduje to przeżucie zarówno procesora, jak i dysku i/0. W przypadku bazy danych możesz łatwo zindeksować pole daty i pobrać dokładnie te rekordy, których potrzebujesz, bez analizowania każdego postu od każdego użytkownika.
Standardy :Korzystanie ze struktury danych specyficznej dla dostawcy oznacza, że przeniesienie aplikacji do innej bazy danych może być uciążliwe. Postgres wydaje się mieć bogaty zestaw typów danych, ale nie są one takie same jak MySQL, Oracle, SQL Server itp. Jeśli pozostaniesz przy standardowych typach danych, wymiana zaplecza będzie znacznie łatwiejsza.
To są główne problemy, które widzę z góry. Popełniłem ten błąd i zapłaciłem za niego cenę, więc o ile nie ma bardzo przekonującego powodu, aby zrobić inaczej, skorzystałbym z oddzielnej tabeli.
