persistente Speicherung von Suchparametern (db-seitig)

nikosch · 23.04.2009, 23:11

Nabend Leute,

in einem aktuellen Projekt setze ich ein kleines bis mittelgroßes Portal zur Stellenvermittlung um. Momentan suche ich nach einem Ansatz für eine Suchfunktion. Anbei mal ein Ausschnitt aus der Datenstruktur.

Es sollen sowohl freie Suchbegriffe (LIKE) als auch konkrete Feldbezüge (IDs von Branchen etc., die über einen Suchindex, ein Dropdown oder dergl. ausgewählt werden) frei kombiniert werden können. Soweit so einfach.

Mir stellt sich nun die folgende Frage: Ich würde eine solche Suche gerne speichern können, sowohl Browser-sitzungsbasiert als eine Art Suchhistory, als auch persistent (also an einen Useraccount gekoppelt als Suchoptionen-Favourit). Habt Ihr etwas ähnliches schon einmal umgesetzt und Erfahrungswerte - oder aber einfach so Ideen - was die Art der Speicherung dieser doch sehr verschiedenen Datentypen anbelangt? Ich spiele ja fast mit dem Gedanken, für die persistente Variante einfach die Sitzungsdaten als serialisiertes Objekt oder als XML-Struktur-Setting in der Datenbank abzulegen. Was haltet Ihr davon und seht Ihr bessere Alternativen?

Es grüsst gespannt, der nikosch.

Creator · 24.04.2009, 12:29

Ich kann nicht genau nachvollziehen, warum du das Ergebnis einer Suche speichern willst.
Wäre es nicht Sinnvoller das zu speichern, wo nach gesucht wurde, oder hast du da den Hintergedanken der Performance?

Zitat:

Ich spiele ja fast mit dem Gedanken, für die persistente Variante einfach die Sitzungsdaten als serialisiertes Objekt oder als XML-Struktur-Setting in der Datenbank abzulegen.

Sind die Daten dafür nicht einfach viel zu Dynamisch?

Oder verstehe ich dich vollkommen flasch?

Koala · 24.04.2009, 12:46

er will die Suche speichern - nicht das Ergebnis.

Zitat:

Ich würde eine solche Suche gerne speichern können
...
also an einen Useraccount gekoppelt als Suchoptionen-Favourit

Wär die ganze Suche in einem einzigen Formular,
dann wär das wohl kein Problem.
Aber so wie ich das verstanden hab geht die Suche über
mehrere Schritte.
Vielleicht kann man die Suchoptionen in der Session speichern
und dann in einer separaten DB-Tabelle "search_options",
wobei jede Spalte eine option repräsentiert.

Beim Abschluß der Suche ne Checkbox: "Suchoptionen speichern".

nikosch · 24.04.2009, 13:40

Zitat:

Wäre es nicht Sinnvoller das zu speichern, wo nach gesucht wurde, oder hast du da den Hintergedanken der Performance?

Nein, weil im Normal die Daten schnell inaktuell werden und kurzlebiger sind als die Userbesuche.

Zitat:

und dann in einer separaten DB-Tabelle "search_options",

Ja, meine Frage ist quasi, wie sowas aussehen könnte.
Mal ein Beispiel, wie blöd sich Suchparameterkombinationen abbilden lassen:

Code:

id | suchId | fk_userId | datum | feldbezug      | value      | type
 1 | 1      | 1         |  ...  | NULL           | Büro       | Stichwort
 2 | 1      | 1         |  ...  | JB_Orte.Plz    | 56         | RelationLike
 3 | 2      | 1         |  ...  | JB_Branchen.ID | 1544       | Relation
 3 | 2      | 1         |  ...  | JB_Branchen.ID | 1546       | Relation
 4 | 2      | 1         |  ...  | JB_Branchen.ID | 1547       | Relation
 5 | 1      | 23        |  ...  | NULL           | Hotel      | Stichwort
 6 | 1      | 23        |  ...  | NULL           | Gaststätte | Stichwort

Gruppe über (suchId, fk_userId) bündelt die Optionen eines Suchvorgangs eines Users.
Es gibt
- Stichwortsuchen über Felder mehrerer Tabellen - Problem: Welche Felder das sind, muß fest verdrahtet sein. Wenn ich das auch noch linear oben abbilden wollte, müßte ich nämlich wiederum die Art der Verknüpfung mit abbilden können. Zur Zeit sind alles AND Vk.
- Relationen direkt auf Ids
- Teilsuchen wie oben Postleitzahlteil.

Vom DB seitigen Nutzen dieser Daten ganz zu schweigen. Aus obigem Schema müßte man die Daten wahrscheinlich pro User bei der Anmeldung auslesen und Sessionseitig ablegen, um das einigermasse handlebar zu machen.

brian johnson · 24.04.2009, 16:07

Zitat:

Ich spiele ja fast mit dem Gedanken, für die persistente Variante einfach die Sitzungsdaten als serialisiertes Objekt

da du einen zustand eines objects speichern möchtest, ist dies mit sicherheit keine schlechte idee. aber ich kenne deine db-access-structure nicht, beim active record pattern wäre es in dieser hinsicht z.b. ziemlich einfach.

nikosch · 24.04.2009, 17:28

Naja, da gibts nicht viel. Das Projekt ist schon 'was älter. Nen zusätzlichen DB-Abstraktions-Layer einzuziehen sieht das Projektbudget mit Sicherheit nicht vor.

Was aber nicht heisst, dass ich jetzt total anfangen will zu schludern

yab · 25.04.2009, 06:05

Zitat:

Zitat von nikosch

Nen zusätzlichen DB-Abstraktions-Layer einzuziehen sieht das Projektbudget mit Sicherheit nicht vor.

Man könnte aber sicherlich ganz pragmatisch den suchstring in einem varchar-Feld speichern.

Koala · 25.04.2009, 10:16

Zitat:

Gruppe über (suchId, fk_userId) bündelt die Optionen eines Suchvorgangs eines Users.

Wieso nicht so?:

Code:

id | suchId | fk_userId | datum | JB_Orte.Plz   | JB_Branchen.ID | ...
 1 | 1      | 1         |  ...  | AND, Büro     | OR, 59134      | ...

nikosch · 25.04.2009, 11:26

Naja, etwas dynamischer darf es dann doch sein. Jeden möglichen Suchparameter als Feld abzubilden halte ich für die schlechteste Variante. Zumal ja auch BrancheID 0815 oder BrancheID 0816 ... in einer Suche vorkommen dürfen sollen. Auch die Operatoren machen nicht wirklich Sinn, weil ohne Klammerung schlicht die Operatorreihenfolge entscheidend wäre.
Um mehrere Zeilen pro Suche wird man mit einem halbwegs atomaren Ansatz wohl nicht herumkommen.

Zitat:

Man könnte aber sicherlich ganz pragmatisch den suchstring in einem varchar-Feld speichern.

Naja, nicht wirklich, weil ich die Suchparameter natürlich auch wieder als Feedback im Suchformular wiederanzeigen möchte.

Chriz · 26.04.2009, 02:42

Lass die Suche doch über ein Suchanfrage-Objekt starten. Das kannst du serialisiert in/aus der DB speichern/laden oder eben Schritt-für-Schritt in einem Suchformular über die Session oder POST zusammenbauen.

Wenn ich mal weiter ausholen darf:
Ich benutze für die Ausgabe von Datensätze immer einen Manager (Datenbank-Zugreifer), ein RecordSet (hier nur einen array mit Record-Objekten) und Records (Datencontainer).

Aufruf etwa:

PHP-Code:

  <?php

$manager = $this->_getJobManager();

$manager->addFilterPaging(1);

$manager->addFilterOrder(array("created", false), array("money", true));

$manager->addFilterSector("IT");

$manager->addFilterSector("Computer");

$manager->addFilterLocation("Berlin");

$manager->addFilterFulltext("reich werden");

$manager->addFilterFulltextCaseSensitive(false);

// ..

$jobs = $manager->getJobs();

foreach ($jobs as $job) {

  echo $job->getTitle(), "<br />"; // sowas

}

?>

So nun könntest du ja hergehen, und dir von dieser JobManager-Klasse alle Filter zurückgeben lassen (getFilters() [array]), die sich später auch wieder über addFilters() einlesen liessen.

Code:

array(
  array("paging", array(1)),
  array("order", array(array("created", false), ..)),
  ..
)

Das kannst du ja super einfach serialisiert speichern.

JobManager könnte grob so aussehen (wenn du Zend_Db mal verwenden magst):
(benutzt du eigentlich ein Framework nikosch?)

PHP-Code:

  <?php

class JobManager

{

  const FilterPaging = "paging";

  const FilterLocation = "location";

  protected $_filters = array();

  public function addFilterPaging($page, $entriesPerPage = 25)

  {

    $this->_filters[self::FilterPaging] = array($page, $entriesPerPage);

  }

  // ..

  public function addFilterLocation($location)

  {

    if (!array_key_exists(self::FilterLocation, $this->_filters)) {

      $this->_filters[self::FilterLocation] = array();

    }

    $this->_filters[self::FilterLocation][] = $location;

  }

  // ..

  public function getJobs() 

  {

    $select = $this->_db->select()->from("job_offers")->joinLeft("branchen", $condition);

    foreach ($this->_filters as $filter => $params) {

      $callback = array($this, "_useFilter$filter");

      call_user_func($callback, $select, $params);

    }

    $jobs = array();

    foreach ($this->_db->fetchAll($select) as $data) {

      $job = new Job();

      $job->import($data);

      $jobs[] = $job;

    }

    return $jobs;

  }

  // ..

  protected function _useFilterPaging(Zend_Db_Select $select, array $params)

  {

     list ($entriesPerPage, $page) = $params;

    $select->limit($entriesPerPage, ($page - 1) * $entriesPerPage);

  }

  // usw.

}

?>

So können deine Filter überall herkommen, solange sie "atomar" sind.

Themen-Optionen
Druckbare Version zeigen Jemanden per E-Mail auf dieses Thema hinweisen
Thema bewerten
Thema bewerten:

23.04.2009, 23:11
nikosch moderatives Dielektrikum Registriert seit: 21.05.2008 Beiträge: 35.994 PHP-Kenntnisse: Fortgeschritten	persistente Speicherung von Suchparametern (db-seitig) Nabend Leute, in einem aktuellen Projekt setze ich ein kleines bis mittelgroßes Portal zur Stellenvermittlung um. Momentan suche ich nach einem Ansatz für eine Suchfunktion. Anbei mal ein Ausschnitt aus der Datenstruktur. Es sollen sowohl freie Suchbegriffe (LIKE) als auch konkrete Feldbezüge (IDs von Branchen etc., die über einen Suchindex, ein Dropdown oder dergl. ausgewählt werden) frei kombiniert werden können. Soweit so einfach. Mir stellt sich nun die folgende Frage: Ich würde eine solche Suche gerne speichern können, sowohl Browser-sitzungsbasiert als eine Art Suchhistory, als auch persistent (also an einen Useraccount gekoppelt als Suchoptionen-Favourit). Habt Ihr etwas ähnliches schon einmal umgesetzt und Erfahrungswerte - oder aber einfach so Ideen - was die Art der Speicherung dieser doch sehr verschiedenen Datentypen anbelangt? Ich spiele ja fast mit dem Gedanken, für die persistente Variante einfach die Sitzungsdaten als serialisiertes Objekt oder als XML-Struktur-Setting in der Datenbank abzulegen. Was haltet Ihr davon und seht Ihr bessere Alternativen? Es grüsst gespannt, der nikosch. __________________ -- One pixel is still too big. Please make it smaller. ASAP. Initiative Mittelstand. Die wichtigste Gestaltungsregel im Screendesign ist Pi mal Daumen des Arbeitgebers. -- Geändert von nikosch (23.04.2009 um 23:17 Uhr).


Mister Ad PHP Code Flüsterer Registriert seit: 21.08.2005 Beiträge: 4682 PHP-Kenntnisse: Fortgeschritten

24.04.2009, 17:28
nikosch moderatives Dielektrikum Registriert seit: 21.05.2008 Beiträge: 35.994 PHP-Kenntnisse: Fortgeschritten	Naja, da gibts nicht viel. Das Projekt ist schon 'was älter. Nen zusätzlichen DB-Abstraktions-Layer einzuziehen sieht das Projektbudget mit Sicherheit nicht vor. Was aber nicht heisst, dass ich jetzt total anfangen will zu schludern __________________ -- One pixel is still too big. Please make it smaller. ASAP. Initiative Mittelstand. Die wichtigste Gestaltungsregel im Screendesign ist Pi mal Daumen des Arbeitgebers. --

26.04.2009, 02:42
Chriz Moderator Registriert seit: 11.05.2008 Beiträge: 6.269	Lass die Suche doch über ein Suchanfrage-Objekt starten. Das kannst du serialisiert in/aus der DB speichern/laden oder eben Schritt-für-Schritt in einem Suchformular über die Session oder POST zusammenbauen. Wenn ich mal weiter ausholen darf: Ich benutze für die Ausgabe von Datensätze immer einen Manager (Datenbank-Zugreifer), ein RecordSet (hier nur einen array mit Record-Objekten) und Records (Datencontainer). Aufruf etwa: PHP-Code: `<?php $manager = $this->_getJobManager(); $manager->addFilterPaging(1); $manager->addFilterOrder(array("created", false), array("money", true)); $manager->addFilterSector("IT"); $manager->addFilterSector("Computer"); $manager->addFilterLocation("Berlin"); $manager->addFilterFulltext("reich werden"); $manager->addFilterFulltextCaseSensitive(false); // .. $jobs = $manager->getJobs(); foreach ($jobs as $job) { echo $job->getTitle(), "<br />"; // sowas } ?>` So nun könntest du ja hergehen, und dir von dieser JobManager-Klasse alle Filter zurückgeben lassen (getFilters() [array]), die sich später auch wieder über addFilters() einlesen liessen. Code: array( array("paging", array(1)), array("order", array(array("created", false), ..)), .. ) Das kannst du ja super einfach serialisiert speichern. JobManager könnte grob so aussehen (wenn du Zend_Db mal verwenden magst): (benutzt du eigentlich ein Framework nikosch?) PHP-Code: <?php class JobManager { const FilterPaging = "paging"; const FilterLocation = "location"; protected $_filters = array(); public function addFilterPaging($page, $entriesPerPage = 25) { $this->_filters[self::FilterPaging] = array($page, $entriesPerPage); } // .. public function addFilterLocation($location) { if (!array_key_exists(self::FilterLocation, $this->_filters)) { $this->_filters[self::FilterLocation] = array(); } $this->_filters[self::FilterLocation][] = $location; } // .. public function getJobs() { $select = $this->_db->select()->from("job_offers")->joinLeft("branchen", $condition); foreach ($this->_filters as $filter => $params) { $callback = array($this, "_useFilter$filter"); call_user_func($callback, $select, $params); } $jobs = array(); foreach ($this->_db->fetchAll($select) as $data) { $job = new Job(); $job->import($data); $jobs[] = $job; } return $jobs; } // .. protected function _useFilterPaging(Zend_Db_Select $select, array $params) { list ($entriesPerPage, $page) = $params; $select->limit($entriesPerPage, ($page - 1) * $entriesPerPage); } // usw. } ?> So können deine Filter überall herkommen, solange sie "atomar" sind. __________________ "Nuschel ich?" - "Was?"