Thalo

Hallo,...

Ich bin mir nicht ganz sicher ob dies das richtige Forum ist -- wenn es eher in Datenbanken passt bitte verschieben

Nehmen wir an, ich habe in meiner Datenbank Pizzen -- wie verbinde ich nun mit einigen Pizzen unterschiedliche Algorithmen?


Einige Beispiel:


Pizza "Viva la summer" kann nur bestellt werden, wenn mindestens 40° Durchschnittstemperatur in Deutschland herrschen.

Pizza "Italia" nur wenn der User Italiener ist..

Eine "Bionade" kann nur bestellt werden, wenn der User Volljährig ist


Wie löst man so etwas möglichst elegant? Vielleicht ist es sogar total banal und ich stehe einfach auf dem Schlauch?

Mister Ad

Freeaak

eine tabelle mit pizzen
eine tabelle mit "algorithmen"
eine tabelle, die beides verbindet (in form von ids)

würde ich vorschlagen. oder hab ich deine frage falsch verstanden?

__________________
"Wenn du nicht weißt, was du tust: Machs mit Eleganz!"

(Murphy's Gesetze)

nikosch

die Frage ist wohl eher, wie man solche Algorithmen sinnvoll abbildet und in SQL umsetzen kann.

__________________
--
One pixel is still too big. Please make it smaller. ASAP.

Initiative Mittelstand.
Die wichtigste Gestaltungsregel im Screendesign ist Pi mal Daumen des Arbeitgebers.
--

Chriz

Hallo,

auf welchem Wissensstand befindest du dich denn? Ob du einen voll-konfigurierbaren E-Shop programmieren willst (und kannst) oder seit zwei Monaten PHP lernst, hätte das ja durchaus Einfluß auf eine Antwort

__________________
"Nuschel ich?" - "Was?"

Thalo

Hi,

Das Problem ist, das ganze kann durchaus komplex werden. Beispiel Eins müsste zum Beispiel über die API eines Wetterdienstes laufen

Wenn ich jetzt was falsches sag werde ich hinterher darauf festgenagelt

Ich bin seit PHP 3 an Board -- die Applikation basiert auf dem Zend Framework


Ich hege einen recht hohen Qualitätsanspruch. Also Antworten können dementsprechend ausfallen

dr.e.

Hi,

Für diese Aufgabe halte ich Business-Rules für angebracht. Hierzu würde ich definieren, wie ein Regelsatz aussieht und welche Operationen (=Auswirkungen) er auf einem Objekt erzeugen kann. Anschließend muss eine Repräsentation dieser Operation in der Datenbank angelegt und mit einem Produkt verknüpft werden.

Möchtest du z.B. eine Liste von Produkten für einen eingeloggten Benutzer anzeigen, muss der Regelsatz für den Benutzer ausgewertet werden und als zusätzliches Selektionskriterium herangezogen werden. Soviel zur Theorie.


Die Information "Durchschnittstemperatur" ist zunächst schwierig zu ermitteln, der "echte" Anwendungsfall dafür kann IMHO "das Produkt ist verfügbar zwischen 01.03. und 15.05." heißen. Die Regel würde also auf die Sichbarkeit des Produktes Einfluss nehmen. Aus diesem Grund muss dein Produkt Objekt-technisch ein Attribut "visibility" mitbringen. Über dieses kannst du dann bei der Selektion eine Einschränkung treffen.


Die hier zu beantwortende Frage lässt sich ebenso auf Sichtbarkeit reduzieren. In diesem Fall müssen nicht Informationen über das Produkt selbst, sondern die des eingeloggten Nutzers ausgewertet werden. Hier passiert also eine Einschränkung auf Grund des Typs oder der Zugehörigkeit eines Benutzers zu einem Land. Für die Abbildung gibt es IMHO eine sinnvolle Möglichkeiten: die Einschränkung passiert über die Assoziation zwischen Land und Produkt - sofern quasi Verfügbarkeiten pro Land in deinem System definierbar sind.

Auch hier geht es um Daten eines Nutzes, allerdings kann das nicht wie zuvor über die Struktur der Daten abgebildet werden, sondern muss tatsächlich über das Attribut des Benutzers abgedeckt werden. Diese Daten müssen gegen Daten des Produkts (z.B. Attribut für Mindestalter, um generischer zu bleiben) vergleichen werden.

Das ist eine berechtigte Frage. An sich muss es eine Mischung zwischen erweiterter Datenhaltung und einer möglichst Ressourcen-schonenden Sortier- und Ausschluss-Logik sein. Ersteres ist meiner Ansicht nach sehr einfach durch Analyse der Domäne zu erledigen, für zweiteres sehe ich das so:
In deiner Business-Schicht werden zusätzliche Regelsätze abstrahiert definiert - meinetwegen auch mit einem DB-Backend - und diese lassen sich in der Datenschicht zu einem zusätzlichen Selektionskriterium de-serialisieren, die in ein SQL-Statement eingehangen werden können. Hierzu solltest du jedoch eine Abstraktion für die Generierung der Statements schaffen, wie sie hier beschrieben ist. Dein Regel-Objekt kann dann seine eigene Logik in ein solches SQL-Regelwerk übersetzen.

Um zu definieren, wie eine solche Logik auszusehen hat, müsste ich nochmal in mich gehen. Hier ist aber vor allem dein Input hinsichtlich der erwarteten Komplexität notwendig.

Cheers,
Dr.E.

__________________
Viele Grüße,
Dr.E.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1. Think about software design before you start to write code!
2. Discuss and review it together with experts!
3. Choose good tools (-> Adventure PHP Framework (APF))!
4. Write clean and reusable software only!
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

nikosch

Da steckt schon viel Information in der Antwort. Es wäre schön, wenn Du da noch einmal in Dich gingest, Doc E. Ich stehe nämlich aktuell vor einer ähnlichen Problematik, wenn auch nicht ganz so komplex gelagert.

__________________
--
One pixel is still too big. Please make it smaller. ASAP.

Initiative Mittelstand.
Die wichtigste Gestaltungsregel im Screendesign ist Pi mal Daumen des Arbeitgebers.
--

dr.e.

Hmm, das kann ich schon machen, man müsste dazu aber mal ein bischen UML zeichnen und ein paar Zeilen schreiben. Kannst du vielleicht deine Problematik etwas näher erläutern? Das ist IMHO insofern wichtig, als dass die Definition des Regelsatzes dann komplexer oder weniger komplex ausfällt.

__________________
Viele Grüße,
Dr.E.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1. Think about software design before you start to write code!
2. Discuss and review it together with experts!
3. Choose good tools (-> Adventure PHP Framework (APF))!
4. Write clean and reusable software only!
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

nikosch

Naja, ich möchte dem TE jetzt nicht den Thread streitig machen. Kurz gesagt gehts bei mir darum, einem Datensatz freie Assoziationen zuordnen zu können, die sich auf konkrete Relationen abbilden lassen.
Ein besonderes Problem habe ich dabei, dass ich mehrere dieser Assoziationen gerne mit Operatoren verknüpfen würde.

__________________
--
One pixel is still too big. Please make it smaller. ASAP.

Initiative Mittelstand.
Die wichtigste Gestaltungsregel im Screendesign ist Pi mal Daumen des Arbeitgebers.
--

Thalo

Hi Doc,


Eben genau dies hatte ich versucht zu vermeiden. Ich wollte mich auf nicht auf ein bestimmten Datumsbereich beschränken, sondern auf Gegebenheiten. Wie z.B , dass mindestens 40° herrschen müssen um die Pizza zu bestellen.

Ich hatte gedacht, sobald die Pizza mit einer Regel assoziiert ist, ist sie temporär. Aber das lässt sich in der Praxis wohl nicht so sagen?


Die Regel sollte alle möglichen Einschränkungen für jeweilige Pizza treffen. Ich möchte ungern weitere Attribute mit der Pizza assoziieren wie das "Mindestalter" oder "Land"...