Tinder szerű alkalmazásnak adatbázis dizájn?

10-es: miért kell tárolni mindkét irányt? Elég a likes táblában csak a viszonzatlan likeokat tárolni. Minden like előtt lenne egy query, hogy az id-d benne van-e a likes oszlopban. Van rá index, gyors lesz. Ha benne van, akkor kitörlöd a listából, és belerakod kettejüket egy matches táblába. Úgyis külön kell őket kezelni.

Kérdező: a one-to-many és many-to-many modelleknek nézz utána.

A sebesség miatt igen elképzelhető. Mert feltehetően jóval kevesebb lesz a match mint a sima like. Azt már korábban írtuk, hogy a "like" tábla eszméletlen nagyra képes növekedni, bár indexekkel egészen jó eredményt lehet elérni a lekérdezéseknél.

Vagy úgy megcsinálni a táblát, hogy liker és liked mellett van egy matched, és akkor a matchek nem fognak két helyet elfoglalni.

Csak melyik végéhez írod be a kapcsolatnak? Főleg akkor amikor jön majd az, hogy "X" felhasználó törölni akarja magát, és minden adatát. Ez majd a törlést is bonyolítani fogja. Míg ha csak a liker és a liked van tárolva akkor a törlés egyszerűen végig fut (és pl. nem fog rekord véletlenül beragadni, bár arra lehet karbantartó rutint írni, amelyik időnként kigyomlálja a beragadt matche-ket.) Ugyanígy (és a nagy számú felhasználó miatt a tranzakció kezelést és a lockolást is nagyon meg kell gondolni) előfordulhat, hogy amikor a matche-s táblát töltöd és vennéd ki a like táblából a rekord párt van egy abnormál terminate. Nyilván az lesz a menet, hogy ha észre vesszük a matche-t akkor előbb teszzük be a matches táblába és utána vesszük ki a like táblából (vagy onnan ki se vesszük, mert mi van ha...). Megint ez olyan probléma ami néhány 100 (legyen 300) felhasználóig nem lesz gond, mert akkor a like tábla nem lesz hosszabb mint 300x300 rekord ami még 90 000 rekord teljesen szépen fog menni. Majd ha meglesz a néhány 10 000 felhasználó fog borulni a mutatvány. Itt jön az, hogy az adatbázis várható mérete is egy tervezési szempont.

#12 gondoltam erre, de nem tetszett, hogy a likes meg a matcses tábla sémája kb ugyanaz.

Ráadásul extra query-k vannak(ha létrejön egy match, törölni kell a likes-ból + ha valaki visszavonja a likeot, akkor a matchesből törölni, a likes-ba meg visszatenni).

Szerintem felesleges bonyolultság.

Lehetséges, hogy felesleges. Arra nem gondoltam, hogy a folyamatos törlések azért nem tesznek jót a performanciának, már csak az index miatt sem. Esetleg egy obsolate "flag", és utána bulk törlés.

Ha ilyennek állnék neki, akkor biztosan csinálnék valami tesztet, és megpróbálnám kimérni, hogy milyen erőforrással, mekkora táblánál lenne érezhető idő egy elemi művelet.