Wdrażanie komentarzy i polubień w bazie danych

Skoro "nienawidzisz" baz danych, dlaczego próbujesz je wdrożyć? Zamiast tego poproś o pomoc kogoś, kto kocha i oddycha tymi rzeczami.

W Przeciwnym Razie, naucz się kochać swoją bazę danych. Dobrze zaprojektowana baza danych upraszcza programowanie, inżynierię witryny i usprawnia jej dalsze działanie. Nawet doświadczony projektant d / b nie będzie miał kompletnego i doskonałego foresight: niektóre zmiany schematu w dół drogi będą potrzebne w miarę pojawiania się wzorców użytkowania lub zmiany wymagań.

Jeśli jest to jednoosobowy projekt, program interfejsu bazy danych do prostych operacji za pomocą procedur składowanych: add_user, update_user, add_comment, add_like, upload_photo, list_comments, itp. Nie osadzaj schematu nawet w jednym wierszu kodu. W ten sposób schemat bazy danych może zostać zmieniony bez wpływu na żaden kod: tylko procedury składowane powinny wiedzieć o schemacie.

Może być konieczne kilkukrotne przeformułowanie schematu. To normalne. Nie martw się o to, aby był idealny pierwszy raz. Po prostu spraw, by był wystarczająco funkcjonalny, aby prototypować początkowy projekt. Jeśli masz luksus czasu, użyj go trochę, a następnie usunąć schemat i zrobić to ponownie. Jest Zawsze lepiej za drugim razem.

To jest ogólna idea nie zwracaj uwagi na stylizację nazw pól, ale bardziej na relację i strukturę

Ten pseudokod otrzyma wszystkie komentarze zdjęcia o ID 5
SELECT * FROM actions
WHERE actions. id_Stuff = 5
I działania.typeStuff= "photo"
I działania.typeAction = "comment"

Ten pseudokod dostanie wszystkich lubiących lub użytkowników, którzy lubili zdjęcie o ID 5
(możesz użyć count() aby po prostu uzyskać ilość polubień)

SELECT * FROM actions  
WHERE actions.id_Stuff = 5  
AND actions.typeStuff="photo"  
AND actions.typeAction = "like"  

O ile rozumiem. wymagane jest kilka tabel. Istnieje wiele relacji między nimi.

• tabela, która przechowuje dane użytkownika, takie jak imię, nazwisko, data urodzenia z polem tożsamości.
• Tabela przechowująca typy danych. te typy mogą być Zdjęcia, akcje, linki. każdy typ musi mieć unikalną tabelę. w związku z tym istnieje zależność między ich poszczególnymi tabelami a tą tabelą.
• każdy inny typ danych ma swoją tabelę. na przykład aktualizacje statusu, zdjęcia, linki.
• Ostatnia tabela jest dla relacji wielu do wielu przechowujących id, user id, typ danych i data id.

Spójrz na wzorce dostępu, których będziesz potrzebować. Czy któraś z nich wydaje się być szczególnie trudna lub nieefektywna?

Jeśli nie preferujesz tego, który wymaga mniejszej liczby tabel

W Tym Przypadku:

1. Dodaj komentarz: albo wybierasz konkretną tabelę many/many, albo wstawiasz do wspólnej tabeli o znanym identyfikatorze dla tego, co jest lubiane, myślę, że kod klienta będzie nieco prostszy w twoim drugim przypadku.
2. Znajdź komentarze do item: tutaj wydaje się, że używanie wspólnej tabeli jest nieco łatwiejsze - mamy tylko jedno zapytanie parametryzowane przez typ encji
3. Znajdź komentarze osoby na temat jednego rodzaju rzeczy: proste zapytanie w obu przypadkach
4. Znajdź wszystkie komentarze osoby na temat wszystkich rzeczy: to wydaje się trochę szorstkie tak czy inaczej.

Myślę, że Twoje "dyskryminowane" podejście, opcja 2, daje prostsze zapytania w niektórych przypadkach, a w innych nie wydaje się dużo gorsze, więc poszedłbym z tym.

Zdecydowanie skorzystaj z drugiego podejścia, w którym masz jedną tabelę i przechowujesz Typ elementu dla każdego wiersza, co da ci o wiele większą elastyczność. Zasadniczo, gdy coś można logicznie zrobić z mniejszą liczbą stołów, prawie zawsze lepiej jest przejść z mniejszą liczbą stołów. Jedną z zalet, która przychodzi mi teraz na myśl w twoim konkretnym przypadku, weź pod uwagę, że chcesz usunąć wszystkie lubiane elementy pewnego użytkownika, przy pierwszym podejściu musisz wydać jedno zapytanie dla każdego typu elementu, ale z drugie podejście można to zrobić tylko jednym zapytaniem lub rozważyć, gdy chcesz dodać nowy Typ elementu, przy pierwszym podejściu polega to na tworzeniu nowej tabeli dla każdego nowego typu, ale przy drugim podejściu nie powinno się nic robić...

Rozważ użycie tabeli dla każdego podmiotu w komentarzach itp. Więcej tabel - lepsze odłamywanie i skalowanie. Nie jest problemem kontrolowanie wielu podobnych tabel dla wszystkich frameworków, które znam.

Pewnego dnia będziesz musiał zoptymalizować odczyty z takiej struktury. Możesz łatwo tworzyć tabele agragacyjne nad bazowymi i tracić trochę na zapisach.

Jeden duży stół ze słownikiem może pewnego dnia stać się niekontrolowany.