Hem
Forum
Donera
Webbutik

Översikt
Nya inlägg
Obesvarade trådar
Sök i forum

Mjukvara och tjänster
Programmering och utveckling

Multi-site - Tabellstruktur

Tråden skapades 2007-11-13 och har fått 9 svar. Det senaste inlägget skrevs 2007-11-20.

2007-11-13 14:26

Knutsson
Medlem ●
Tanum
2007-11-13 14:26

Jag håller på och bygger webbverktyg som skall hantera ett antal webplatser (i detta fall 10 st med olika domäner) och alla skall utgå ifrån samma "skriptuppsättning" så att säga. Från Admin-gränssnittet skall du kunna hantera alla tio webbplatserna.
Frågan är hur jag skall lägga upp tabellstrukturen.
Skall jag ha EN uppsättning tabeller där data från alla siter lagras, (med ett fält site_id) eller skall jag ha en uppsättning tabeller per site. typ site1_content, site2_content osv.
En tabell skall vara global, dvs. samma tabell för alla siter.

Hur skall jag tänka?

Prestanda mm... ?

Anmäl Ändra Gilla Svara

2007-11-13 17:36

irrelogical
Medlem ●
Göteborg
2007-11-13 17:36

Det här är nog lite över min nivå, men det blir lättare att göra saker som att flytta innehåll mellan sajter, ha någon form av gemensam moderering/hantering och sånt om man kör med gemensamma tabeller. Dessutom, om du av någon anledning behöver ändra databasschemat så räcker det med att göra det en gång istället för att göra det för varje sajt. Att det blir lättare att lägga till en sajt är ett plus med.

Anmäl Ändra Gilla Svara

2007-11-13 18:50

sebastian_r
Medlem ●
Stockholm
2007-11-13 18:50

Håller med om att de inte bör ligga i olika tabeller. Möjligen i olika databaser om du vill lättare kunna flytta en domän till annan server eller liknande. Att lägga in ett fält för att identifiera domän ska inte påverka prestanda nämnvärt, däremot blir koden något mer komplex att skriva. Så mitt förslag är att om du inte har möjlighet att skapa flera databaser(t.ex. vissa webhotell tillåter inte det) så borde du lägga siterna i separata databaser. Får du problem med prestanda är det bättre att titta på om du kan cacha data för att öka prestanda och respons-tider. Gör du komplexa frågor gentemot databasen är index och vyer något att titta på.

Anmäl Ändra Gilla Svara

2007-11-13 18:52

ninjamac
Medlem ●
Malmö
2007-11-13 18:52

en databas per sajt tycker jag. Men det beror ju lite på hur du bygger. Har en sådan lösning själv, funkar (mycket förenklat) så här:

En databas som hanterar åtkomst, uppgifter för respektive databas, val av domän, sökvägar, etc.

En databas med sådana saker som är (och alltid förväntas vara) gemensamma för alla sajter. Denna är ju bara nödvändig under vissa omständigheter, beror ju på projektets egenheter.

En databas per sajt - en del av dem ligger lokalt, andra remote.

Anmäl Ändra Gilla Svara

2007-11-13 18:53

sebastian_r
Medlem ●
Stockholm
2007-11-13 18:53

Ville lägga till att om du behöver göra frågor som berör flera sidor samtidigt kan det iofs förenkla om du lägger alla sidor i samma databas. T.ex. besökarstatistik m.m

Anmäl Ändra Gilla Svara

2007-11-13 19:29

ninjamac
Medlem ●
Malmö
2007-11-13 19:29

Om det inte redan står klart för dig:
Query till flera databaser:

anslut till flera: (persistent connections)
$dbh1 = mysql_pconnect($host,$user,$pass);
$dbh2 = mysql_pconnect($host,$user,$pass);

du behöver inte göra mysql_select_db - gör query så här:
mysql_query("SELECT * FROM database1.table",$dbh1);
mysql_query("SELECT * FROM database2.table",$dbh2);

Anmäl Ändra Gilla Svara

2007-11-14 19:40

sebastian_r
Medlem ●
Stockholm
2007-11-14 19:40

Menade att jag ville lägga till på mitt eget inlägg

Klart att man kan ansluta till flera databaser samtidigt(vissa plattformar gör det iofs svårare... t.ex. hibernate), däremot kan du inte i en fråga få svar från flera databaser samtidigt. Alltså en fråga kan inte spänna över flera databaser.

Det man istället får göra då är ju att själv slå ihop datan vart eftersom svaren trillar trillar tillbaka, vilket jag tyckte verkade jobbigt... Kanske bara är lat

Anmäl Ändra Gilla Svara

2007-11-14 23:02

ninjamac
Medlem ●
Malmö
2007-11-14 23:02

Nja, skulle väl inte gärna bygga så att man behöver göra motsvarande joins över flera databaser. Vad jag pratar om är inheritance där en rad ur en tabell kan hämtas från relevant databas. Säg att du har t ex en templates-tabell. I din default_db har du en komplett tabell med alla templates. I din client_db har du eventuella custom templates.
Ett exempel är nog enklast:

if(extract(mysql_fetch_array(mysql_query("SELECT Code FROM client_db.templates WHERE Name = '".$template[name]."'"))));
elseif(extract(mysql_fetch_array(mysql_query("SELECT Code FROM default_db.templates WHERE Name = '".$template[name]."'"))));
else $template[error] .= $template[name].' not found';
$template[code] = $Code;

Anmäl Ändra Gilla Svara

2007-11-19 20:37

Knutsson
Medlem ●
Tanum
2007-11-19 20:37

Tack för alla utförliga svar. Jag skall förtydliga min situation lite...
Systemet består just nu av i stort sett tre delar: Innehåll, Annonser och Platser.
Innehållet skall vara unikt för varje sajt.
Annonserna skall vara tillgängliga för alla sajter, då samma annons skall kunna finnas på flera sajter samtidigt. Annonserna kopplas till page_id i innehållstabellen för att veta vilka annonser som skall visas på vilka sidor.
"Platser" innebär små inlägg om olika platser som hör till respektive sajt, och dessa skall sedan visas i Google Maps, men när du tittar på Google Maps på sajt 1 skall du kunna se platser från sajt 2 och 3 etc...
Detta innebär att annonser och platser måste vara EN tabell för alla sajter, och just nu känns det som det blir enklast om innehållet för alla sajter ligger i en och samma tabell, och separeras med site_id.

Jag kör just nu sajterna på egen server men när det blir dags för skarpt läge är det förmodligen Loopia som gäller och där har vi EN databas som standard.

Anmäl Ändra Gilla Svara

2007-11-20 03:10

#10

ninjamac
Medlem ●
Malmö
2007-11-20 03:10

Du kan ju göra dig själv en tjänst och rent semantiskt planera/tänka och göra dina scheman som om det handlade om flera databaser. Att du sen i praktiken smäller ihop det under en db är egenligen inte av någon större konsekvens. För att vara extra tydlig kan du ju namna tabellerna med prefix, som t ex global_settings, global_ads, site_nisse, site_arne om du fattar hur jag menar.