ugrás a tartalomhoz

Permalink és ID visszakeresés

joed · 2009. Júl. 12. (V), 01.49
Sziasztok!

Gyakorlott fejlesztők véleményét szeretném kérni a következő problémában.
Egy CMS-t fejlesztek és szeretnék permalink alapú oldal elérést. Az lenne a kérdésem, hogy ha a permalink-ből nem lehet egyedileg meghatározni a megjelenítendő tartalmat, ti milyen eljárást használtok. A problémám pl: http://siteom.hu/blog/majusi_kirandulas_bakony ami a http://siteom.hu/index.php?modul=blog&id=234. Az ID az adatbázisban tárolt oldal/tartalom kulcsa. A "majusi_kirandulas_bakony" string és a 234 között ugye nincs egyértelmű leképzés. Hogy a megfelelő tartalmat tudjam megjeleníteni az egyes permalinkekhez, vagy a táblában tárolom az egyes tartalmakhoz a hozzájuk tartozó permalinket vagy egy külön katalógust használok a permalink=>ID/kulcs megfeleltetésekhez. Az előbbit szeretném elkerülni, mert nem akarok egy ekkora mezőre indexet építeni, tekintve, hogy sokezer rekord lesz a táblában. És ha minden egyes oldalletöltésnél plusz egy lekérdezést le kell futtatni, már nem tartom annyira jó ötletnek.

A külön katalógusra a következőt találtam ki. Készítek egy PHP tömböt a permalink=>ID hozzárendelésekhez, amit a permalinkek kezdőbetűi alapján széttördelek és külön fájlokba teszem őket.

Például:
permalinkek:
a_sotet_ejszaka
az_elveszett_frigylada_fosztogatoi
Azur_kek_tenger
bachelor_of_arts
barbie_es_ken
barracuda
bukaresti_mese

A tömb:

<?php
$pl['a_']['a_sotet_ejszaka'] = 254;
$pl['az']['az_elveszett_frigylada_fosztogatoi'] = 563;
$pl['az']['azur_kek_tenger'] = 32;
$pl['ba']['bachelor_of_arts'] = 768;
$pl['ba']['barbie_es_ken'] = 31;
$pl['ba']['barracuda'] = 34;
$pl['bu']['bukaresti_mese'] = 3466;
?>
Ezt megfelelően külön fájlokba szétdobva:

<?php
/**
  * pl__a.inc.php
  */
$pl['a_']['a_sotet_ejszaka'] = 254;
?>

<?php
/**
  * pl_az.inc.php
  */
$pl['az']['az_elveszett_frigylada_fosztogatoi'] = 563;
$pl['az']['azur_kek_tenger'] = 32;
?>

<?php
/**
  * pl_ba.inc.php
  */
$pl['ba']['bachelor_of_arts'] = 768;
$pl['ba']['barbie_es_ken'] = 31;
$pl['ba']['barracuda'] = 34;
?>

<?php
/**
  * pl_bu.inc.php
  */
$pl['bu']['bukaresti_mese'] = 3466;
?>
Így a permalink és annak első két betűjének ismeretében mindenféle adatbázis vagy bonyolultabb művelet nélkül hozzájutunk a kulcshoz/ID-hez:

<?php
/**
  * http://siteom.hu/blog/barbie_es_ken => http://siteom.hu/index.php?plink=barbie_es_ken
  */
$part = $_GET['plink'][0].$_GET['plink'][1];
include 'pl_' . $part . '.inc.php';
$ID = $pl[$part][$_GET['plink']];

/**
  * További műveletek, lekérdezések stb.
  */
?>
Hátránya, hogy include-olni kell és időről-időre optimalizálni/aktualizálni kell a tömböt. Előnye, hogy lényegesen kevesebb erőforrást mozgat meg mint egy adatbázis lekérdezés. A tömbök mérete sem lesz soha túl nagy, hiszen ha túl sok permalink kerülne egy tömbbe, megnövelhetjük a használt kezdőbetűk számát és máris századára csökken a tömb mérete. Arra is gondoltam, hogy memcached-be is lehetne tenni a tömböt.

Mennyire érdemes tehermentesíteni az adatbázist? Túlzás ez, túlreagálom a problémát? (Nagy (10 000 + / nap) látogatottsággal kell számolni)

Vélemények, ötletek, tapasztalatok?

Előre is nagyon köszönöm.
 
1

Adatbázis index

Rici · 2009. Júl. 12. (V), 08.47
Túlbonyolítod a dolgot, pont erre találták ki az adatbázis indexeket. Nem kell félni attól, hogy egy sztring oszlopon van index. Plusz lekérdezés nem tudom, hol jön be a képbe, nyilván úgy kell megírni a lekérdezést, hogy ne a permalinkről az id-re, majd az id-ről a tartalomra képezz le, hanem egyből a permalinkről a tartalomra.

Lehet hogy a te megoldásoddal az adatbázist minimálisan tehermentesíted, de az összteljesítmény és a karbantarthatóság szinte biztos, hogy rosszabb lesz.
2

csatlakozom

thgab · 2009. Júl. 12. (V), 09.37
az előttem szólóhoz. A permalinknek úgyis egyedinek kell lennie, tárold az adatbázisban, és rögtön tudsz rá keresni. A legjobb ha a bejegyzés címéből képzed.
3

Szerintem simán mehetne az id

duplabe · 2009. Júl. 12. (V), 10.19
Szerintem simán mehetne az id is az url-be. A fenti példával: http://siteom.hu/blog/234/majusi_kirandulas_bakony. Szépnek így is szép az url, keresőbarát is, és egyszerűbb is a tartalom keresése.
6

+1

Török Gábor · 2009. Júl. 12. (V), 19.43
Ezt a koncepciót már egyre több helyen alkalmazzák, és szerintem is best of both worlds. Továbbá ezt az elgondolást még lehet annyival bővíteni, hogy a http://siteom.hu/blog/234/majusi_kirandulas_bakony mellett a http://siteom.hu/blog/234/ URL-re is kiadd ugyanazt a tartalmat (például egy 301-es átirányítással vagy canonical megjegyzéssel, hogy a duplikátumot elkerüld).
4

Megoldások

vbence · 2009. Júl. 12. (V), 10.59
Eleve rossz megközelítés, ha PHPben valami rendszerközeli logikát szeretnél megépíteni. Nem erre való.

Az azonosítót tárolhatod a blogbejegyzés mellett (ami a címvől származik), ilyenkor viszont ki kell találj vlami mechanizmust ami garantálja az egyediséget (mi van ha 3 évvel ezelőtt volt már egy azonos című bejegyzés)?

Duplabe javaslata egyszerübben implementálható. Én hosszú ideje használom ezt a módszert. Nálam kb így nézne ki:
http://siteom.hu/b234-majusi-kirandulas-bakony

A "blog" szó nem hordoz információt, és így előbbre kerülnek az értékes kifejezések, a gugli szavak elválasztására a - karaktert ajánlja az aláhúzással szemben...
8

a gugli szavak elválasztására

Török Gábor · 2009. Júl. 16. (Cs), 10.54
a gugli szavak elválasztására a - karaktert ajánlja az aláhúzással szemben…

Már az aláhúzás is egyenrangú szóelválasztó.
9

Rendben

vbence · 2009. Júl. 16. (Cs), 11.53
... akkor csak emberbarátabb :D
5

Kösz!

joed · 2009. Júl. 12. (V), 14.28
Kösz a válaszokat!

duplabe: kösz, ez tűnik a legjobb megoldásnak!

Rici: tisztában vagyok az indexek szerepével, de azzal is hogy egy 5000 rekordos táblában egy varchar255 mező indexe mennyi erőforrást igényel. Pont ezért szeretném elkerülni.

thgab: igen, egyedi lehet nagy valószínűséggel, de mi van ha nem? ahogy vbence is rávilágított, lehet, hogy 3 év múlva lesz egy azonos nevű bejegyzés.

Még egyszer kösz mindenkinek! :)
7

- vs. _

randomly · 2009. Júl. 15. (Sze), 22.29
Szia!

Hol ajánlja?

Köszi a válaszod előre is.

rand

ps: Elbaltáztam ... nem választ nyomtam sorry