Content gebaseerd op domeinnaam

[Geerrrt]

Voor een systeem maken wij gebruik van meerdere domeinnamen. Deze zijn vastgelegd in de database. Voor deze case gaan we even uit van het volgende:

• a.com (Database id = 1)
• b.com (Database id = 2)
• c.com (Database id = 3)

Als een bezoeker a.com bezoekt, moet hij natuurlijk de content van domein A te zien krijgen. Dat lukt allemaal wel. Maar wat is nu de beste manier om te bepalen, op welke site deze bezoeker zit, en het systeem zo min mogelijk belast?

Ik had zelf al de volgende opties uitgedacht:

1. Je kunt bij ieder bezoek de domeinnaam vergelijken met je database en aan de hand daarvan de juiste content inladen, maar dan heb je ieder bezoek een extra query. Wil je dit wel?
2. Een andere optie is om bij je 1e bezoek. 2 Variabelen vast te leggen in je sessie/cookie. De domeinnaam, en de id. Als je de volgende keer dan bezoekt, en je domeinnaam is anders als je sessie/cookie. Kun je de database id opnieuw berekenen. Zo belast je de database maar 1 x per bezoeker.

Een case/if statement is imo geen goede optie. Want iedere keer als je een domeinnaam toevoegt moet je je code aanpassen.

Hoe zouden jullie dit geval oplossen?

[Kettrick]

Als je echt geen query wil doen kan je het mogelijk via je webserver configuration oplossen, door bijvoorbeeld een env var te configureren.

Ik zou me overigens helemaal niet druk maken om een query meer of minder, mocht die query echt te vaak uitgevoerd worden kan je het altijd nog in een lokale cache duwen.

[Kalentum]

Inderdaad zal het qua queries wel mee vallen.

Maar ik zou optie 2 doen. Dus 1x opvragen van id, daarna opslaan in de sessie. Hoe is je sessiemanagement geregeld? Meestal werkt dat op basis van een cookie met een sessie id en die is sowieso aan de host- of domeinnaam gekoppeld dus die check op domeinnaam kun je overslaan.

[Geerrrt]

Het is inderdaad maar één simpele select query. Maar stel je hebt 1000 bezoekers per dag, scheelt het toch al weer 1000 queries.

[dcm360]

Ehm, ja, een query duurt misschien een paar milliseconden? Zeker 'simpele' queries hoef je niet bepaald weg te bezuinigen, daar kan een database prima mee overweg.

[Sebazzz]

Je zoekt naar het woord 'multi-tenancy'. Ayende Rahien heeft een goede blogserie hierover.

[TheNephilim]

Je kunt toch een tabel met domeinen maken; id, name. Dan domain.name vergelijken met wat $_SERVER['HTTP_HOST'] en/of $_SERVER['SERVER_NAME'] teruggeven. Alle content kun je koppelen aan domain.id en die meenemen in je queries.

Maar misschien zie ik wat over het hoofd ofzo, of denk ik te simpel.

[Geerrrt]

TheNephilim schreef op woensdag 22 oktober 2014 @ 14:48:
Je kunt toch een tabel met domeinen maken; id, name. Dan domain.name vergelijken met wat $_SERVER['HTTP_HOST'] en/of $_SERVER['SERVER_NAME'] teruggeven. Alle content kun je koppelen aan domain.id en die meenemen in je queries.

Maar misschien zie ik wat over het hoofd ofzo, of denk ik te simpel.

Het juiste id bij de juiste domeinnaam vinden is het probleem ook niet. Zoals je kan zien heb ik daar ook al diverse oplossingen voor. Maar het gaat me in dit geval om de best-practice oplossing.

[ Voor 12% gewijzigd door Geerrrt op 22-10-2014 15:15 ]

[Gomez12]

GeertJam schreef op woensdag 22 oktober 2014 @ 15:14:
[...]
Het juiste id bij de juiste domeinnaam vinden is het probleem ook niet. Zoals je kan zien heb ik daar ook al diverse oplossingen voor. Maar het gaat me in dit geval om de best-practice oplossing.

Hoe bedoel je "best practice oplossing"? Ik zie het hele probleem eigenlijk niet.

Je gooit in je sessie je db-id vast. Mits je geen vage constructies qua sessies etc hebt zal een normaal sessie-beheer systeem gewoon een nieuwe sessie starten als de bezoeker op een nieuw/ander domein binnenkomt.

Dan heb je het over 1 query per bezoeker per browser per domein per sessieduur, oftewel totaal verwaarloosbaar.
En ja, dat betekent 1000 query's bij 1000 unieke bezoekers per dag, Maar als al die bezoekers 10 pagina's doorklikken dan heb je 0 extra query's. Terwijl je waarschijnlijk voor het ophalen van je content (met 1 content-query per pagina) al zit op 10.000 query's.

Je genoemde optie 1 is wmb dan ook pure overkill, dat handelt iedere browser / web-server / scripttaal al af door sessies.
Optie 2 is het weer overbodig om je domeinnaam op te slaan, want wederom dat doet je sessie-beheer systeem als het goed is.

Applicatie technisch is het totaal niet relevant op welke site iemand zit, enkel welke dbase deze nodig heeft. Om te bepalen welke dbase iemand nodig heeft kan je eenmalig een query doen op basis van site maar daarna is de site niet meer relevant.

[MSalters]

Het meest vreemde aan dit hele idee is de veronderstelling dat het bewaren van gegevens in sessies efficienter is dan het bewaren van gegevens in databases ! Ergens mis je dan het hele doel van databases.

Toegegeven, het is natuurlijk niet handig hoe er hier met databases wordt gewerkt. Domeinnamen zijn uniek, en dus geschikt als keys in een database. Kunstmatige database ID's zijn niet handig.

[Gomez12]

MSalters schreef op donderdag 23 oktober 2014 @ 22:25:
Het meest vreemde aan dit hele idee is de veronderstelling dat het bewaren van gegevens in sessies efficienter is dan het bewaren van gegevens in databases ! Ergens mis je dan het hele doel van databases.

Toegegeven, het is natuurlijk niet handig hoe er hier met databases wordt gewerkt. Domeinnamen zijn uniek, en dus geschikt als keys in een database. Kunstmatige database ID's zijn niet handig.

Ehm, is mijn sarcasme detector stuk oid?

Sessies (zolang ze niet db-backed zijn dan) zijn in elke taal die ik ken efficienter dan een db (mits het om extreem kleine (<10 values) hoeveelheden data gaat)

En domeinnamen als db-identifier? Persoonlijk zou ik ofwel database-namen pakken of gegenereerde id's, maar ik zie totaal niet in wat de domeinnaam ermee te maken heeft, dan besluit marketing dat het handiger is om een .com te hanteren als een .nl en dan mag jij je routines gaan aanpassen? Houd het gewoon of op nietszeggende id's of op namen waar je 100% controle over hebt (database namen).

[Tribits]

GeertJam schreef op woensdag 22 oktober 2014 @ 12:06:
Ik had zelf al de volgende opties uitgedacht:

1. Je kunt bij ieder bezoek de domeinnaam vergelijken met je database en aan de hand daarvan de juiste content inladen, maar dan heb je ieder bezoek een extra query. Wil je dit wel?
2. Een andere optie is om bij je 1e bezoek. 2 Variabelen vast te leggen in je sessie/cookie. De domeinnaam, en de id. Als je de volgende keer dan bezoekt, en je domeinnaam is anders als je sessie/cookie. Kun je de database id opnieuw berekenen. Zo belast je de database maar 1 x per bezoeker.

Loop je met optie twee niet het risico dat de gebruiker de database ID (client side) aanpast en op die manier in staat is om sites op te vragen die bijvoorbeeld nog niet live zijn? Misschien is het geen issue voor dit systeem maar ik kan me indenken dat het in bepaalde gevallen onwenselijk is.

[Ramon]

GeertJam schreef op woensdag 22 oktober 2014 @ 13:18:
Het is inderdaad maar één simpele select query. Maar stel je hebt 1000 bezoekers per dag, scheelt het toch al weer 1000 queries.

1000 queries is niets. Ik heb sites gezien waar op sommige pagina's 400~500 queries gedaan worden, en de pagina staat er nog steeds binnen de seconde. Doe dat nou maar, hiervoor sessies gebruiken is nutteloos en je maakt het jezelf alleen maar moeilijker.

Tribits schreef op donderdag 23 oktober 2014 @ 23:11:
[...]


Loop je met optie twee niet het risico dat de gebruiker de database ID (client side) aanpast en op die manier in staat is om sites op te vragen die bijvoorbeeld nog niet live zijn? Misschien is het geen issue voor dit systeem maar ik kan me indenken dat het in bepaalde gevallen onwenselijk is.

Met sessies kan je geen data aanpassen.

[Tribits]

Ramon schreef op donderdag 23 oktober 2014 @ 23:14:

[...]
Met sessies kan je geen data aanpassen.

Ik doelde eigenlijk op het aanpassen van een database id die in een cookie op wordt geslagen, maar goed, dat gaat voor sessie cookies inderdaad niet op, my bad.

[ Voor 16% gewijzigd door Tribits op 23-10-2014 23:36 ]

[dynast]

Ik zou gebruikmaken van een prefix voor je database-naam doen en deze laten corresponderen met het betreffende domeinnaam met bijv. $_SERVER['SERVER_NAME'].
In je configfile die overal geïnclude word moet 1x de mysql use query toepassen (liefst met pdo als je php gebruikt).
Ik zou niet gaan werken met een aparte tabel met een extra select waar je de domeinen in gaat bijhouden, tenzij het er bijv. meer dan 10 zijn ofzo.
Misschien dat wanneer je een fatsoenlijk framework gebruikt je makkelijke meerdere environments kan definiëren hiervoor.

Ga alsjeblieft hiervoor niet met sessions of cookies oid werken.

[Ramon]

Tribits schreef op donderdag 23 oktober 2014 @ 23:19:
[...]


Ik doel op het aanpassen van de database id die in de sessie cookie op wordt geslagen, niet op database updates.

Snapte ik. Alleen wordt er in een sessie cookie geen data bewaard, afgezien van een unique id die verwijst naar een server-side storage (de sessie) waar de database-id opgeslagen zou kunnen worden. Je kan dus niet zomaar de waarde "database-id" veranderen.

[Gomez12]

Ramon schreef op donderdag 23 oktober 2014 @ 23:26:
[...]

Snapte ik. Alleen wordt er in een sessie cookie geen data bewaard, afgezien van een unique id die verwijst naar een server-side storage (de sessie) waar de database-id opgeslagen zou kunnen worden. Je kan dus niet zomaar de waarde "database-id" veranderen.

En al ga je met cookies werken en kan de gebruiker het aanpassen dan is er nog pas iets aan de hand als je backend het ook vrijgeeft, als het backend het niet vrijgeeft dan is er nog niets aan de hand.

[TheNephilim]

Gomez12 schreef op vrijdag 24 oktober 2014 @ 02:08:
[...]

En al ga je met cookies werken en kan de gebruiker het aanpassen dan is er nog pas iets aan de hand als je backend het ook vrijgeeft, als het backend het niet vrijgeeft dan is er nog niets aan de hand.

Waarom zo moeilijk doen met sessies of cookies? Gewoon het domeinnaam direct laten corresponderen met de database en/of gegevens erin. Domeinnaam is leidend, een sessie of cookie er bovenop gooien maakt het alleen maar foutgevoeliger.

[creator1988]

Wat een non-discussie dit. Je wil nooit teveel queries doen, dus gooi die lookup table in je cache en klaar.

[MSalters]

Gomez12 schreef op donderdag 23 oktober 2014 @ 22:51:
[...]
Sessies (zolang ze niet db-backed zijn dan) zijn in elke taal die ik ken efficienter dan een db (mits het om extreem kleine (<10 values) hoeveelheden data gaat)

Zulke kleine hoeveelheden data eindigen in de RAM cache van een database. En daar is de data bovendien gedeeld tussen alle gebruikers, zodat ook het eerste bezoek van een gebruiker snel is.

Dus ja, de database is efficienter.

creator1988 schreef op vrijdag 24 oktober 2014 @ 10:13:
Wat een non-discussie dit. Je wil nooit teveel queries doen, dus gooi die lookup table in je cache en klaar.

Nog beter idee: gooi de lookup tabel in een database die het cachen voor je doet. Databases zijn goed met tabellen.

[ Voor 25% gewijzigd door MSalters op 24-10-2014 10:40 ]

[Soultaker]

Heerlijke bikeshed-discussie dit.

MSalters schreef op vrijdag 24 oktober 2014 @ 10:38:
Zulke kleine hoeveelheden data eindigen in de RAM cache van een database. En daar is de data bovendien gedeeld tussen alle gebruikers, zodat ook het eerste bezoek van een gebruiker snel is.

Een round-trip naar de database is natuurlijk nooit sneller dan een lokale lookup. Maar ik denk niet dat het praktisch gezien veel uitmaakt.

De oplossing met het domein in je sessie opslaan is ook een vorm van caching, trouwens. Dat kun je dus altijd nog doen als je tijd wil besparen.

[Firesphere]

TheNephilim schreef op vrijdag 24 oktober 2014 @ 10:05:
[...]


Waarom zo moeilijk doen met sessies of cookies? Gewoon het domeinnaam direct laten corresponderen met de database en/of gegevens erin. Domeinnaam is leidend, een sessie of cookie er bovenop gooien maakt het alleen maar foutgevoeliger.

Dit. Heb ik ook gedaan verschillende keren.

gewoon per domein een config-bestand. En dan bij bezoek aan a.com, de a.conf includen. Bij b.com, include je b.conf, etc.

Makkelijkste en meest overzichtelijke manier.