Opslaan van formules en variabelen in MySQL

[eLScha]

Voor een nieuw project moet ik formules en variabelen opslaan in een MySQL database. Sommige variabelen zijn statisch (1, 4, 0.5) maar andere variabelen worden berekend door formules. Binnen deze formules worden dan weer statische variabelen gebruikt, of zelfs het resultaat van andere formules.

Nu heb ik redelijk wat ervaring met MySQL, maar wat is nu een goede manier om dit op te slaan? Zelf heb ik hier over nagedacht:

variableTypes:
variableTypes_id | variableTypes_type
1 | static
2 | formula

variables
variables_id | variables_name | variableTypes_id | variables_value
1 | statisch1 | 1 | 1
2 | statisch2 | 1 | 3
3 | statisch3 | 1 | 0.5
4 | statisch4 | 1 | 5
5 | formule1 | 2 | (statisch1 + statisch2) / statisch3
6 | formule2 | 2 | formule1 / statisch4
7 | formule3 | 2 | (formule2 > 5) ? 1 : 0
8 | formule4 | 2 | (formule2 > 5 && statisch3 > 1) ? (formule1 / statisch2) : 0

Maar waarom sla je formule2 niet gewoon op als ((statisch1 + statisch2) / statisch3) / statisch4"?

Dat heeft ermee te maken dat er straks honderden formules in de database komen waarbij het kan dat formule1 een kleine aanpassing krijgt. Het is dan niet de bedoeling dat alle afhankelijke formules ook aangepast moeten worden.

Graag jullie hulp.

[ Voor 4% gewijzigd door eLScha op 17-01-2013 21:13 . Reden: formule 3 en 4 toegevoegd ]

[Janoz]

Waarom wil je dit in een database doen? Waarom zou juist een spreadsheet niet voldoen?

[eLScha]

Dat is tweeledig:
1. De applicatie staat nu in Excel en begint daar enorm uit z'n voegen te groeien
2. De applicatie gaat benaderd worden vanaf verschillende locaties en door verschillende mensen zullen diverse variabelen aangepast worden.

[pedorus]

Google docs FTW? Ga je nu daadwerkelijk zelf een generieke spreadsheet-achtige applicatie ontwikkelen? Dat kan natuurlijk al snel enorm uit de klauwen lopen.. In ieder geval zijn er genoeg bestaande (online) oplossingen voor als Excel uit z'n voegen groeit, beetje afhankelijk van je probleem en je budget.

Terug op je vraag, die ik wat onduidelijk geformuleerd vind omdat ik dus niet helemaal snap wat je nu wil: Ik zou in ieder geval bijhouden welke berekening waar van afhangt, met een koppeltabel om die many-to-many relatie op te slaan (formulaId,dependsOnId). Je wilt waarschijnlijk niet namen steeds als tekst opslaan.

[Gomez12]

Honderden formules klinkt nu niet echt als zoveel / onbeheersbaar dat je er een dbase voor moet zetten.

Ik zou het of in excel doen of gewoon een custom app maken waarbij je formules als een soort van templates gaat zien en het uiteindelijke resultaat door eval heengooit.

Laat ik het eens andersom vragen anders : Als er honderden formules instaan, hoe gaat een klant dan ooit weten welke te pakken / welke waar in te voegen? Daar heb je imho toch een custom iets voor nodig wat tussenresultaten etc gaat tonen (zodat zichtbaar is dat formule 2 afhankelijk is van formule 1, zodat als je iets wilt aanpassen dat je of formule 1 moet aanpassen (of als je daar de dependencies van bekijkt) dat je formule 3 moet creeeren).

Qua verwerking kan het technisch gezien allemaal wel in een dbase, maar je moet je wel in tig bochten wringen en je beheer is dramatisch

[Verwijderd]

schakenraadjuh schreef op donderdag 17 januari 2013 @ 20:21:
...

5 | formule1 | 2 | (statisch1 + statisch2) / statisch3
6 | formule2 | 2 | formule1 / statisch4

...

Maar waarom sla je formule2 niet gewoon op als ((statisch1 + statisch2) / statisch3) / statisch4"?

Dat heeft ermee te maken dat er straks honderden formules in de database komen waarbij het kan dat formule1 een kleine aanpassing krijgt. Het is dan niet de bedoeling dat alle afhankelijke formules ook aangepast moeten worden.

Weet je zeker dat je beoogde doel zo wordt gehaald? Ik weet niet hoe je parser de formules evalueert, maar logisch gezien lijkt mij hier precies te gebeuren wat je juist wilt voorkomen.

[eLScha]

Verwijderd schreef op vrijdag 18 januari 2013 @ 00:31:
[...]


Weet je zeker dat je beoogde doel zo wordt gehaald? Ik weet niet hoe je parser de formules evalueert, maar logisch gezien lijkt mij hier precies te gebeuren wat je juist wilt voorkomen.

Het is de bedoeling dat wel alle berekeningen aangepast worden, maar niet alle formules aangepast hoeven te worden. De uitkomst van formule2 kan in tientallen andere formules gebruikt worden. Pas je vervolgens formule2 aan, dan verandert de uitkomst van die tientallen andere formules zonder dat ik daarvoor al die formules voor aan heb moeten passen.

[Gomez12]

schakenraadjuh schreef op vrijdag 18 januari 2013 @ 12:53:
[...]


Het is de bedoeling dat wel alle berekeningen aangepast worden, maar niet alle formules aangepast hoeven te worden. De uitkomst van formule2 kan in tientallen andere formules gebruikt worden. Pas je vervolgens formule2 aan, dan verandert de uitkomst van die tientallen andere formules zonder dat ik daarvoor al die formules voor aan heb moeten passen.

Dat is leuke theorie, totdat formule1 opeens richting formule2 gaat wijzen en je een eindeloze loop krijgt.

Of totdat formule 10 tot 20 allemaal formule 2 gebruiken (en dus indirect ook formule1) en dan komt handige harry die in formule 16 een aanpassing nodig heeft en daarvoor formule1 of 2 aanpast en het hele kaartenhuis in elkaar laat storten.

Technisch kan het, praktisch zou ik voor een solidere oplossing kiezen...

[Verwijderd]

Zoals velen zou ik het lekker aan een spreadsheet overlaten om formules op te slaan. Als die formules elkaar aanroepen moet de spreadsheetbouwer dat maar gestructureerd doen.
Wellicht dat er nog oplossingen zijn om wijzigingen van de formules via een versiebeheertool a la subversion of git ergens in te checken zodat je een audit trail hebt.

Wellicht dat een ander programma zoals Matlab etc dit ook zou kunnen, geen idee want geen ervaring mee.

Tenslotte zou je de invoerdata/variabelen wel in een db kunnen opslaan als dat helpt...

[Zoijar]

Opslaan als expression tree: http://www.iue.tuwien.ac.at/phd/klima/node56.html

En dan de standaard dingen om een boomstructuur in je database te krijgen. bv: id | parentid | orderingindex | operatorid | constid, waar operator iets is als "+" of "/", misschien nog met instructies voor c-code, of anders constid wijst naar een constante met value en naam, orderingindex geeft de volgorde van child nodes aan voor dingen als "/". (kan ook anders... http://fungus.teststation...handling/TreeHandling.htm )

[ Voor 8% gewijzigd door Zoijar op 18-01-2013 17:11 ]

[Verwijderd]

Als je het zo nodig in een database wilt hebben dan is SQLite een betere optie. Dit is een op-een-bestand-gebaseerde database, die je met een makkelijke api zou kunnen aanspreken.

[Herko_ter_Horst]

Je spreekt zo'n DB in het algemeen aan via een standaard-API en SQL queries, dus ik zie niet in waarom de ene SQL database als oplossingsrichting beter zou zijn dan de andere?

[ Voor 41% gewijzigd door Herko_ter_Horst op 18-01-2013 19:06 ]

[Verwijderd]

Omdat het aantal formules praktisch niets is, en het inrichten van een MySQL database server met dit doel teveel van het goede is. Een SQLite of zelfs BerkeleyDB is echt meer dan genoeg voor het opslaan van dit soort vormen van data.

- Ik ga ervan uit dat database enkele megabytes groot zal zijn met als maximum misschien zelfs 15 a 20 megabyte, als wij het daadwerkelijk hebben over een database met honderden aantallen aan formules.
- De database zal niet eens 50 bezoekers tegelijk in zijn algehele gebruik meemaken.

Waarom zou je een full featured database instance willen inrichten als een op-een-bestand-gebaseerde database oplossing, zoals SQLite, meer dan voldoende is gezien het bovenstaande En gezien het praktisch geen echte resources claimt en bijna dezelfde mogelijkheden heeft als MySQL?

[Zoijar]

Verwijderd schreef op zaterdag 19 januari 2013 @ 19:11:
Waarom zou je een full featured database instance willen inrichten als een op-een-bestand-gebaseerde database oplossing, zoals SQLite, meer dan voldoende is gezien het bovenstaande En gezien het praktisch geen echte resources claimt en bijna dezelfde mogelijkheden heeft als MySQL?

Misschien omdat je al een mysql server hebt draaien en dus alleen een database instance of zelfs tabel hoeft toe te voegen. Misschien omdat je van vele verschillende locaties dezelfde data aan wilt spreken en je niet een heel network sharing iets op wilt zetten om een bestand te delen. Waarschijnlijk is dat ook nog de voornaamste rede om uberhaupt dit om te bouwen naar een centraal systeem. Je kan dan een SQLite server op gaan zetten, maar waarom zou je?

schakenraadjuh schreef op donderdag 17 januari 2013 @ 20:37:
2. De applicatie gaat benaderd worden vanaf verschillende locaties

[ Voor 10% gewijzigd door Zoijar op 19-01-2013 20:01 ]

[Foeijonghaai]

Verwijderd schreef op zaterdag 19 januari 2013 @ 19:11:
Omdat het aantal formules praktisch niets is, en het inrichten van een MySQL database server met dit doel teveel van het goede is. Een SQLite of zelfs BerkeleyDB is echt meer dan genoeg voor het opslaan van dit soort vormen van data.

- Ik ga ervan uit dat database enkele megabytes groot zal zijn met als maximum misschien zelfs 15 a 20 megabyte, als wij het daadwerkelijk hebben over een database met honderden aantallen aan formules.
- De database zal niet eens 50 bezoekers tegelijk in zijn algehele gebruik meemaken.

Waarom zou je een full featured database instance willen inrichten als een op-een-bestand-gebaseerde database oplossing, zoals SQLite, meer dan voldoende is gezien het bovenstaande En gezien het praktisch geen echte resources claimt en bijna dezelfde mogelijkheden heeft als MySQL?

En als je nou toch al een database-server hebt draaien in je omgeving? ;-)

Hmm, spuit 11. Zoijar was me voor.

[ Voor 1% gewijzigd door Foeijonghaai op 19-01-2013 20:51 . Reden: spuit11 ]

[eLScha]

Op dit moment staat het model al in Excel. Excel voldoet niet meer om meerdere redenen, waarbij de voornaamste reden is dat gebruikers op diverse fysieke locaties data in moeten voeren. Dit gebeurt nu nog door alle gebruikers een versie van het bestand te sturen en handmatig hun wijzigingen samen te voegen.

Het probleem van recursieve formules wat hierboven aangekaart werd is niet van toepassing. Dat is namelijk een wiskundig probleem en niet van toepassing op de manier van het opslaan van formules.

Grof gezegd zou het een soort van Excel online moeten zijn. Zijn hier bestaande library's voor?

[Verwijderd]

Zoals al eerder aangehaald: google docs?

[Verwijderd]

schakenraadjuh schreef op maandag 21 januari 2013 @ 00:05:
...

Het probleem van recursieve formules wat hierboven aangekaart werd is niet van toepassing. Dat is namelijk een wiskundig probleem en niet van toepassing op de manier van het opslaan van formules.

Grof gezegd zou het een soort van Excel online moeten zijn. Zijn hier bestaande library's voor?

Ik had dit probleem aangekaart omdat het ook zo expliciet stond toeglicht in de OP. Het was niet de bedoeling om het topic zo offtopic te slingeren.

Om toch ook nog even inhoudelijk op je eerste vraag te antwoorden, dat schema bereikt prima wat je er mee wilt doen. Als alternatief voor de 'types' tabel zou je ook een enumeration kunnen gebruiken om he type aan te duiden.

M.b.t. tot je laatste vraag hebben Pedorus en Yexo Google Docs al voorgesteld en sluit ik me daarbij aan.

[Bigs]

Misschien moet je niet vanuit de bestaande spreadsheet denken, maar onderzoeken wat nu echt het probleem is en daar een passende oplossing voor zoeken. Ik denk niet dat je van het plan wat je nu voorstelt echt gelukkig gaat worden om de redenen die hierboven al aan worden gegeven.