Dlaczego warto korzystać z bazy danych zamiast po prostu zapisywać dane na dysku?

Zamiast bazy danych po prostu serializuję swoje dane do JSON, zapisując je i ładując na dysk w razie potrzeby. Całe zarządzanie danymi odbywa się w samym programie, co jest szybsze ORAZ łatwiejsze niż korzystanie z zapytań SQL. Z tego powodu nigdy nie zrozumiałem, dlaczego bazy danych są w ogóle potrzebne.

Dlaczego warto korzystać z bazy danych zamiast po prostu zapisywać dane na dysku?

1. Możesz wyszukiwać dane w bazie danych (zadawać pytania).
2. Dane z bazy danych można wyszukiwać stosunkowo szybko.
3. Możesz powiązać dane z dwóch różnych tabel za pomocą JOIN.
4. Możesz tworzyć znaczące raporty z danych w bazie danych.
5. Twoje dane mają wbudowaną strukturę.
6. Informacje danego typu są zawsze przechowywane tylko raz.
7. Bazy danych są ACID .
8. Bazy danych są odporne na uszkodzenia.
9. Bazy danych mogą obsługiwać bardzo duże zestawy danych.
10. Bazy danych są współbieżne; wielu użytkowników może z nich korzystać jednocześnie, nie uszkadzając danych.
11. Bazy danych dobrze się skalują.

Krótko mówiąc, korzystasz z szerokiej gamy dobrze znanych, sprawdzonych technologii rozwijanych przez wiele lat przez szeroką gamę bardzo inteligentnych ludzi.

Jeśli martwisz się, że baza danych jest nadmierna, sprawdź SQLite.

Chociaż zgadzam się ze wszystkim, co powiedział Robert, nie powiedział ci, kiedy powinieneś używać bazy danych, a nie tylko zapisywać dane na dysku.

Weź to dodatkowo do tego, co Robert powiedział o skalowalności, niezawodności, odporności na uszkodzenia itp.

Kiedy używać RDBMS, oto kilka punktów do rozważenia:

• Masz dane relacyjne, tzn. Masz klienta, który kupuje twoje produkty, a produkty te mają dostawcę i producenta
• Masz dużą ilość danych i musisz być w stanie szybko znaleźć odpowiednie informacje
• Musisz zacząć martwić się o poprzednie zidentyfikowane problemy: skalowalność, niezawodność, zgodność z ACID
• Musisz użyć narzędzi do raportowania lub wywiadu, aby rozwiązać problemy biznesowe

Co do tego, kiedy użyć NoSQL

• Masz dużo danych, które muszą być przechowywane, które nie są uporządkowane
• Wymagania dotyczące skalowalności i prędkości
• Zasadniczo nie musisz definiować schematu z góry, więc jeśli zmienisz wymagania, może to być dobry punkt

Wreszcie, kiedy używać plików

• Masz nieustrukturyzowane dane w rozsądnych ilościach, które system plików może obsłużyć
• Nie obchodzi cię struktura, relacje
• Nie zależy Ci na skalowalności ani niezawodności (chociaż można to zrobić w zależności od systemu plików)
• Nie chcesz lub nie możesz poradzić sobie z narzutem, który doda baza danych
• Masz do czynienia ze strukturalnymi danymi binarnymi należącymi do systemu plików, na przykład: obrazy, pliki PDF, dokumenty itp.

Jedną rzeczą, o której nikt nie wspomniał, jest indeksowanie rekordów. Twoje podejście jest w tej chwili w porządku i zakładam, że masz bardzo mały zestaw danych i bardzo niewiele osób ma do niego dostęp.

W miarę, jak się komplikujesz, tworzysz bazę danych. Jakkolwiek chcesz to nazwać, baza danych to tylko zestaw rekordów zapisanych na dysku. Niezależnie od tego, czy tworzysz plik, czy MySQL , SQLite lub cokolwiek tworzy plik (i), oba są bazami danych.

Brakuje kompleksowej funkcjonalności wbudowanej w systemy baz danych, aby ułatwić ich obsługę.

Najważniejsze, co przychodzi na myśl, to indeksowanie. OK, więc możesz przechowywać 10 lub 20, a nawet 100 lub 1000 rekordów w szeregowanej tablicy lub ciągu JSON i wyciągnąć go z pliku i stosunkowo szybko iterować .

Teraz wyobraź sobie, że masz 10 000, 100 000, a nawet 1 000 000 rekordów. Gdy ktoś spróbuje się zalogować, będziesz musiał otworzyć plik o wielkości kilkuset megabajtów, załadować go do pamięci w swoim programie, wyciągnąć tablicę informacji o podobnej wielkości, a następnie iterować setki tysięcy rekordów tylko po to, aby znajdź jeden rekord, do którego chcesz uzyskać dostęp.

Odpowiednia baza danych pozwoli Ci ustawić indeksy dla niektórych pól w rekordach, pozwalając na zapytanie do bazy danych i otrzymanie odpowiedzi bardzo szybko, nawet przy dużych zestawach danych. Połącz to z czymś takim jak Memcached , a nawet z systemem buforowania domowego napoju (na przykład przechowuj wyniki wyszukiwania w osobnej tabeli przez 10 minut i ładuj te wyniki, na wypadek, gdyby ktoś inny szukał tego samego wkrótce), i będziesz mieć niezwykle szybkie zapytania, czego nie dostaniesz przy tak dużym zestawie danych, gdy ręcznie odczytujesz / zapisujesz pliki.

Kolejną rzeczą luźno związaną z indeksowaniem jest transfer informacji. Jak powiedziałem powyżej, gdy masz pliki setek lub tysięcy megabajtów, musisz załadować wszystkie te informacje do pamięci, iterować je ręcznie (prawdopodobnie w tym samym wątku), a następnie manipulować danymi.

Z systemem baz danych będzie działał na swoim własnym wątku (wątkach), a nawet na własnym serwerze. Wszystko, co jest przesyłane między twoim programem a serwerem bazy danych, jest zapytaniem SQL, a wszystko, co jest przesyłane z powrotem, to dane, do których chcesz uzyskać dostęp. Nie ładujesz całego zestawu danych do pamięci - wszystko, co wysyłasz i odbierasz, to niewielki ułamek całego zestawu danych.

Gdy masz proste dane, takie jak lista rzeczy, które opisujesz w komentarzach do twojego pytania, baza danych SQL nie da ci wiele. Wiele osób nadal z nich korzysta, ponieważ wiedzą, że ich dane mogą z czasem się skomplikować, a wiele bibliotek sprawia, że ​​praca z bazą danych jest banalna.

Ale nawet z prostą listą, którą ładujesz, przechowujesz w pamięci, a następnie piszesz w razie potrzeby, może mieć wiele problemów:

Nieprawidłowe zakończenie programu może spowodować utratę danych lub podczas zapisywania danych na dysk coś pójdzie nie tak i możesz ostatecznie zabić cały plik. Możesz sobie poradzić z własnymi mechanizmami, ale bazy danych radzą sobie z tym za pomocą sprawdzonych w bitwie technik.

Jeśli Twoje dane zaczną rosnąć za duże i będą się zbyt często aktualizować, serializacja wszystkich danych i oszczędzanie będzie dużym wyzwaniem dla zasobów i spowolni wszystko. Musiałbyś zacząć pracować nad podziałem rzeczy, aby nie było tak drogo. Bazy danych są zoptymalizowane pod kątem zapisywania tylko tych rzeczy, które zmieniają się na dysk w sposób odporny na uszkodzenia. Są również zaprojektowane tak, abyś mógł szybko załadować małe fragmenty danych, których potrzebujesz w danym momencie.

Ponadto nie musisz używać baz danych SQL. Możesz używać „baz danych” NoSQL, co wiele osób robi, wystarczy użyć JSON do przechowywania danych. Odbywa się to jednak w sposób odporny na uszkodzenia oraz w taki sposób, że dane mogą inteligentnie dzielić, wyszukiwać i inteligentnie dzielić na wiele komputerów.

Ponadto niektórzy ludzie mieszają różne rzeczy. Mogą używać magazynu danych NoSQL, takiego jak Redis, do przechowywania danych logowania. Następnie używaj relacyjnych baz danych do przechowywania bardziej złożonych danych, w których muszą wykonywać bardziej interesujące zapytania.

Widzę wiele odpowiedzi dotyczących problemu współbieżności i niezawodności. Bazy danych zapewniają inne korzyści oprócz współbieżności, niezawodności i wydajności. Pozwalają nie zawracać sobie głowy sposobem reprezentowania bajtów i znaków w pamięci. Innymi słowy, bazy danych pozwalają programiście skoncentrować się na „czym”, a nie na „jak”.

Jedna z odpowiedzi wymienia zapytania. „Zadawanie pytań do bazy danych SQL” dobrze skaluje się wraz ze złożonością pytania. W miarę ewolucji kodu podczas programowania proste zapytania, takie jak „pobierz wszystko”, mogą łatwo rozwinąć się w „pobierz wszystko tam, gdzie właściwość1 równa się tej wartości, a następnie posortuj według właściwości2”, nie powodując, że programista będzie musiał zoptymalizować strukturę danych dla takiego zapytania. Wydajność większości zapytań można przyspieszyć, tworząc indeks dla określonej właściwości.

Inne korzyści to relacje. W przypadku zapytań czystsze jest odsyłanie do danych z różnych zestawów danych niż zagnieżdżone pętle. Na przykład wyszukiwanie wszystkich postów na forum od użytkowników, którzy mają mniej niż 3 posty w systemie, w którym użytkownicy i posty są różnymi zestawami danych (lub tabelami DB lub obiektami JSON), można wykonać za pomocą jednego zapytania bez utraty czytelności.

Podsumowując, bazy danych SQL są lepsze niż zwykłe tablice, jeśli ilość danych może być duża (powiedzmy ponad 1000 obiektów), dostęp do danych w nietrywialnych i różnych częściach kodu dostępu do różnych podzbiorów danych.

TLDR

Wygląda na to, że podjąłeś ważną, krótkoterminową decyzję techniczną dotyczącą przechowywania danych dla swojej aplikacji - zdecydowałeś się napisać niestandardowe narzędzie do zarządzania magazynem danych.

Siedzisz na kontinuum, z opcjami poruszania się w obu kierunkach.

W dłuższej perspektywie prawdopodobnie (prawie, ale nie w 100% na pewno) wpadniesz w kłopoty i lepiej będzie skorzystać z istniejących rozwiązań do przechowywania danych. Istnieją specyficzne, bardzo częste, przewidywalne problemy z wydajnością, z którymi będziesz musiał sobie poradzić, i lepiej jest korzystać z istniejących narzędzi, niż tworzyć własne.

Wygląda na to, że napisałeś (małą) niestandardową bazę danych, wbudowaną i bezpośrednio wykorzystywaną przez twoją aplikację. Zakładam, że polegasz na systemie operacyjnym i systemie plików do zarządzania faktycznym zapisywaniem i odczytywaniem dysku oraz traktowaniem kombinacji jako magazynu danych.

Kiedy robić to, co zrobiłeś

Siedzisz w dogodnym miejscu do przechowywania danych. Magazyn danych systemu operacyjnego i systemu plików jest niezwykle wygodny, dostępny i przenośny na wiele platform. Ta kombinacja istnieje już od tak dawna, że ​​masz pewność, że będziesz obsługiwany i uruchomisz aplikację na prawie każdej standardowej konfiguracji wdrażania.

Jest to również łatwa kombinacja do pisania kodu - interfejs API jest dość prosty i podstawowy, a do jego działania potrzeba stosunkowo niewielu wierszy kodu.

Ogólnie rzecz biorąc, idealnie jest robić to, co zrobiłeś, gdy:

• Prototypowanie nowych pomysłów
• Budowanie aplikacji, których skalowanie i wydajność jest mało prawdopodobne
• Ograniczone przez nietypowe okoliczności, takie jak brak zasobów do zainstalowania bazy danych

Alternatywy

Jesteś na kontinuum opcji i możesz stąd iść w dwóch kierunkach, co uważam za „w dół” i „w górę”:

Na dół

Jest to najmniej prawdopodobna opcja do zastosowania, ale jest tutaj ze względu na kompletność:

Możesz, jeśli chcesz, zejść na dół , to znaczy całkowicie ominąć system operacyjny i system plików i naprawdę pisać i czytać bezpośrednio z dysku. Ten wybór jest zwykle istotny tylko w przypadkach, w których wymagana jest ekstremalna wydajność - pomyśl na przykład o minimalnym / małym odtwarzaczu MP3 , bez wystarczającej ilości pamięci RAM dla w pełni funkcjonalnego systemu operacyjnego lub czegoś takiego jak Wayback Machine , która wymaga niewiarygodnie wydajnej masy operacje zapisu danych (większość sklepów danych kompromisuje wolniejsze zapisy w celu szybszych odczytów, ponieważ jest to o wiele bardziej powszechny przypadek użycia dla prawie wszystkich aplikacji).

W górę

Jest tu kilka podkategorii - nie są one jednak do końca ekskluzywne. Niektóre narzędzia obejmują oba, zapewniając pewne funkcje w każdym, niektóre mogą całkowicie przełączyć się z pracy w jednym trybie do pracy w drugim, a niektóre można nakładać na siebie, zapewniając różne funkcje dla różnych części aplikacji.

Bardziej wydajne magazyny danych

Być może będziesz musiał przechowywać coraz większe ilości danych, wciąż polegając na własnej aplikacji do zarządzania złożonością manipulacji danymi. Dostępna jest cała gama sklepów z kluczowymi wartościami, z różnym zakresem obsługi powiązanych funkcji. Narzędzia NoSQL należą do tej kategorii, podobnie jak inne.

Jest to oczywista ścieżka do zwiększenia, gdy następujące elementy opisują twoją aplikację:

• Niezwykle ciężki jest odczyt
• Nie masz nic przeciwko zamianie wyższej wydajności na niższe (krótkoterminowe) gwarancje spójności (wiele oferuje „ostateczną spójność”).
• „Bezpośrednio” zarządza większością manipulacji danymi i brakiem spójności (w praktyce prawdopodobnie najpierw użyjesz narzędzia innej firmy, ale ostatecznie wprowadzisz to do swojej aplikacji lub do niestandardowej pisemnej warstwy pośredniej) .
• Chcesz masowo skalować ilość przechowywanych danych i / lub zdolność do ich przeszukiwania, przy „względnie prostych” wymaganiach dotyczących manipulacji danymi.

Jest tu trochę miejsca na poruszanie się - możesz wymusić lepszą spójność odczytu, dla wolniejszych odczytów. Różne narzędzia i opcje zapewniają api do manipulacji danymi, indeksowania i inne opcje, które mogą być mniej lub bardziej odpowiednie do łatwego pisania konkretnej aplikacji. Więc jeśli powyższe punkty prawie całkowicie opisują twoją aplikację, możesz być „wystarczająco blisko”, aby pracować z bardziej wydajnym rozwiązaniem do przechowywania danych.

Dobrze znane przykłady: CouchDB , MongoDB , Redis , rozwiązania do przechowywania w chmurze, takie jak Microsoft Azure , Google App Data Store i ECE Amazon.

Bardziej złożone silniki do manipulacji danymi

Rodzina aplikacji do przechowywania danych „SQL”, a także wiele innych, lepiej opisać jako narzędzia do manipulacji danymi niż zwykłe silniki pamięci. Zapewniają one szeroki zakres dodatkowych funkcji, poza przechowywaniem danych, a często nawet więcej niż to, co jest dostępne po stronie sklepu z kluczowymi wartościami. Będziesz chciał pójść tą ścieżką, gdy:

• Absolutnie musisz mieć spójność czytania, nawet jeśli oznacza to, że podejmiesz wydajność.
• Chcesz efektywnie wykonywać bardzo złożone operacje na danych - pomyśl o bardzo złożonych operacjach JOIN i UPDATE, kostkach danych i segmentowaniu itp.
• Nie przeszkadza ci kompromis w zakresie wydajności (wymuszone, stałe formaty przechowywania danych, takie jak tabele, których nie można łatwo i / lub skutecznie zmienić).
• Masz zasoby, aby poradzić sobie z często bardziej złożonym zestawem narzędzi i interfejsów.

Jest to bardziej „tradycyjny” sposób myślenia o bazie danych lub magazynie danych, który istnieje już od dłuższego czasu - więc jest tu wiele rzeczy do zrobienia i często jest dużo komplikacji. Jest to możliwe, choć wymaga pewnej wiedzy i wiedzy oraz pozwala budować proste rozwiązania / unikać dużej złożoności - najprawdopodobniej jednak będziesz używać narzędzi i bibliotek innych firm do zarządzania większością z nich.

Dobrze znanymi przykładami są MySQL , SQL Server , baza danych Oracle i DB2 .

Zlecić pracę na zewnątrz

Istnieje kilka nowoczesnych narzędzi i bibliotek innych firm, które współdziałają między narzędziami do przechowywania danych a aplikacją, aby pomóc Ci zarządzać złożonością.

Próbują początkowo zabrać większość lub całość pracy związanej z zarządzaniem magazynami danych i manipulowaniem nimi, a idealnie pozwalają na płynne przejście do złożoności tylko wtedy, gdy jest to wymagane. Jest to aktywny obszar przedsiębiorczości i badań, z kilkoma ostatnimi wynikami, które są natychmiast dostępne i przydatne.

Dobrze znanymi przykładami są narzędzia MVC ( Django , Yii ), Ruby on Rails i Datomic . Trudno tu być uczciwym, ponieważ istnieją dosłownie dziesiątki narzędzi i bibliotek, które działają jak opakowania wokół interfejsów API różnych magazynów danych.

PS: jeśli wolisz filmy wideo niż tekst, możesz obejrzeć niektóre filmy związane z bazą danych Richa Hickeya; robi dobrą robotę, wyjaśniając większość myślenia związanego z wyborem, projektowaniem i używaniem magazynu danych.

System plików pasuje do opisu bazy danych NoSQL, więc powiedziałbym, że zdecydowanie powinieneś rozważyć użycie tego przy podejmowaniu decyzji o tym, jak przechowywać dane, a nie po prostu odrzucić je na korzyść RDBMS, jak sugerują tutaj niektóre odpowiedzi.

Jednym problemem z systemami plików (i ogólnie NoSQL) jest obsługa relacji między danymi. Jeśli nie jest to tutaj główny bloker, powiedziałbym, że na razie pomiń RDBMS. Pamiętaj również o pozytywnych stronach korzystania z systemu plików jako magazynu:

• Zero administracji
• Niska złożoność, łatwa w konfiguracji
• Współpracuje z dowolnym systemem operacyjnym, językiem, platformą, bibliotekami itp
• Jedynym ustawieniem konfiguracji jest katalog
• Trywialny do przetestowania
• Trywialne sprawdzenie za pomocą istniejących narzędzi, kopii zapasowej, modyfikacji itp
• Dobra charakterystyka wydajności i dobrze dostrojony przez system operacyjny
• Łatwy do zrozumienia dla każdego programisty
• Bez zależności, bez dodatkowych sterowników
• Model bezpieczeństwa jest prosty do zrozumienia i stanowi podstawową część systemu operacyjnego
• Dane nie są dostępne z zewnątrz

( źródło )

Systemy plików są rodzajem bazy danych. Może nie RDBMS, o którym mówią wszyscy, ale na pewno DB w najściślejszym tego słowa znaczeniu. Dostarczasz klucze (nazwę pliku) do wyszukiwania danych (zawartości pliku), które mają abstrakcyjne miejsce do przechowywania i interfejs API, za pomocą którego komunikuje się Twój program.

Używasz bazy danych. Pozostałe posty mogą spierać się o zalety różnych typów baz danych ...

Baza danych jest potrzebna, jeśli masz wiele procesów (użytkowników / serwerów) modyfikujących dane. Następnie baza danych zapobiega wzajemnemu nadpisywaniu zmian.

Potrzebujesz również bazy danych, gdy twoje dane są większe niż pamięć. Obecnie, dzięki dostępnej pamięci, korzystanie z baz danych w wielu aplikacjach staje się przestarzałe.

Twoje podejście jest zdecydowanie lepsze niż nonsens „baz danych w pamięci”. Które są zasadniczo twoim podejściem, ale z dużą ilością dodanych kosztów ogólnych.

Zawsze należy zadać sobie pytanie, czy dana aplikacja wymaga RDBMS. Zbyt wiele aplikacji jest zbudowanych z procesem projektowania, który automatycznie zakłada na początku wszystkie wymagane narzędzia i struktury. Relacyjne bazy danych są tak powszechne i wielu programistów pracowało nad podobnymi aplikacjami jak wcześniej, że są one automatycznie dołączane przed rozpoczęciem projektu. Wiele projektów może temu zaradzić, więc nie oceniaj zbyt surowo.

Rozpocząłeś swój projekt bez niego i działa. Łatwiej było ci to uruchomić bez czekania na SQL. Nie ma w tym nic złego.

W miarę rozwoju tego projektu, a wymagania stają się bardziej skomplikowane, niektóre rzeczy będą trudne do zbudowania. Dopóki nie przeprowadzisz badań i nie przetestujesz metod alternatywnych, skąd wiesz, która metoda jest lepsza? Możesz zapytać programistów i przejrzeć płomienie i „to zależy”, aby odpowiedzieć na to pytanie. Gdy się go nauczysz, możesz rozważyć, ile wierszy kodu chcesz napisać w swoim języku, aby obsłużyć niektóre zalety bazy danych. W pewnym momencie wymyślasz koło na nowo.

Łatwe jest często względne. Istnieją pewne frameworki, które mogą zbudować stronę internetową i połączyć formularz z tabelą bazy danych bez konieczności pisania kodu przez użytkownika. Myślę, że jeśli zmagasz się z myszą, może to stanowić problem. Wszyscy wiedzą, że nie jest to skalowalne ani elastyczne, bo, Boże, zabroń, że ściśle powiązałeś wszystko z GUI. Non-programista właśnie zbudował prototyp; wiele YAGNI można znaleźć tutaj.

Jeśli wolisz nauczyć się ORM manipulowanego przez wybrany język zamiast nauki SQL, skorzystaj z niego, ale spróbuj zainstalować, utwórz tabelę i wyciągnij dane z popularnej bazy danych z SQL (wybierz * From; nie oszałamiające rzeczy). To łatwe do zrobienia. Właśnie dlatego ktoś je stworzył. To nie wydaje się tak wielką inwestycją, aby podjąć świadomą decyzję. Prawdopodobnie możesz również wykonać test wydajności.

Zapisywanie danych na dysku JEST zapisywaniem ich w bazie danych, zwłaszcza jeśli umieścisz każdy obiekt w osobnym pliku, którego nazwa jest kluczem do rekordu. Aby zminimalizować czas wyszukiwania odczytu pliku, utwórz podkatalogi na podstawie kilku pierwszych znaków klucza.

Na przykład key = ghostwriter miałby postać g / ho / stwriter.json lub g / h / o / stwriter.json lub g / ho / ghostwriter.json lub g / h / o / ghostwriter.json. Wybierz schemat nazewnictwa w oparciu o dystrybucję kluczy. Jeśli są to numery sekwencyjne, to 5/4/3 / 12345.json jest lepszy niż na odwrót.

To jest baza danych i jeśli robi wszystko, czego potrzebujesz, zrób to w ten sposób. W dzisiejszych czasach nazywa się to bazą danych NoSQL, taką jak GDBM lub db Berkeley. Tyle wyborów. Najpierw dowiedz się, czego potrzebujesz, a następnie zbuduj bibliotekę interfejsów, aby poradzić sobie ze szczegółami, być może interfejs get / set, taki jak memcached lub interfejs CRUD, a następnie będziesz mógł zamienić biblioteki, jeśli będziesz musiał zmienić format bazy danych na jeden o różnych cechach.

Należy pamiętać, że niektóre bazy danych SQL, takie jak PostgreSQL i Apache Derby DB, umożliwiają wykonywanie zapytań SQL na podstawie wielu formatów NoSQL, w tym własnych baz danych. Nie jestem pewien co do MyBatis, ale może być podobnie.

Unikaj szumu NoSQL. Przeczytaj o funkcjach, przetestuj wydajność i możliwości, a następnie wybierz na podstawie tego, jak dobrze odpowiada Twoim potrzebom aplikacji.

http://www.hdfgroup.org/HDF5/ to kolejny interesujący i szeroko stosowany format magazynu danych, którego ludzie często nie rozważają.

Gdy tylko dane są aktualizowane jednocześnie, podejście wykorzystujące bazę danych (może to być baza danych w pamięci) będzie prawdopodobnie bardziej poprawne i wydajniejsze, a jednocześnie kod pozostanie łatwy, ponieważ po prostu nie masz martwić się o jednoczesne aktualizacje, transakcje, buforowanie, asynchroniczne operacje we / wy i tak dalej.

Potrzebujesz bazy danych do przechowywania / pobierania kontroli jakości, takich jak te, które tutaj publikujemy! Prosty plik nie jest w stanie uporządkować danych związanych z różnymi tematami.