Matchquality-Matrix-DB

Einklappen
X
 
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

  • Matchquality-Matrix-DB

    Hallo Miteinander

    Wir suchen eine Lösung für folgende Problemstellung. Falls Du also sowas bereits realisiert hast oder weisst, wie man dies am besten löst, sind wir über jede Unterstützung dankbar.

    Da der Rest der Website, wo dies integriert wird, in PHP und MySQL programmiert wurde, würden wir eine Lösung mit MySQL bevorzugen. Wenn du sowas aber mit einer anderen Datenbank realisieren würdest, sind Vorschläge auch willkommen. Wir müssen einfach mit Perl und PHP Scripts auf die Datenbank zugreifen können.


    Wir haben folgende Situation (Äpfel werden nur als Beispiel verwendet!):

    Es gibt beliebig viele Äpfel, wobei keiner gleich ist wie der andere, jeder hat seine individuellen Eigenschaften. Wenn wir nun ein spezielles Programm mit den Eigenschaften von zwei Äpfeln füttern, gibt und dieses einen Übereinstimmungswert zwischen 0% und 100% zurück, was uns zeigt, wie ähnlich die beiden Äpfel sind.

    Die Äpfel verändern sich nie. Also immer wenn ich die gleichen zwei Äpfel vergleiche, kommt auch dasselbe Ergebnis zurück. Für weitere Abfragen möchten wir nun die Resultate in einer Datenbank speichern können.

    In dieser Datenbank wollen wir dann beliebige Abfragen machen können wie z.B.:

    A) Zeige mir die Äpfel mit der grössten Übereinstimmung, dabei sollen aber nur rote Äpfel berücksichtigt werden

    B) Zeige mir die Äpfel mit der grössten Übereinstimmung, wobei nur Äpfel berücksichtigt werden sollen, deren Durchmesser grösser als X ist.

    C) Zeige mir die Äpfel mit der grössten Übereinstimmung, wobei alle Äpfel berücksichtigt werden können.

    etc. dies ist nur ein kleiner Auszug der möglichen Abfragen, die wir nachher machen wollen.


    Natürlich könnte ich in MySQL eine ganz einfache Tabelle machen:

    ApfelID1 ApfelID2 Relevanz
    34 523 68%
    8739 879776 57%
    593 4793 98%

    etc.

    also ich vergleiche einfach jeden Apfel mit jedem und speichere das Ergebnis in dieser Tabelle. Bei 100 verschiedenen Äpfeln wäre das sicherlich auch noch kein Problem, dann hätten wir in der Tabelle gerade mal 4950 Einträge und alles würde wunderbar funktionieren.

    Wenn wir nun aber über 1 Million verschiedene Äpfel haben wären das 4'999'999'500'000 Einträge (wenn ich das jetzt richtig gerechnet habe), wo MySQL mit einer Tabelle wohl an seine Grenzen stossen würde.


    Man müsste wohl sowas wie eine Matchquality-Matrix-DB aufbauen. Habt ihr gute Lösungsvorschläge für diese Problemstellung?

  • #2
    Erstmal würde ich überlegen ob es wirklich nötig ist alle Kombinationen zu speichern oder ob es reicht bereits errechnete zu cachen - das kommt ganz auf die Anwendung an (ein Beispiel: man errechnet wie gut bestimmte Personen (anhand eines Profiles) zusammen passen - in einer normalen Community besuchen aber nie alle Personen alle anderen). Die andere Frage wäre ob es sinnvoll ist derartige Vergleiche und Abfragen zu machen, wenn ihr tatsächlich 1 Mio. Äpfel gleichzeitig miteinander vergleichen wollt und das Ergebnis auch noch in der Gesamtheit abfragen wollt wäre es vielleicht sinnvoller einen Algorithmus zu entwickeln der für jeden Apfel einen Wert errechnet der sich dann mit den Basisfunktionen von MySQL vergleichen lässt.
    Die Regeln | rtfm | register_globals | strings | SQL-Injections | [COLOR=silver][[/COLOR][COLOR=royalblue]–[/COLOR][COLOR=silver]][/COLOR]

    Kommentar


    • #3
      Hallo Tontechniker

      Danke für dein Feedback.

      Da es alle möglichen Arten von Abfragekombinationen geben wird und teilweise wirklich alle mit allen verglichen werden und dann die besten gefunden werden müssen sollte jeder mit jedem einmal verglichen worden und das Ergebnis dann irgendwo abrufbar sein...

      Soweit ich das bis jetzt vom Kunden mitgekriegt habe, wird es nicht möglich sein einen solchen Algorithmus zu generieren...

      Kommentar


      • #4
        Original geschrieben von JayQ
        Soweit ich das bis jetzt vom Kunden mitgekriegt habe, wird es nicht möglich sein einen solchen Algorithmus zu generieren...
        Die Relevanzwerte oder was auch immer sind also nicht berechenbar?
        Wie gedenkt denn der Kunde die DB zu füllen? Hat er ein Heer Chinesen an der Hand?

        Es muss ja nicht unbedingt der Algorithmus sein, der alle Merkmale zu einer einzigen Zahl verwurstet. Vielmehr sollte klar gestellt werden, ob die gesuchte Lösung nur ein DB-Schema und Zugriffsmethoden umfassen soll oder auch die Berechnung irgendwelcher Werte.
        Zuletzt geändert von onemorenerd; 28.04.2008, 19:41.

        Kommentar


        • #5
          OffTopic:
          Wie gedenkt denn der Kunde die DB zu füllen? Hat er ein Heer Chinesen an der Hand?
          Ein Schachfeld und ein paar LKWs Reis
          Die Regeln | rtfm | register_globals | strings | SQL-Injections | [COLOR=silver][[/COLOR][COLOR=royalblue]–[/COLOR][COLOR=silver]][/COLOR]

          Kommentar


          • #6
            Original geschrieben von onemorenerd
            Wie gedenkt denn der Kunde die DB zu füllen? Hat er ein Heer Chinesen an der Hand?
            hehe ja, so wird es dann ungefähr sein.

            Der Kunde hat dieses Programm, welches einfach die Ähnlichkeit zweier Objekte (kann theoretisch auch ein Apfel und eine Birne sein) herausfindet.

            Letztendlich wird es tatsächlich eine grosse Anzahl von Leuten sein, welche die Datenbank mit allen möglichen Objekten füllen und dann Objekte miteinander vergleichen wollen.

            Und dann soll es halt eben auch diese Abfragen geben wie, welche beiden Bananen (jedes Objekt ist mittels eindeutiger ID identifizierbar) sind am ähnlichsten. Oder welche beiden Objekte sind sich grundsätzlich am ähnlichsten. Oder welche Banane gleich am ehesten welcher Birne, etc. ...

            Also wir sind hier auch ein paar Leute, die schon länger an dieser Geschichte herumstudieren, und sind bisher noch auf keine bessere Idee gekommen, also irgendwie/irgendwo solch eine Matrix aufzubauen, wo dann das Resultat aus dem Vergleich von jedem Objekt mit jedem irgendwie abgerufen werden kann...

            Kommentar


            • #7
              Wenn die Ähnlichkeit zweier Objekte nicht algorithmisch bestimmbar ist, wird es wohl keine andere Lösung geben. Für N Objekte braucht ihr eine NxN-Matrix. Denn die von Menschenhand bestimmten Ähnlichkeitswerte müssen ja irgendwo gespeichert werden.

              Bleibt also nur noch die Suche nach einem geschickten DB-Schema für diese Matrix. Der intuitive Ansatz wäre eine Tabelle mit N Spalten (für jedes Objekt eine Spalte) oder N Tabellen mit je 2 Spalten (für jedes Objekt eine Tabelle) oder irgendwas dazwischen (Partitionierung).

              Allgemein wären das N-k Tabellen mit k Spalten, wenn man gleichgroße Partitionen bildet.
              Bei N > 10^6 kann das für ein DBMS problematisch sein, für alle k.

              Da sich die Limits des DBMS kaum umgehen lassen, müsst ihr von der NxN-Matrix wegkommen. Das geht wohl nur, wenn man irgendwelche Merkmale der Objekte nutzt um Klassen zu bilden. Geht das?

              Kommentar


              • #8
                Der Kunde hat dieses Programm, welches einfach die Ähnlichkeit zweier Objekte (kann theoretisch auch ein Apfel und eine Birne sein) herausfindet.
                Ich bezweifle ja noch, dass sich das nicht in die Tabelle integrieren lässt.
                Bleibt also nur noch die Suche nach einem geschickten DB-Schema für diese Matrix.
                Glaube nicht, dass ist sinnvoll ist sowas in einer MySQL Datenbank abzulegen.
                Die Regeln | rtfm | register_globals | strings | SQL-Injections | [COLOR=silver][[/COLOR][COLOR=royalblue]–[/COLOR][COLOR=silver]][/COLOR]

                Kommentar


                • #9
                  Original geschrieben von tontechniker
                  Ich bezweifle ja noch, dass sich das nicht in die Tabelle integrieren lässt.
                  Bezweifle ich auch, aber letztlich weiß das nur der Threadstarter (besser).
                  Glaube nicht, dass ist sinnvoll ist sowas in einer MySQL Datenbank abzulegen.
                  Naja vielleicht nicht MySQL, aber irgendein DBS sollte es schon sein. Schließlich gilt es viele kleine Datenschnipsel zu speichern und nahezu beliebige Anfragen stellen zu können. Genau dafür wurden DBS erfunden.

                  Aus meiner Sicht ist dieses Thema inzwischen an einem Totpunkt angelangt, der sich nur überwinden läßt, wenn der Threadstarter mal preisgibt, wie die Relevanz bestimmt wird. (Ich setze 'nen 10er, dass es doch algorithmisch machbar ist.)

                  Kommentar

                  Lädt...
                  X