Laden...

Filtern von Daten bei dem ein Ergebnis nicht noch einmal beim Filtern angezeigt werden darf

Erstellt von Olii vor 5 Jahren Letzter Beitrag vor 5 Jahren 1.069 Views
O
Olii Themenstarter:in
76 Beiträge seit 2017
vor 5 Jahren
Filtern von Daten bei dem ein Ergebnis nicht noch einmal beim Filtern angezeigt werden darf

Hallo liebe User,

ich wollte mal ein Thema ansprechen worüber ich mir schon lange den Kopf zerbreche. Es geht um das Filter von Daten, aber nicht einfach nur ein Filtern wie select * from User where User = "Mark".

Ich versuche es mal an einem Beispiel zu verdeutlichen was genau ich meine:

Nehmen wir an es gibt einen Webshop. Dieser Webshop ist aber etwas anders aufgebaut als ein normaler Webshop.
Ein User kann einen ODER mehrere Filter wählen um sich seine Wunschprodukte anzeigen zu lassen.
ABER sobald er ein Produkt angeklickt bzw. sich ein Produkt angesehen hat, soll dieses Produkt diesem User nie wieder angezeigt werden, auch nicht, wenn er die selben Filter Kriterien einstellt wie zuvor.

(In einem echten Shop würde das natürlich keinen Sinn machen aber ich glaube das Beispiel zeigt ganz gut was gemeint ist)

Ich dachte zuerst ich könnte einfach die Produkte in einer Tabelle speichern die der User bereits gesehen hat und dann quasi mit einem umgekehrten INNER JOIN zwischen der "User" und der "UserHatDiesesProduktGesehen" Tabelle einfach immer die Produkte nehmen die nicht in der Tabelle "UserHatDiesesProduktGesehen" stehen.

Aber nehmen wir an es sind über 10.000 User registriert und jeder dieser User schaut sich täglich 30 Produkte an. Die Tabelle "UserHatDiesesProduktGesehen" würde sich ungemein schnell vergrößern und irgendwann nach kurzer Zeit würde das Auflisten der Produkte so lange dauern da, jedes mal diese Query ausgeführt werden muss.

Kennt jemand Herangehensweisen oder etwas der gleichen wie man so etwas umsetzen kann?

T
2.219 Beiträge seit 2008
vor 5 Jahren

Hast du den schon einen passenden Index gesetzt, der auch beim Join verwendet wird?
Falls nicht, muss ggf. die gesamte Tabelle gelesen werden, was den Join dann unheimlich langsam macht!

Ebenfalls bieten Datenbanken durch Partitionierung dann auch zusätzlich die Möglichkeit die Daten so aufzuteilen, dass diese gezielt für solche Vorhaben gespeichert werden können.
Somit kannst du z.B. eine Partition pro User ID festlegen.
Dies hat dann den Vorteil, dass eben alle gesehenen Produkte für diesen Benutzer auf Datenbankebene auch in dieser Partition vorliegen.
Dies spart der Datenbank viele Suche und Tabellen zugriffe, da eben nur die jeweilige Partition in einem Rutsch gelesen werden muss.

Nachtrag:
Was die Datenmenge noch angeht.
Jede gängige SQL Datenbank ist im Stande Joins über Tabelle zu machen, die teils über mehrere Mio. Datensätze beinhalten.
Dein Fall mit 10.000 Usern und 30 Produkten würde pro Monat "nur" 9.000.000 Einträge in deiner Tabelle erzeugen.
Diese müsstest du auch zukünftig um Einträge bereinigen, wenn z.B. Produkte gelöscht werden.
Sonst hast du nach Jahren unnötig viele Daten in der Tabelle stehen.

Deine Tabelle dürfte im einfachsten Fall auch nur eine Tabelle mit zwei Spalten sein.
Der UserId und der ProduktId.
Diese würden dann auch den PK bilden, was je anch Datentypen auch eine recht kleine Tabelle erzeugen dürfte.
Für die DB also eine ganz simple Relationstabelle die ohne große Probleme gelesen werden kann, da der PK selbst ein Index ist.

T-Virus

Developer, Developer, Developer, Developer....

99 little bugs in the code, 99 little bugs. Take one down, patch it around, 117 little bugs in the code.

16.807 Beiträge seit 2008
vor 5 Jahren

99% der Shops verwenden für Produkte keine SQL sondern NoSQL Datenbanken.
Mit diesen lassen sich solche Szenarien viel performanter umsetzen.