Viele Tabellen ?

  • Moin, also direkt zum Punkt:


    Es geht um eine Seite auf der man ein Bild von Instagram liken kann und dafür einen Punkt erhält. Da man aber auch bei Instagram den Like wieder entfernen kann und den Punkt trotzdem hat und sozusagen nochmal liken kann um sich selbst Punkte zu generieren muss ich das anders Regeln. Nun die Frage, was ist schlauer?


    Variante 1:
    Eine Tabelle pro User, dort ID (AI) sowie Media ID (jedes Bild hat eine ID) eintragen bei jedem Like.
    Beim Liken die Tabelle vom User durchgehen und schauen ob er bereits geliked hat und so kann ich auch gleichzeitig prüfen ob er den Like entfernt hat (Verwarnung, 2. Verwarnung, Sperre auf der Seite).
    Wobei sich so hunderte, tausende Tabellen ansammeln? (Bei Inaktivität nach 3 Monaten automatisch löschen geht ja, aber in der Zeit kommen ja neue Accounts..)


    Variante 2:
    Eine Tabelle mit User ID sowie Likes als Spalten. Bei Likes die Media ID's eintragen im Format: 123,234,345 .. immer mit Komma getrennt. Und beim Abfragen exploden und die ID's durchlaufen.
    Vorteil: EIne Tabelle, Nachteil: Langsamer?


    Variante 3:
    Gibt es eine andere Variante?


    Danke im Voraus!


    Advertising has us chasing cars and clothes, working jobs we hate so we can buy shit we don’t need.
    – Tyler Durden


    Sobald Werbung im Spiel ist, bist du, die Nutzerin, der Nutzer, das Produkt.


    Einmal editiert, zuletzt von Pablo Borsellino ()

  • variante 1 kommt näher an die norm ....


    die 2.te variante ist totaler schwachsin weil du wenn du die ids auswerten wilst die nicht einzeln bekommst

  • ich würde es mit variante drei lössen,
    eine Tabelle (likes) wo du als einträge userid und mediaid hast, so kann man immer sehen welcher user was geliked hat und beim unliken die entsprechende spalte löschen

  • du kannst doch auch beim unlieken wieder einen punkt abziehen...


    Es handelt sich dabei um eine Seite die über eine API mit Instagram verbunden ist. Das etwas unliked wurde kann man nicht sehen ohne weiteres, die API ermöglicht nur Dinge zu liken, kommentieren und Daten abzufragen etc. :)


    @DanRho: Ich habe gesagt, den Datensatz exploden dann habe ich sie einzeln.


    [DT]Sniper: Dann wären aber ALLE Likes von ALLEN Usern in EINER Tabelle, die wäre ja endlos lang. Lädt doch viel zu lange wenn die riesig ist beim Abfragen jedes mal, oder irre ich mich da?


    @JJJan: Was ich nun verwende ist erst einmal egal, es geht mir nur um das Prinzip.


    Advertising has us chasing cars and clothes, working jobs we hate so we can buy shit we don’t need.
    – Tyler Durden


    Sobald Werbung im Spiel ist, bist du, die Nutzerin, der Nutzer, das Produkt.


  • warum einfach wenns auch schwer geht :D ..... exploden ist nicht grade die feine englische art

  • Naja, war ja nur ein Vorschlag damit ich nicht nur eine Variante habe :P


    Advertising has us chasing cars and clothes, working jobs we hate so we can buy shit we don’t need.
    – Tyler Durden


    Sobald Werbung im Spiel ist, bist du, die Nutzerin, der Nutzer, das Produkt.


  • do.de - Domain-Offensive - Domains für alle und zu super Preisen
  • Was ich nun verwende ist erst einmal egal, es geht mir nur um das Prinzip.

    Eben und genau in dem Moment musst du dich entscheiden, weil eine falsche Entscheidung zu späterem Zeitpunkt fatale Folgen haben könnte. Genau aus diesem Grund würde ich auf NoSQL zurückgreifen. Einfach einen Key, sprich eine UserID/Name speichern und als Wert die dazugehörige ID des Likes/Bildes. Mit Cassandra ist es dann quasi egal, ob du eine Tabelle mit mehreren Milliarden Einträgen hast.

  • Ja, ich bin noch bei der Planung und was ich wofür verwende kommt zum Schluss.
    Das nur uid (User ID) sowie mid (Media ID) gespeichert werden habe ich bereits festgelegt.


    Advertising has us chasing cars and clothes, working jobs we hate so we can buy shit we don’t need.
    – Tyler Durden


    Sobald Werbung im Spiel ist, bist du, die Nutzerin, der Nutzer, das Produkt.


  • [DT]Sniper: Dann wären aber ALLE Likes von ALLEN Usern in EINER Tabelle, die wäre ja endlos lang. Lädt doch viel zu lange wenn die riesig ist beim Abfragen jedes mal, oder irre ich mich da?


    Bis eine tabelle so groß ist, dass die langsam wird dauert es wirklich lange, die meisten warenwirtschaftssysteme kommen mit tabellen klar die Millionen einträge haben.