PHP Datenbankbasierte Suchfunktion mit mehreren Eingabemöglichkeiten

Lollek · 10. Oktober 2014

Die Angelegenheit ist ziemlich komplex und alleine komme ich da als php-Dodo nicht weiter.

Ich benötige für eine Webseite, mittels derer ich ein Netzwerk aufbauen möchte, eine Suchfunktion mit gleichzeitiger Eingabemöglichkeit der Daten.
Es handelt sich um ein gemeinnütziges Portal ohne Gewinnstreben.

Gesammelt werden sollen folgende Daten:
Name und Adresse von Erzeugern getrennt nach Bundesland
Art der Waren die erzeugt werden

Die Suche soll enthalten:
Suche nach bestimmten Waren
Suche nach Bundesländern
Suche nach Adressen
Umkreis Postleitzahlensuche

um es weiter zu verdeutlichen, folgend ein Verweis zu einer Seite, die solch eine Suche hat:

http://www.erzeuger-direkt.de/umkreissuche/find.php

Mir ist durchaus klar, das es sich dabei um einen komplexen Code handeln wird, trotzdem wäre es sehr nett, wenn mich jemand dabei unterstützen könnte.

Troublegum · 10. Oktober 2014

Du brauchst erstmal deine Datenbankstruktur. Naheliegend ist:
- eine Tabelle für Erzeuger
- eine Tabelle für Waren
- eine Tabelle für die N-M Verknüpfung zwischen Erzeugern und Waren (Erklärung siehe zB http://www.sqldocu.com/nine/relationship.htm)

Die Suche selbst ermöglichst du dann durch eine SQL-Abfrage.
Dazu gibts auch gute Tutorials, die Datenbank Strukturen und SQL erklären.

Für die Umkreissuche musst du dir erst Geodaten zu den Postleitzahlen besorgen. Da gibt es kostenlose Downloads im Netz, zB http://opengeodb.org/wiki/OpenGeoDB

Daaron · 10. Oktober 2014

Was du brauchst...
- ein gutes Framework oder CMS als Grundlage, dass dir die ganzen Basisaufgaben wie Routing, Datenbankabstraktion und evtl. sogar Models abnimmt.
- eine RICHTIG durchdachte Datenbank-Struktur. Kompakt, und doch erweiterbar. Saubere und ideal platzierte Indizes. Referentielle Integrität. Der ganze Kleister
- einen klar strukturierten Workflow
- eine saubere Rechteverwaltung. Wer darf sich einloggen? Was darf er dann? Wer darf neue Objekte anlegen?
- eine gute Caching-Lösung, damit das Ding nicht zur Schnecke verkommt
- eine saubere und intuitive Möglichkeit, um sowohl statische Seiten als auch deine Produkte/Erzeuger/... anzulegen und für den Endkunden darzustellen
- die schon erwähnte Geo-Datenbank

Da ich in der Vergangenheit an etwas ähnlichem mal gearbeitet habe kann ich dir sagen: So ein Projekt kostet, wenn es leidlich gut gemacht sein soll, problemlos soviel wie ein Mittelklassewagen. An so etwas sitzen mehrere professionelle Entwickler & Grafiker für mehrere Wochen.

benneq · 10. Oktober 2014

Einfache Text und GeoSuchen kann quasi jede Datenbank. Inzwischen hat so ziemlich jede DB einen "Point" oder "GeoPoint" Datentyp.

Besonders bequem fand ich GeoSuchen via Elasticsearch. Da kann man z.B. Umkreissuchen mit km Angaben machen und muss nicht erst hin- und herrechnen und die Erdkrümmung berücksichtigen.
Ansonsten ist ES dank Analyzer/Tokenizer besonders für alle Arten von Textsuchen sehr gut geeignet und es skaliert wunderbar über mehrere Server.

Allerdings unterscheidet sich die Konfiguration erheblich von den üblichen Verdächtigen (RDBMS, MongoDB). Also das Mapping der Felder auf Datentypen und die Query/Filter-Syntax ist auch andersartig.

In meinem letzten Projekt hatten wir u.a. das Problem, dass wir eine Kontakt-Suche in MySQL ausgeführt haben (bei 130000 Kontakten) und diese Tabelle dann mit 8 weiteren Tabellen gejoint werden musste, weil auf jeder dieser Tabellen gesucht wurde (fast ausschließlich String-Vergleiche mit LIKE). Das Ergebnis war eine inakzeptable Suchzeit von ~1 Sekunde. Danach hab ich mich hingesetzt und dieselbe Suche mit denselben Daten in ES geschrieben. Ich war etwas überrascht, dass es nur zwischen 1-3ms dauerte

Nachteil: Man muss die Daten in 2 Datenbanken speichern, alle Aktualisierungen/Löschungen in beiden Datenbanken ausführen, etc.

Um das Ganze zu erleichtern, bietet ES sog. "Rivers" an. Damit kann man sich diesen Datenabgleich sparen, weil ES die Hauptdatenbank "überwacht" und alle Änderungen übernimmt. (Damit hab ich allerdings nicht gearbeitet).

Abgesehen von der Suche: siehe was Daaron zu sagen hatte

Lollek · 10. Oktober 2014

Besten Dank für eure Antworten.
Allerdings bezweifel ich dadurch jetzt schon, ob ich solch ein Projekt wirklich alleine in Angriff nehmen kann.
Nun, ich werden mich mal in eure Vorschläge etwas einarbeiten und schauen, ob mir die ganze Sache nicht doch zu hochtechnisiert ist.
Aber zumindest habe ich ja oben schon mal zwei Links und ansonsten etliche Fachbegriffe, mit denen ich bei Google sicherlich etwas mehr finde, als bisher.
LG

benneq · 10. Oktober 2014

Erst mal solltest du ganz genau definieren welche DatenTypen es geben soll:
Nutzer, Erzeuger, Waren, etc.

Dazu noch welche Daten jeder Typ haben soll/muss:
Nutzer hat Namen und Passwort, Erzeuger hat Adresse und Name, Adresse hat Straße, PLZ, Ort, Ware hat Name, etc. pp.

Dann die Verknüpfung der Daten:
z.B. Erzeuger hat genau 1 Adresse, Erzeuger hat beliebig viele Waren, ...

Wer darf was mit welchen Daten:
z.B.: Nutzer, der einen Erzeuger erstellt hat darf diesen editieren, sonst niemand. Alle Nutzer (auch nicht eingeloggte?!) dürfen auf allen Datensätzen suchen. Muss man sich registrieren, um neue Daten anzulegen? etc.

Auf welchen Daten genau darf/soll gesucht werden:
Wenn ich in die Suchmaske "Ha" eingebe, findet er dann nichts, oder nur Erzeuger die HAselnüsse anbieten, oder auch welche die in der HAuptstraße wohnen, oder auch die wo der Kontaktperson HAns heißt?

Wenn du sich mit Security gar nicht auskennst, solltest du wirklich zu einem CMS greifen. Wenn du die Lösung selbst baust, ohne dich sehr gut auszukennen, wird deine Datenbank sehr sehr schnell entweder vollgemüllt oder geleert oder zum Austausch illegaler Daten genutzt.

Die Auswahl der "richtigen" Datenbank ist im Endeffekt Geschmackssache. Ob es nun ein good ol' RDBMS ist, oder eine hippe NoSQL Lösung, ist im Endeffekt völlig egal. In jedem Fall muss man wissen WIE man es anstellt.
Natürlich hat jede Datenbank hier und da Vor- und Nachteile. Aber laut deinen Angaben ist es bei deinen Daten ziemlich egal ob die Daten in Tabellen, Dokumenten oder Knoten in einem Graphen sind.

Über Caching und Indizes musst du dir vorerst keine Gedanken machen. Das sind beides natürlich sehr wichtige Punkte für große Anwendungen, die die Serverhardware ausreizen, aber ich denke mal, du bist schon froh, wenn die Webseite überhaupt läuft - egal wie schnell

Wenn das Datenmodell und die Anwendung steht, weißt du ja dann auf welchen Daten die Suchanfragen laufen und kannst dann dort Indizes setzen. Und dann siehst du auch welche Daten besonders oft abgefragt werden und kannst diese cachen.

Lollek · 10. Oktober 2014

benneque schrieb:
Erst mal solltest du ganz genau definieren welche DatenTypen es geben soll:
Nutzer, Erzeuger, Waren, etc.

Die Nutzer (also die Kunden der Erzeuger) sollen in der DB nicht zu suchen haben. Darin sollen nur die Erzeuger mit Adresse und deren angebotenen Waren erscheinen.

benneque schrieb:
Dazu noch welche Daten jeder Typ haben soll/muss:
Nutzer hat Namen und Passwort, Erzeuger hat Adresse und Name, Adresse hat Straße, PLZ, Ort, Ware hat Name, etc. pp.

Der Nutzer darf nur über die Suchfunktion auf die DB zugreifen. Beim Erzeuger die kompletten Adressdaten und seine angebotenen Waren.

benneque schrieb:
Dann die Verknüpfung der Daten:
z.B. Erzeuger hat genau 1 Adresse, Erzeuger hat beliebig viele Waren, ...

Genau so. Hat ein Erzeuger mehrer Niederlassungen, bekommt er auch mehrer unabhängige Datensätze

benneque schrieb:
Wer darf was mit welchen Daten:
z.B.: Nutzer, der einen Erzeuger erstellt hat darf diesen editieren, sonst niemand. Alle Nutzer (auch nicht eingeloggte?!) dürfen auf allen Datensätzen suchen. Muss man sich registrieren, um neue Daten anzulegen? etc.

Eigentlich hatte ich es so geplant, das ich mit einigen Morderatoren die Daten eingeben und verwalten werde, damit eben nicht jeder Zugriff auf die Datenbank erhält, sie also auch nicht vollmüllen kann, wie du selber ja auch ansprachst. Die reine Suche sollte dann schon in allen für den Kunden relevanten Datensätzen erfolgen dürfen.

benneque schrieb:
Auf welchen Daten genau darf/soll gesucht werden:
Wenn ich in die Suchmaske "Ha" eingebe, findet er dann nichts, oder nur Erzeuger die HAselnüsse anbieten, oder auch welche die in der HAuptstraße wohnen, oder auch die wo der Kontaktperson HAns heißt?

In der Suchmaske sollte die Ware vom Kunden schon richtig definiert werden, so dass daraufhin auch nur die Erzeuger in dem gewählten Bundesland gezeigt werden, die diese Ware anbieten.
Im Gegensatz dazu bei der Postleitzahlensuch mit Umkreis sollen alle Erzeuger in diesem Kreis unabhängig von der Ware angezeigt werden.
Beides jeweils in Listenform.
Und hinter jedem Suchergebnis soll ein Link zu finden sein, der den gewünschten Datensatz mit allen Daten wie Name Adresse, Telefonnummer und Art der Waren z.B. in einem neuen Fenster auf den Schirm bringt.

benneque schrieb:
Wenn du sich mit Security gar nicht auskennst, solltest du wirklich zu einem CMS greifen. Wenn du die Lösung selbst baust, ohne dich sehr gut auszukennen, wird deine Datenbank sehr sehr schnell entweder vollgemüllt oder geleert oder zum Austausch illegaler Daten genutzt.

Gibt es denn CMS, über die man einer derart umfangreiche Sache ralisieren kann?

benneque schrieb:
Die Auswahl der "richtigen" Datenbank ist im Endeffekt Geschmackssache. Ob es nun ein good ol' RDBMS ist, oder eine hippe NoSQL Lösung, ist im Endeffekt völlig egal. In jedem Fall muss man wissen WIE man es anstellt.
Natürlich hat jede Datenbank hier und da Vor- und Nachteile. Aber laut deinen Angaben ist es bei deinen Daten ziemlich egal ob die Daten in Tabellen, Dokumenten oder Knoten in einem Graphen sind.

In welcher Form die Daten gespeichert sind, dürfte wirklich keine Rolle spielen. Und da sie öffenrtlich zugänglich sind, durch die Suche, muss man sie ja auch nicht gegen Zugriff schützen sondern nur gegen Veränderung.

benneque schrieb:
Über Caching und Indizes musst du dir vorerst keine Gedanken machen. Das sind beides natürlich sehr wichtige Punkte für große Anwendungen, die die Serverhardware ausreizen, aber ich denke mal, du bist schon froh, wenn die Webseite überhaupt läuft - egal wie schnell
Wenn das Datenmodell und die Anwendung steht, weißt du ja dann auf welchen Daten die Suchanfragen laufen und kannst dann dort Indizes setzen. Und dann siehst du auch welche Daten besonders oft abgefragt werden und kannst diese cachen.

Da sprichst du ein großes Wort gelassen aus. Erst müsste ich es überhaupt schaffen, solch ein Projekt zu realisieren. Dann kann man auch über die Feinheiten sprechen. Ich denke, wenn ich das ans laufen bekomme, kenne ich mich danach auch etwas besser mit der Materie aus.

Aber ob ich da jemals realisiert bekomme?????????

benneq · 11. Oktober 2014

Lollek schrieb:
Aber ob ich da jemals realisiert bekomme?????????

Übung macht den Meister

Oder du fragst 'nen Bekannten, der sich damit auskennt. Ooooder du bezahlst jemanden, damit der es macht.

Wenn das da oben wirklich alles an Daten ist, dann schafft ein (erfahrener) Entwickler das locker an einem Tag zu einer benutzbaren Beta-Version (Optimierungen ausgeschlossen).

Fassen wir zusammen:

Es gibt im Grunde nur 2 Arten von Benutzern, die sich registrieren/einloggen müssen: Erzeuger und Moderatoren

Ein Erzeuger kann mehrere Niederlassungen erstellen. Und zu jeder Niederlassung eine Liste von Produkten anlegen.

Also gibt es als Datentypen: Benutzer (für login), Benutzergruppe (Erzeuger oder Moderator), Erzeuger (u.a. Name, email, handy), Niederlassung (Adresse und GeoDaten), Produkte

Erzeuger dürfen ihre eigenen Daten editieren: Niederlassungen anlegen/entfernen, Produkte zu den Niederlassungen anlegen/entfernen
Moderatoren dürfen neue Erzeuger anlegen/entfernen und die Niederlassungen und Produkte anlegen/entfernen

Alle (auch nicht eingeloggte) dürfen alle Datensätze (Erzeuger, Niederlassung, Produkt) durchsuchen.

Also ein CMS verwaltet im Prinzip erstmal nur beliebige Inhalte, und (das ist der springende Punkt für dich) bringt eine solide Benutzerverwaltung mit Rechtemanagement mit! Die eigentliche Logik deines Programms muss man natürlich separat erstellen.

Also wirklich simpel!

In einem RDBMS wie MySQL ergibt das vermutlich 4-5 Tabellen. In einem DocumentStore wie MongoDB lässt sich das in 2-3 Collections abfrühstücken.

(Zum Vergleich: Mein aktuelles Projekt besteht aus über 80 Tabellen und mit jedem Kundenwunsch werden es mehr

)

Lollek · 11. Oktober 2014

Danke schön dafür.
Du hast mir wieder Mut gemacht.
Ich werde mich mal etwas tiefer mit den Themen befassen und zur Not muss ich halt etwas Geld in die Hand nehmen, und es von jemandem machen lassen. Zumindest das Grundgerüst, auf dem ich dann aufbauen kann.
Ich halte dich/euch hier auf dem Laufenden.
Wünsche jetzt erst mal ein schönes Wochenende.

Daaron · 11. Oktober 2014

Lollek schrieb:
Die Nutzer (also die Kunden der Erzeuger) sollen in der DB nicht zu suchen haben.
...
Der Nutzer darf nur über die Suchfunktion auf die DB zugreifen.

Also hat der Endverbraucher DOCH Zugriff auf Teile der Datenbank... in Form von Suchanfrage. Er hat nur eben (logischerweise) keine Schreibrechte.

Gibt es denn CMS, über die man einer derart umfangreiche Sache ralisieren kann?

Evtl. könntest du mit Contao und der MetaModels - Erweiterung verhältnismäßig schnell kleine Erfolge feiern.

benneque schrieb:
Wenn das da oben wirklich alles an Daten ist, dann schafft ein (erfahrener) Entwickler das locker an einem Tag zu einer benutzbaren Beta-Version (Optimierungen ausgeschlossen).

Na ja, wenn es nur um die Datenstruktur gehen würde, evtl. schon... aber zu einer Webseite gehört eben noch deutlich mehr. Wenn der Scheiß am Ende nicht aussehen soll wie der Link im ersten Thread (also wie späte 90er), dann muss hier schon einiges an Arbeit rein gesteckt werden.
Wie gesagt: Routing für anständige URLs, eine ordentliche Datenbank-Abstraktion, ein hübsches MVC-Pattern wäre nicht verkehrt...

Ein Erzeuger kann mehrere Niederlassungen erstellen. Und zu jeder Niederlassung eine Liste von Produkten anlegen.

Da hast du dann ein großes Problem beim erstmaligen Anlegen der Produkte. Sollte ein Erzeuger jetzt Bio-Tomoffeln anbieten wollen, muss erst ein Moderator selbige Tomoffeln im System bereit stellen.
So etwas artet wirklich übel in Arbeit aus.

Also wirklich simpel! In einem RDBMS wie MySQL ergibt das vermutlich 4-5 Tabellen.

Elementar für die Aufgabenstellung: users, groups, producers, stores, products
evtl. noch sinnig: product_types
Wobei Produkte so gravierend unterschiedlich sein können, dass Produktspeicherung nach diesem Schema ziemlich ineffizient oder gar unmöglich wird. Je nach Komplexität kann es am Ende darauf hinaus laufen, dass man für Produkte eher den Ansatz wählt: Tabelle: product_attributes; Felder: product_id, attribute_id, value

Für eine komplette Seite drumherum notwendig:
- Tabellen für den Seitenbaum, "regulären" Content (Texte, Bilder,...), evtl. eine Tabelle in der die verschiedenen Module verwaltet werden, ein Logbuch, Tabellen, die News verwalten, Tabellen, die Newsletter verwalten,...

(Zum Vergleich: Mein aktuelles Projekt besteht aus über 80 Tabellen und mit jedem Kundenwunsch werden es mehr )

Damit hast du glaub ich einen Magento-Shop mit ner Horde Extensions überholt. Gratuliere.

benneq · 11. Oktober 2014

Daaron schrieb:
Damit hast du glaub ich einen Magento-Shop mit ner Horde Extensions überholt. Gratuliere.

Danke

Geht aber auch nicht anders, wenn das Projekt aus 15 Modulen besteht.

Ansonsten könnte man beim Projekt des TE wirklich über einen DocumentStore nachdenken:

Code:

{
  name: "Bauer Peter",
  user: 42,
  stores: [
    {
      name: "Store 1",
      address: {
        street: "Feldweg 1",
        zip: "12345",
        city: "Berlin",
        region: "Berlin",
        country: "DE",
        position: {
          lat: ...,
          lon: ...
        }
      }
      products: [
        "APFEL",
        "BIRNE"
      ]
    },
    {
      name: "Store 2",
      address: {
        street: "Dorfgasse 3",
        zip: "54321",
        city: "Buxtehude",
        region: "Niedersachsen",
        country: "DE",
        position: {
          lat: ...,
          lon: ...
        }
      }
      products: [
        "FLEISCH"
      ]
    }
  ]
}

Dazu dann noch eine Collection mit den verfügbaren Produkt Typen (falls das ganze eingeschränkt werden soll) und noch eine für die User.

Daaron · 11. Oktober 2014

Pft... ACID, ACID über alles!

benneq · 11. Oktober 2014

Wenn du ACID willst, geh zum Dealer deines Vertrauens

Suche

PHP Datenbankbasierte Suchfunktion mit mehreren Eingabemöglichkeiten

Lollek

Newbie

Troublegum

Lt. Commander

Daaron

Fleet Admiral

benneq

Fleet Admiral

Lollek

Newbie

benneq

Fleet Admiral

Lollek

Newbie

benneq

Fleet Admiral

Lollek

Newbie

Daaron

Fleet Admiral

benneq

Fleet Admiral

Daaron

Fleet Admiral

benneq

Fleet Admiral