[PHP] Pagination met pagina titels en bestandslimiet in map

[RS_Jelle]

Ik heb twee praktische vraagjes waarmee ik wordt geconfronteerd bij het scripten van een klein CMS.

Er zal een nieuwssysteem zijn, maar ook een systeem voor grotere artikels. Het concept is dus vergelijkbaar met het Reviews systeem van Tweakers.net en vele andere sites. De artikels moeten dus uit verschillende pagina's bestaan en elke pagina moet een titel krijgen.
Ik zie twee mogelijkheden:

1. Een tabel voor de artikels met hoofdtitel enzo en een aparte tabel voor alle pagina's en dan gewoon met JOIN werken.
2. Alles in één tabel en de tekst onderverdelen met merktekens zoals bv. <!-- newpage --> en dan nog een voor de titel. Dan met explode de boel splitsen en alles x2 voor de titel te splitsen.

Ik vond hierover dit oude onderwerp. Mij lijkt methode één de beste qua performance, optie twee lijkt me duidelijk intensiever. Maar daar ik optie twee na wat googlen zoeken met Google toch nog vrij veel tegenkwam begon ik wat te twijfelen. Momenteel staat alles op één server, dus het feit waar je juist vooral de load kan leggen speelt nog niet echt mee. Tips buiten dat oude topic zijn uiteraard altijd welkom.

Ten tweede moet de site ook een afbeeldingen beheersysteem krijgen. Hierbij sta ik voor het volgende praktische probleem: hoeveel bestanden kan ik uploaden naar een map (server draait op FC2, maar dat wordt binnenkort geüpgraded naar FC4, FC5 kan niet wegens incompatibiliteit met andere dingen)? Of beter: hoeveel is echt wenselijk, want er is een verschil tussen de theorie en de praktijk.
Ik vraag me dus af wanneer ik het best begin met een /hoofdmap/1/, /hoofdmap/2/, ... indeling bij het opslaan van de bestanden.
De afbeeldingen gaan uiteraard ook de database in om ze doorzoekbaar te maken op trefwoorden en dergelijke

Hiervoor kan je gemakkelijk zeggen dat het van het bestandssysteem afhangt en sommigen er dus meer aankunnen dan anderen en dat vind je gemakkelijk met Google. Ik ben dus echt meer geïnteresseerd in dit concreet geval in de praktijk.

[Soultaker]

RS_Jelle schreef op dinsdag 15 augustus 2006 @ 23:20:
Er zal een nieuwssysteem zijn, maar ook een systeem voor grotere artikels. Het concept is dus vergelijkbaar met het Reviews systeem van Tweakers.net en vele andere sites. De artikels moeten dus uit verschillende pagina's bestaan en elke pagina moet een titel krijgen.
Ik zie twee mogelijkheden:

1. Een tabel voor de artikels met hoofdtitel enzo en een aparte tabel voor alle pagina's en dan gewoon met JOIN werken.
2. Alles in één tabel en de tekst onderverdelen met merktekens zoals bv. <!-- newpage --> en dan nog een voor de titel. Dan met explode de boel splitsen en alles x2 voor de titel te splitsen.

Ik vond hierover dit oude onderwerp. Mij lijkt methode één de beste qua performance, optie twee lijkt me duidelijk intensiever.

Dat zou je denken, maar in de praktijk is het afhankelijk van hoeveel data er daadwerkelijk in je artikel zit (zijn het veel pagina's?). De tweede optie is beter genormaliseerd en schaalt dus beter, en ik zou ook zeggen dat 'ie netter is, maar ik kan me goed voorstellen dat de eerste optie voor artikelen met weinig pagina's (zoals op Tweakers.net bijvoorbeeld) gewoon sneller is omdat je maar één rij hoeft te vinden in de database.

Ik denk dat optie één vaak gebruikt wordt in systemen die oorspronkelijk geen ondersteuning hadden voor meerdere pagina's; seperators in de content stoppen is dan de snelste manier om die functie toe te voegen, omdat je er het databaseschema niet voor hoeft aan te passen. In die situatie is het dus geen bewuste keuze voor die optie op technische gronden. Als je het van de grond af opbouwt en je hebt de tijd om het goed te doen, zou ik zelf waarschijnlijk voor de tweede optie kiezen, vanwege de betere schaalbaarheid en normalisatie.

Ten tweede moet de site ook een afbeeldingen beheersysteem krijgen. Hierbij sta ik voor het volgende praktische probleem: hoeveel bestanden kan ik uploaden naar een map (server draait op FC2, maar dat wordt binnenkort geüpgraded naar FC4, FC5 kan niet wegens incompatibiliteit met andere dingen)? Of beter: hoeveel is echt wenselijk, want er is een verschil tussen de theorie en de praktijk.
[..]
Hiervoor kan je gemakkelijk zeggen dat het van het bestandssysteem afhangt en sommigen er dus meer aankunnen dan anderen en dat vind je gemakkelijk met Google. Ik ben dus echt meer geïnteresseerd in dit concreet geval in de praktijk.

Sorry, maar het komt toch neer op het gebruikte bestandssysteem, of de configuratie. Het is in dit topic al eens gesproken, en daar blijkt EXT2/3 er standaard een lineaire complexiteit op na te houden; dan kan het al heel snel uit om submappen te gebruiken. Ik heb daar ook mijn ervaring met UFS (FreeBSD) gepost, en die blijkt een logaritmische complexiteit te hebben wat er in de praktijk op neerkomt dat je praktisch een onbeperkt aantal bestanden kwijt kunt; dat zal met ReiserFS (wat in theorie een stuk beter ontworpen is dan EXT2/3) ook zo zijn.

Je kunt in EXT3 ook een directory index toevoegen (tune2fs -O dir_index, of chattr +I) om ook met EXT3 logaritmische performance te krijgen. Nieuwe directory entries maken wordt dan wat trager, maar dat kan voor plaatjes (die vaak worden gelezen en veel minder vaak toegevoegd) zeker uit.

Concreet zou ik afraden submappen te maken als je de server waarop je het CMS draait beheert. Als het de bedoeling is om op 'standaard' systemen te deployen zonder iets aan te kunnen passen, is het waarschijnlijk slim om wél submappen aan te maken, omdat Linux hosts met standaard EXT3 partities vrij veel voorkomen.