ik heb een functie welke in een loop een bestand moet zoeken en dan includen in geval deze bestaat
if (file_exists(''.$folder.'/'.$accountid.'/'.$jaar.'/'.$maand.'/users/'.$id.'/'.$file.'')) {
echo ''.$folder.'/'.$accountid.'/'.$jaar.'/'.$maand.'/users/'.$id.'/'.$file.'<br>';
include(''.$folder.'/'.$accountid.'/'.$jaar.'/'.$maand.'/users/'.$id.'/'.$file.'');
}
1 van de linken naar een bestand is
beheer/cache/45/2020/3/users/3/dag_13_03_2020.php
hij doet de echo dus het bestand bestaat
maar de include werkt echter niet
doe ik deze zelfde code nou op de pagina waar ik de functie opvraag dan doet hij het wel
dus zonder functie wel en met gebruik van een functie niet.
mag je geen files includen in een functie?
@ozzie
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.
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
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.
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
"en het zou dan 0,05 sec schelen op de hele maand berekening "
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
[size=xsmall]Toevoeging op 24/03/2020 02:53:44:[/size]
" 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.
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.
