[php/alg] meerdere sites+ db, 1 centraal forum/userauth

[kmf]

ik ben bezig met een flink project. Een globale indruk van dit project:

Ik wil een netwerk opzetten van eigen websites op een eigen subdomeinnaam. Elke website concentreert zich op 1 onderwerp en zal een eigen database hebben voor de content en whatever it needs.
Ik ben zelf een CMS aan het schrijven dat basis moet dienen voor elk van de websites.
Al deze websites zijn centraal verbonden aan 1 forum. Deze zit op een andere DB en heeft zijn eigen user authenticatiesysteem (login, register, session,etc).

Het is de bedoeling dat een user registreert op de forum en dan ook voor alle websites tegelijkertijd geregistreerd staat. Inloggen op de forum zorgt ook voor dat de user voor alle websites is ingelogd met alle nodige rechten.

Wat ik met dit topic wilt verkrijgen is advies over het efficient opzetten van dit project en dan met name over het verbinden van de sites.

Wat is namelijk het probleem?

Hoewel de sites gebruik maakt van mijn eigen CMS, en dus dezelfde klasses, zijn ze structureel toch net wat anders. Het ene is een listing, een andere een niewssysteem, etc.
Ik zit nu dus voor elk website afzonderlijk een CMSje te bouwen waarvan 70% met elkaar overeenkomt. Ik werk al met classes (die meer een functiecontainer zijn), en templates, maar ik moet toch elke keer weer een afzonderlijke switchactie opzetten terwijl elk van deze toch op elkaar lijkt "show list","show item","add item","save item","edit item".
Hoe kan ik zodanig werken dat ik niet dubbel werk zit te doen?

Het andere probleem is natuurlijk de centrale auth-systeem. Hoe kan ik ervoor zorgen dat het aantal connecties richting de forumdb minimaal kan blijven en toch gebruik maken van de usertabel daarin voor authenticatie en rechten?
Ik zit zelf te denken om eenmalig bij het inloggen een enorme array op te bouwen met alle rechten van de user voor alle websites te genereren en in de sessie te dumpen, een hashed password wordt dan in de cookie opgeslagen. Deze cookie en de sessie moeten dan vergeleken worden voor auth..
Probleem is dan de subdomeinen. Elke site zit op een ander subdomein, dus cookies werken niet helemaal lekker.

Iemand dus misschien mooie adviezen?

[LauPro]

Centrale authorisatie zou je met LDAP kunnen doen. Echter wanneer je onderling ook sessie-variabelen wil delen dan zul je deze in een database moeten stoppen en die elke keer weer uitlezen, kost je een extra query.

[djluc]

Ja, neem gewoon 1 database en maak een plugin-gebaseerd systeem. Wat jij wilt kan overigens ook met bestaande systemen zoals Typo3.

[kmf]

djluc schreef op zondag 27 februari 2005 @ 09:53:
Ja, neem gewoon 1 database en maak een plugin-gebaseerd systeem. Wat jij wilt kan overigens ook met bestaande systemen zoals Typo3.

Ik ben juist een eigen CMS aan het schrijven omdat plugin systemen zoals mambo niet genoeg zijn. En als ik 1 DB zal gebruiken, zal dat een DB zijn met 300-400 tabellen. Zal mijn table-cache leuk vinden..

[simon]

athlonkmf schreef op zondag 27 februari 2005 @ 10:47:
[...]


Ik ben juist een eigen CMS aan het schrijven omdat plugin systemen zoals mambo niet genoeg zijn. En als ik 1 DB zal gebruiken, zal dat een DB zijn met 300-400 tabellen. Zal mijn table-cache leuk vinden..

Dat is niet echt een verstandige aanpak. Als je je eigen CMS schrijft kun je dit wel fatsoendelijk normaliseren. Als je er maar voor zorgt dat elke site een id heeft, en je je data 'universeel' opslaat kun je een al omvattend cms bouwen met maar een paar tabellen.

[JHS]

Over het dubbelle werk: het lijkt me dat elke site in feite hetzelfde is. Je wilt op elke pagina een aantal items laten zijn, afhankelijk van in welke catagorie je bent. Je wilt afhankelijk van of er nog meer subitems zijn een overzicht laten zien. Schrijf dus daar een cms voor, en zo dat je al je acties simpel in een template kan opslaan. Je kan dan bijvoorbeeld de templates bij de index.php (of whatever) stoppen en dan steeds het cms aanroepen, of de templates centraal opslaan, en vanuit een site het cms aanroepen, die dan afhankelijk van de URL een template aanroept. Als je zoveel mogelijk html en texten in het cms vermijd, hoef je niet per site iets anders te doen .

En zoals Simon al zegt, normaliseer je tabellen gewoon. Neem bijvoorbeeld een tabel met daarin alle items met een parentid (of id's), een tabel met alle catagorieen, met een flag of dat de root is, er dus naar een template gezocht moet worden, en niet verder naar parents. En eventueel een koppeltabel tussen de items en de parents, als je een item in meerdere catagorieen wil stoppen.

Overigens doet Typo3 ongeveer precies wat je wil (en dat werkt toch net wat beter / geavanceerder dan mambo), alleen is het nogal een gedoe om te leren hoe je daarmee je pagina's en templates moet opbouwen .

Wat betreft de authenticatie: als die forumdatabase nu al zwaar belast is zou je in je database voor je sites ook een user tabel op kunnen nemen, desnoods alleen met username / password en eventueel sessionid('s) . Dan laat je bij het registreren / wijzigen gegevens naar twee databases schrijven en doe je eventueel met een cronjob eens in de zoveel tijd de data met elkaar controleren, en eventueel vanuit de primaire database inlezen. Je kan ook gewoon de forum database aanroepen, ik betwijfel of dat zo'n enorme load oproept, maar dat kan jij beter inschatten. Of een derde database opzetten met daarin alleen de user tabel, het lijkt me op zich beter info maar op één plaats op te slaan. Als de sites-database onderbelast is, zou je het forum ook je sites database kunnen laten aanroepen. Mogelijkheden genoeg dus .

Overigens zou ik niet een passwordhash opslaan, maar gewoon een sessionid, met je eigen auth systeem, of gewoon vanuit het sessie systeem van PHP

[djluc]

Overigens doet Typo3 ongeveer precies wat je wil (en dat werkt toch net wat beter / geavanceerder dan mambo), alleen is het nogal een gedoe om te leren hoe je daarmee je pagina's en templates moet opbouwen .

Dat is tegenwoordig wel veranderd. Als je nu op Typo3.org kijkt zie je een nieuwe ontwikkeling. De one-minute website. Dit is echt een goede ontwikkeling. Op basis van een HTML template kan je met enkele klikken een dynamische website in elkaar zetten.

[JHS]

djluc: dat is op zich wel een flinke vooruitgang ja . Wat het niet minder leuk maakt om zelf een CMS / framework te ontwikkelen . Alleen je weet wel waar je aan begint, en het zal qua snelheid niet snel opgewassen zijn tegen een proffessioneel CMS / framework, behalve als je zelf hele specifieke functies nodig hebt .

[alienfruit]

Zelf vind ik eZ Publish (php oplossing) erg interessant, hier kun je ook nieuwe "modules" aanmaken e.d.

[kmf]

JHS schreef op zondag 27 februari 2005 @ 11:10:
Over het dubbelle werk: het lijkt me dat elke site in feite hetzelfde is. Je wilt op elke pagina een aantal items laten zijn, afhankelijk van in welke catagorie je bent. Je wilt afhankelijk van of er nog meer subitems zijn een overzicht laten zien. Schrijf dus daar een cms voor, en zo dat je al je acties simpel in een template kan opslaan. Je kan dan bijvoorbeeld de templates bij de index.php (of whatever) stoppen en dan steeds het cms aanroepen, of de templates centraal opslaan, en vanuit een site het cms aanroepen, die dan afhankelijk van de URL een template aanroept. Als je zoveel mogelijk html en texten in het cms vermijd, hoef je niet per site iets anders te doen .

En zoals Simon al zegt, normaliseer je tabellen gewoon. Neem bijvoorbeeld een tabel met daarin alle items met een parentid (of id's), een tabel met alle catagorieen, met een flag of dat de root is, er dus naar een template gezocht moet worden, en niet verder naar parents. En eventueel een koppeltabel tussen de items en de parents, als je een item in meerdere catagorieen wil stoppen.

Dat is nou wel iets waar ik mee zat. In het begin had ik dit structuur gebruikt om te programmeren.
Category_category<--Category-->Cat_item<--item-->item_item

Zo kan ik zo'n beetje alle mogelijke sites opzetten in 1 DB. Musicdb, faqsystem, articles.

Maar ik ben daar snel weer van afgestapt omdat het zo'n abstract geheel wordt dat het qua onderhoud niet meer bij te houden is.

En dan al die joins dat ik moest doen om iets voor elkaar te krijgen wordt je ook niet vrolijk van. Niet te spreken over het gebrek aan referentiele integretiteitsregels bij mysql. Moet ik dus handmatig een cascading script optikken. 3 lagen is te doen, maar als het meer dan dat wordt wordt je ook beroerd van

Vandaar ook het idee om gewoon te splitsen naar sites. een simpele select is waarschijnlijk nog steeds sneller dan een select met een hoop joins.

Ik heb ook gemerkt dat 1 grote DB onder mysql minder prettig werkt dan een aantal losse. Die 500 tabellen is een schatting vanuit wat ik nu heb. 180 tabellen die door de forum, gallery en cms-scripts zijn aangemaakt.