Sinnvolles Datenbank/Tabellen-Schema für kleine Social Plattform

  • C#
  • .NET (FX) 4.5–4.8

Es gibt 4 Antworten in diesem Thema. Der letzte Beitrag () ist von MrTrebron.

    Sinnvolles Datenbank/Tabellen-Schema für kleine Social Plattform

    Hello zusammen,

    ich möchte eine kleine Social Media Plattform (absolutes max. 10-20k Nutzer, eher 5k-10k) für ein Nischenprodukt aufbauen (also fernab von Größen wie Instagram und co :D), welches ich dann mit einer C# WPF Anwendung verwalten möchte (Nutzer sind dann per Web oder App eingebunden).
    Die Frage ist für mich nun wie man sinnvoll ein Tabellen-Schema aufbaut, dass skallierbar bleibt und einigermaßen einfach für einen Feed abzufragen ist.

    Sagen wir, es gibt folgende Entitäten die abgebildet werden:
    Event
    Food     (Bilder sollen möglich sein, ist aber ein anderes Thema)
    User

    Damit sollen folgende Aktivitäten passieren können:
    Like
    Comment
    Rate
    Follow
    Share


    1. Möglichkeit

    Daraus ergeben sich erstmal folgende Aktivitäten-Tabellen:

    CommentEvent, id, comment, date, fkUser, fkEvent
    CommentFood id, comment, date, fkUser, fkFood
    LikeFood id, date, fkUser, fkFood
    LikeEvent id, date, fkUser, fkEvent
    RateFood id, rating, date, fkUser, fkFood
    RateEvent id, rating, date, fkUser, fkFood
    FollowUser id, date, fkUserFollower, fkUserFollowed
    ShareFood id, date, comment, fkFood, fkUser
    ShareEvent id, date, comment, fkEvent, fkUser

    Könnte man machen. Einen User Feed könnte man mit einer Union Abfrage nach Datum sortiert erstellen.


    2. Möglichkeit

    Allerdings könnte man das System auch etwas vereinfachen und folgende Tabellen mit einem objectType machen:

    Like     id, date, fkUser, fkObject, objectType
    Comment id, comment, date, fkUser, fkObject, objectType
    Rate id, rating date, fkUser, fkFood
    Follow id, date fkUserFollower, fkUserFollowed
    Share id, date, comment, fkObject, objectType, fkUser

    So spart man sich ein paar Tabellen. Allerdings hab ich dann keinen echten Foreignkey mehr.


    3. Möglichkeit

    Man schreibt alles in eine Tabelle:

    UserActivity id, fromUser, toUser, content, rating, type, objectType, fkObject




    Was wäre sinnvoller? Oder ganz anders?
    Vielen Dank! :)

    Dieser Beitrag wurde bereits 5 mal editiert, zuletzt von „asuryan“ ()

    Vorschlag zu Möglichkeit 2:
    Like id, date, fkUser, fkFood, fkEvent

    Und eines von beiden ist immer dbNull. Also entweder ist Food geliked oder Event, aber nie beides.

    Eine "fk-Spalte", die mal die diese, mal auf eine andere Tabelle verweist löst bei mir Panik-Attacken aus.

    Oder nüchtern gesprochen:
    Die Technologie relationaler Datenbanken ist noch nicht so weit entwickelt, dass sie das unterstützen könnte (und wird sie wohl auch nie).
    Leider, weil ich fände so eine Möglichkeit eiglich sehr reizvoll.

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von „ErfinderDesRades“ ()

    Danke für Deinen Input!

    Ich werde dann wohl mit Möglichkeit 2 in betracht ziehen mit echten FKs. Irgendwo mal gehört, das Spalten, in denen per Default Null vorkommt, eher schlecht sind aber das scheint mir auch am sinnvollsten.
    Dann könnte man auch einfach neue Foreignkeys anheften, sollten neue Entitäten hinzukommen.