Tijden veranderen
functie accepteert geen include
gij wil op basis van invoer in de database met aantallen consumpties en diensten de 'loonstrook ' van enkele 'zzpers' bepalen.
opbouw is echter geheel procedureel en zonder al te veel programmeerkennis neergezet. daardoor is het zo traag dat allerlei cache bestanden nodig zijn. naar nu blijkt, zijn dat dynamisch opgebouwde php scripts.
zie ook de andere topics van de laatste dagen
Ivo P op 23/03/2020 23:14:05:
waarom sla je dan de berekende DATA niet op in een DATAbase?
als er een reden zou zijn om de data in een file op te slaan, zou ik dan denken aan een file met data.
CSV of Json bijvoorbeeld
als er een reden zou zijn om de data in een file op te slaan, zou ik dan denken aan een file met data.
CSV of Json bijvoorbeeld
Was hier nog over aan het nadenken en precies dit, en dan zou ik die bestanden alleen on-demand bouwen, met behulp van de opgeslagen resultaten als een soort export-functie naar het gewenste formaat.
Volgens mij valt dat ook onder AVG, dat alles opvraagbaar moet zijn.
En als het nu een echte relationele database betrof, dan was het "recht op vergeten worden" ook een peuleschil: je verwijdert dan gebruiker X en alle informatie die hier aan vast geknoopt zit met sleutels wordt automatisch ook verwijderd.
Als het fundament van je applicatie (database) goed in elkaar zit, dan is er meestal een hele hoop (en op een eenvoudige wijze) mogelijk.
Gewijzigd op 24/03/2020 01:49:32 door Thomas van den Heuvel
Quote:
waarom sla je dan de berekende DATA niet op in een DATAbase?
het werd eerst ook via sql enzo gedaan, echter moest ik uit veiligheid altijd terug rekenen vanuit de bruto bedragen,
dus en sql was toen enorm groot,
omdat ik all alles in vars had staan heb ik dit toen omgebouwd naar een cache systeem
verschil was dan, dat als cache file bestond hij niet meer hoefde te rekenen
ik heb er toen inderdaad overnagedacht om inderdaad csv of json te doen maar met huidige code was tat veels te veel werk om daar exact zelfde uitkomst mee te krijgen
en het zou dan 0,05 sec schelen op de hele maand berekening
aangezien ik in toekomst toch alles goed wil gaan schrijven leek mij dat onnodig om dat te doen
ik ben helaas wegens een paar aanpassingen genoodzaakt het een klein beetje te tweaken zodat ik straks makkelijker de code delen kan herscripten in duidelijke taal en in php van nu
[/quote]
hoe vaak heb je nu gezegd dat je liever de halve oplossing nam dan een ddordachte omdat jouw oplossing voor nu werkte?
kostte toen 15 minuten minder werk misschien maar je hebt er haren ellende van
Toevoeging op 24/03/2020 02:53:44:
" in de toekomst goed wil schrijven "
je geeft wel 10x aan dat je echt niet zo iets raars als doordacht opbouwen wilt doen
laat staan nieuwe dingen als functies en classes gebruiken.
je plakt steeds een pleister en dat is dan dé oplossing.
maar als er 1 probleem niet was geweest, was een hele rij aan pleisters niet nodig: een goed fundament in de vorm van een database gebaseerd op een doordacht datamodel en relaties tussen tabellen.
maar daar wil je niet aan
Gewijzigd op 24/03/2020 09:39:57 door Ivo P
Ivo P op 24/03/2020 02:44:22:
je plakt steeds een pleister en dat is dan dé oplossing.
maar als er 1 probleem niet was geweest, was een hele rij aan pleisters niet nodig: een goed fundament in de vorm van een database gebaseerd op een doordacht datamodel en relaties tussen tabellen.
maar daar wil je niet aan
maar als er 1 probleem niet was geweest, was een hele rij aan pleisters niet nodig: een goed fundament in de vorm van een database gebaseerd op een doordacht datamodel en relaties tussen tabellen.
maar daar wil je niet aan
