Klanten database maken

Status
Niet open voor verdere reacties.
Het is niet zo offtopic denk ik, het is onderdeel van het probleem wat de TS heeft; hoe sla je de bestanden goed op.

Elke klant kan prima zijn eigen directory hebben, zonder dat een mens de structuur hoeft te zien. Het punt is ook niet wel / geen database maar het neerzetten van de fysieke files voor algemeen beheer.

Het beheer wordt gedaan door een applicatie dus er is geen reden om de structuur mensvriendelijk op te zetten. Het kan wel, maar als je daardoor een map krijgt met 10.000 submappen dan heb je een probleem.


Als ik dus een file ophaal uit: '/fotos/klanten/klant500/' is dat nauwelijks beinvloed door het feit dat er veel andere subdirs in "klanten" zijn.

Als je één bestand ophaalt niet nee, maar er gebeurt meer met die bestanden. De backup procedure bijvoorbeeld, virusscanners, quotatellers, een simpele 'ls'.


Je kunt nu eenmaal niet ongestraft zoveel bestanden in een map proppen als je wilt. Ik had ook liever gehad dat het wel kon, maar zodra je in de duizenden komt moet je al gaan nakijken welke libraries je tools gebruiken om te voorkomen dat ze vastlopen in het grote aantal nodes.
 
Dus... Met mijn oplossing heb je dat probleem niet ^,^

Jouw oplossing eindigt met:

Zo hoef je maar 1 mapje te hebben.

Dus jij gaat het probleem nog veel eerder merken dan met Wampier's oplossing, hij deelt de foto's nog op in mapjes per user, jij zet alles in dezelfde map...
 
En als we nou even alles lezen in plaats van alleen 1 regeltje zien we dat je via een database alleen bepaalde gebruikers de foto kunnen zien. De users gaan (lijk mij dan) niet in de mappenstructuur bladeren om hun foto te vinden.
 
En als we nou even alles lezen in plaats van alleen 1 regeltje zien we dat je via een database alleen bepaalde gebruikers de foto kunnen zien. De users gaan (lijk mij dan) niet in de mappenstructuur bladeren om hun foto te vinden.

De gebruikers niet, jij wel al dan niet via PHP (bv. om te kijken welke foto's wel en niet op disk staan), locate wel, find wel, en daarmee ook de backup wel. En de backup is toch redelijk belangrijk.

Ik zeg dit allemaal ook niet om interessant te doen, dit soort dingen gebeuren in de praktijk gewoon, google er voor de grap zelf ook eens naar, ipv vol te houden dat jij vindt dat het niet zo is.
 
Ik snap niet echt wat je bedoeld?
Dat je kan kijken wat een user kan zien ofzo?

Ik bedoel het dagelijkse beheer. Jij wilt als beheerder wel gewoon bij die bestanden kunnen omdat jij bijvoorbeeld moet kunnen controleren wat er mis is als een gebruiker zegt dat zijn bestand niet goed doorkomt. Als je *dat* bestand oproept en het is leeg, dan wil je ook kunnen zoeken of dat met nog meer bestanden is gebeurd, en dat kun je dus botweg niet als het er teveel zijn.
 
Je kan ook wel een mooi php scriptje maken om dit soort dingen te controleren. Je kan het zelfs zo maken dat het dmv van een cronjob een mailtje krijgt als er bestandjes verdwenen zijn.
 
Je kan ook wel een mooi php scriptje maken om dit soort dingen te controleren. Je kan het zelfs zo maken dat het dmv van een cronjob een mailtje krijgt als er bestandjes verdwenen zijn.

Je kunt alleen scripts schrijven voor de situaties die je kunt voorspellen. Ik weet niet hoe goed jouw glazen bol is, maar de fouten die ik zie gebeuren in websites en applicaties zijn steevast volslagen onverwacht, in code waarvan ik nooit had gedacht dat dat een probleem zou opleveren. En dat is logisch natuurlijk want als ik weet dat iets een probleem kan zijn dan bouw ga ik een andere manier bedenken zodat ik dat probleem alvast voorkomen heb.

Op het moment dat de poep begint te vliegen moet je kunnen vertrouwen op het gereedschap wat je hebt en als je dan een directorylisting op wilt vragen moet dat gewoon werken, en je wilt er natuurlijk tijdens een panieksituatie al helemaal neit achterkomen dat je backup al een paar weken de helft van je bestanden heeft overgeslagen omdat hij niet op tijd antwoord kreeg van het fileystem.


Maargoed, terug naar het topic: in een geautomatiseerd upload/gallery systeem maakt het helemaal niet uit hoe de bestanden opslaat want vanuit de gebruikerskant wordt alles door de applicatie geregeld. Bij gevolg is het dus niet nodig om mapjes per klant te maken, al is dat wel erg overzichtelijk voor jou als beheerder. Echter, als er een kans bestaat dat er tienduizenden klantenmapjes in dezelfde hoofdmap komen dan moet je daar maatregelen tegen nemen. In de echt grote systemen is het niet ongebruikelijk om mappen op alphabet te maken: a/aa, a/ab, a/ac, .... /z/zy, z/zz. Zo hebben de eerste twee lagen slechts 26 mappen elk, en deel je het aantal nodes dat in de uiteindelijke map staat door26*26= 676, dus als je dan 100.000 nodes in totaal hebt, en de verdeling is een beetje normaal, dan heb je slechts 147 nodes per map.
Zelf heb ik veel pret gehad aan een simpele regexp om het bestand met id=14573864 neer te zetten in map /14/573/864, en zo weer maximaal duizend subnodes per node te hebben. Dit is gelijk ook makkelijk om een node te vinden als je het id weet.
 
Maar die codes schrijven is misschien 5 minuten werk.
Gewoon even uit interesse, wat zou er dan voor iets onverspelbaars kunnen gebeuren?
 
Maar die codes schrijven is misschien 5 minuten werk.
Gewoon even uit interesse, wat zou er dan voor iets onverspelbaars kunnen gebeuren?

Hoe ga je in vijf minuten een script schrijven dat helpt met het de debuggen van een probleem waarvan je niet eens wist dat het op zou kunnen treden?

Dat is de pest van onvoorspelbare problemen; ze zijn niet te voorspellen.

Stel dat een klant belt en zegt dat zijn bestand niet goed doorkomt, dan ga jij als eerste via SSH je server in om te kijken of dat bestand op disk te vinden is; je doet een ls en die loopt vast, elke keer. En nu? Ga je dan een script schrijven? Nee, want ls is de meest elementaire manier om bestanden uit te lijsten en als dat niet meer werkt waarom zou een script dan wel werken? Dus je gaat een paar andere tools proberen en die lopen allemaal stuk voor stuk vast, je belt je hoster, en als je geluk hebt dan kom je er dezelfde dag nog achter dat er teveel bestanden zijn. Vervolgens ga je het aantal bestanden terugbrengen door een aantal te verplaatsen met "mv 1* submap/" en dat faalt want er zijn veel te veel bestanden waarvan de naam begint met een '1', en ja, tegen die tijd ben je misschien zover dat je een scriptje kunt gaan riskeren, maar dan zit je op je liverserver te klieren en daar wil je graag heel zeker zijn dat je de bestanden heel houdt, dus je bent wel even bezig.
 
Status
Niet open voor verdere reacties.
Steun Ons

Nieuwste berichten

Terug
Bovenaan Onderaan