[php/json/magento] Twijfel hoe waardes op te slaan in mysql

[Marco1994]

Voor mijn afstudeer project op stage moet ik een module maken waarmee dynamisch product bundels aangemaakt of aangepast kunnen worden.

Situatie schets:
We gebruiken een webshop die draait op Magento.
Het is een groot bedrijf dat tuinkappen levert, een klant koopt een [kleur] tuinkap van [meter] breed...
Dit is in feite een product bundel, een kap van 12m breed bevat bijvoorbeeld 57 schroeven en nog 14 andere producten met een variabel aantal, dus een kap van 7 meter heeft 38 schroeven, etc.

Wat ik aan het maken ben:
In de backend moet per product een aantal regels kunnen worden in gesteld voor een product bundel.
voorbeeld:

code:

If Lengte Greater then 6,06
    If Staanders Equal to 2
        Do Lengte Multiply attribute by 2
        Do Liggers Is 4
    If Dak type Equal to Glas

dit alles prop ik in een array.
voorbeeld

code:

Array
(
    [0] => Array
        (
            [THING] => CONDITION
            [ATTRIBUTE] => Lengte
            [OPERATOR] => Greater then
            [ATTRIBUTE_VALUE] => 6,06
        )

    [1] => Array
        (
            [0] => Array
                (
                    [THING] => CONDITION
                    [ATTRIBUTE] => Staanders
                    [OPERATOR] => Equal to
                    [ATTRIBUTE_VALUE] => 2
                )

            [1] => Array
                (
                    [0] => Array
                        (
                            [THING] => ACTION
                            [AMOUNT] => 2
                            [OPERATOR] => Multiply attribute by
                            [ATTRIBUTE] => Lengte
                        )

                    [1] => Array
                        (
                            [THING] => ACTION
                            [AMOUNT] => 4
                            [OPERATOR] => Is
                            [ATTRIBUTE] => Liggers
                        )
                )
        )

    [2] => Array
        (
            [THING] => CONDITION
            [ATTRIBUTE] => Dak type
            [OPERATOR] => Equal to
            [ATTRIBUTE_VALUE] => Glas
        )
)

Let even niet op mijn prachtige benaming.
Dit alles heb ik werkend in de testomgeving, de conditions en actions kan ik uitvoeren en werkt allemaal naar behoren.

Dit alles wordt door een simpele functie ge-for-looped. Hier krijg ik elke condition of action apart te zien.
Ik houd ook bij in welk level dit genest is.

Het volgende punt is alles op te slaan in de database.
Ik zie hier twee mogelijkheden voor.

Mogelijkheid 1:
Ik sla elke condition of action apart op in een table, deze zal ik later aan elkaar 'plakken' in een array.
Hier zal ik relaties en 'nest-niveaus' moeten leggen.
Voordelen:
-Ik kan rulesets later hergebruiken

Nadelen:
-Ik moet een verschillende relaties en nest-niveaus bij houden.

Mogelijkheid 2:
Ik encode de volledige array in json, sla deze json-string op in de database met een product-sku zodat ik weet bij welk product deze ruleset hoort. En decode deze later naar een array als ik het product uit wil lezen.

Voordelen:
-Dit zal een snellere manier zijn om rulesets te laden. (betere performance)
-Geen gekloot met verschillende nest relaties tussen verschillende rules in een rule set

Nadelen:
-Het is lastiger om een ruleset een tweede keer te gebruiken, ik kan dus de ruleset van een setje schroeven niet hergebruiken voor bijvoorbeeld een set betonpoeren.

Mijn persoonlijke voorkeur gaat uit naar mogelijkheid 2, echter is webdevelopment nog redelijk nieuw voor mij en wil ik dus feedback hebben op mijn gedachtengang.

Ik zoek dus geen kant-en-klare oplossing hebben, maar feedback op mijn gedachtengang.

[Marco1994]

*bump* iemand?

[Miyamoto]

Lijkt me een goed moment om je onderzoek (twee oplossingen) te bespreken met je begeleider. Je hebt er weinig aan wat "wij" er van vinden. Je hebt netjes pros en cons opgeschreven. De uiteindelijke beslissing is mss ook gebaseerd op de werkwijze/voorkeur van het bedrijf.

[Marco1994]

Miyamoto schreef op woensdag 19 maart 2014 @ 10:56:
Lijkt me een goed moment om je onderzoek (twee oplossingen) te bespreken met je begeleider. Je hebt er weinig aan wat "wij" er van vinden. Je hebt netjes pros en cons opgeschreven. De uiteindelijke beslissing is mss ook gebaseerd op de werkwijze/voorkeur van het bedrijf.

Het grappige is dat mijn 'begeleider' zelf ook pas een half jaar van school is, en dus ook zijn twijfels heeft.

[drm]

Ik zou zonder meer voor 2 gaan. Het "hergebruik" argument wordt in het algemeen vreselijk overschat. Het hergebruiken van rules door middel van relaties maakt het geheel in zoveel opzichten zoveel complexer dat het alleen maar een voordeel líjkt en zeker niet is. Je introduceert namelijk een compleet nieuw probleemdomein wat je in eerste instantie helemaal niet had (hoe ga je hierarchische rules relationeel opslaan, hoe zorg je voor precedence, enzovoorts), terwijl als je het gewoon in een tekstveld in je eigen formatje opslaat heel simpel blijft. Of dat dan JSON, of wellicht een DSL is, doet er dan niet meer toe.

Dan zou ik liever het voorbeeld wat je al hebt gemaakt implementeren als DSL en daar een parsertje voor schrijven die vervolgens de ruleset generereert. Dat is echt niet zo moeilijk en geeft veel meer vrijheid (en dus herbruikbaarheid). Je kunt dan eigen rulesets gewoon importeren met een eigen syntax, en hoef je het niet eens in je database op te slaan om het te kunnen testen.

edit:

Even voor je idee, die array die je hebt is eigenlijk een AST van de syntax die je erboven hebt opgeschreven, dus het resultaat van het parsen van die taal.

[ Voor 7% gewijzigd door drm op 19-03-2014 12:18 ]

[Marco1994]

drm schreef op woensdag 19 maart 2014 @ 12:17:
Ik zou zonder meer voor 2 gaan. Het "hergebruik" argument wordt in het algemeen vreselijk overschat. Het hergebruiken van rules door middel van relaties maakt het geheel in zoveel opzichten zoveel complexer dat het alleen maar een voordeel líjkt en zeker niet is. Je introduceert namelijk een compleet nieuw probleemdomein wat je in eerste instantie helemaal niet had (hoe ga je hierarchische rules relationeel opslaan, hoe zorg je voor precedence, enzovoorts), terwijl als je het gewoon in een tekstveld in je eigen formatje opslaat heel simpel blijft. Of dat dan JSON, of wellicht een DSL is, doet er dan niet meer toe.

Dan zou ik liever het voorbeeld wat je al hebt gemaakt implementeren als DSL en daar een parsertje voor schrijven die vervolgens de ruleset generereert. Dat is echt niet zo moeilijk en geeft veel meer vrijheid (en dus herbruikbaarheid). Je kunt dan eigen rulesets gewoon importeren met een eigen syntax, en hoef je het niet eens in je database op te slaan om het te kunnen testen.

edit:

Even voor je idee, die array die je hebt is eigenlijk een AST van de syntax die je erboven hebt opgeschreven, dus het resultaat van het parsen van die taal.

Bedankt voor je reactie, dit was inderdaad ook een van mijn grootste argumenten(Hoe ga ik in godsnaam alles aan elkaar knopen).
Ik ben van Json JSON afgestapt en ga ik voor php serialize/unserialize.


Ik heb op internet benchmarkt gevonden die concluderen dat JSON sneller is om gegevens te coderen, maar langzamer is in decoderen. Aangezien ik verwacht vaker te moeten decoderen, was de keuze voor php serialize/unserialize snel gemaakt aangezien de implementatie exact hetzelfde is.

Ninja edit: dit is het resultaat dat uit mijn 'parse functie' komt rollen in plain text.
Uiteindelijk zal ik in de admin panel de attributes, operators en values (die nu in plain text staan) vervangen door comboboxes.

[ Voor 5% gewijzigd door Marco1994 op 19-03-2014 12:28 ]

[epic007]

Marco1994 schreef op woensdag 19 maart 2014 @ 12:25:
Ik heb op internet benchmarkt gevonden die concluderen dat JSON sneller is om gegevens te coderen, maar langzamer is in decoderen. Aangezien ik verwacht vaker te moeten decoderen, was de keuze voor php serialize/unserialize snel gemaakt aangezien de implementatie exact hetzelfde is.

Het lijkt hier alsof je al aan het optimaliseren bent terwijl dit misschien helemaal niet nodig is (http://c2.com/cgi/wiki?PrematureOptimization).
Als je flexibel wilt zijn zou je idd een DSL moeten maken van je rules / actions en deze in je database opslaan. Zo ben je onafhankelijk van je implementatie.
Mocht je later kiezen om je backend niet in PHP maar bv python, java, c# ofzo te schrijven dan voldoet je database nog steeds. Met php serialize/unserialize lukt dit niet.

[Marco1994]

epic007 schreef op woensdag 19 maart 2014 @ 13:21:
[...]


Het lijkt hier alsof je al aan het optimaliseren bent terwijl dit misschien helemaal niet nodig is (http://c2.com/cgi/wiki?PrematureOptimization).
Als je flexibel wilt zijn zou je idd een DSL moeten maken van je rules / actions en deze in je database opslaan. Zo ben je onafhankelijk van je implementatie.
Mocht je later kiezen om je backend niet in PHP maar bv python, java, c# ofzo te schrijven dan voldoet je database nog steeds. Met php serialize/unserialize lukt dit niet.

Ik ben nog niet perse aan het optimaliseren, maar er zijn zo gigantisch product bundels, dat het gerust 20 minuten duurt om deze allemaal te laden. Aangezien php unserialize 50% sneller kan zijn maakt dit een erg groot verschil.

Echter weet ik voor 100% zeker dat de backend nooit in een andere taal zal komen
En mocht het ooit zo ver komen dat de backend wel volledig opnieuw gemaakt wordt, is het niet z'on probleem denk ik om een php script te schrijven dat de database leeg plukt, vervolgens de boel unserializised, decode in JSON en de database terug in pleurt.