Ez így szerkezetileg jó lesz?
Tervezgetek - és persze meg is valósítok - egy afféle egyszerű, kis blog motort. A célom ezzel az, hogy saját írásaimat és talán másokét is publikáljam. A megjelentetett írásokat kommentelni is lehet majd, statisztikát is készítek majd a látogatottságról, magamnak. Továbbá, mivel a cikkek, írások, posztok előbb utóbb megütnék azt a számot (100+), amit már egy főoldalon nem lehet normálisan megjelentetni, így kategóriákba is szervezném őket. Így idővel mindig csak egy kitüntetett kategória tartalma kerülne az index oldalra, a tobbi csak akkor, ha arra kiváncsi az olvasó. Ehhez az egészhet kialakítottam egy oldalstruktúrát. Azt szeretném megtudni, hogy jó lesz-e ez így, illetve ha nem jó, akkor kérlek, véleményezzétek és javítsatok ki, ahol ennek szükségét látjátok. Esetleges bővítési javaslatokat is szívesen vennék, bár nem igérem, hogy feltétlenül meg is valósítom ezeket. A tervezet így néz ki most:
A gyoker konyvtarban helyezkedik el az
- index.php ez listazza a hirek cimet mint egy-egy linket, fooldalon
- poster.php ezzel lehet majd hirt bekuldeni
- comment.php ez jeleniti meg a teljes hirt es ez irja a kommentet is
A [NEWS] directory a hireket,
a [PICT] directory a kepeket,
a [COMMENT] directory a kommenteket tartalmazza
a [STAT] pedig a szamlalo file-okat a statisztikahoz
A file-ok szerkezete [irasok]:
A file datuma a file neve /Unix time formatumban/ kiterjesztes nelkul
- Elso sor az iras cime
- Masodik sor a kategoria
- bunugy, technika, technikatortenet, kozelet, stb.
- a harmadik es minden tovabbi sor magat a cikket, irast, esszet tartalmazza.
A file-ok szerkezete [kommentek]:
A file neve a NEWS dir-ben levo valamelyik file komment fileja
- Az elso sor a USER nickneve
- A masodik sor a bekuldes datuma, unix time formatumban
- A harmadik sor fejlesztesre fenntartva
- A negyedik es minden tovabbi sor maga a komment.
A STAT file-ok neve szintén az írás dátuma lenne, de ebben csak egy számláló számolna felfelé, ha érkezik klikk az írásra. Ezek a file-ok az írás postolásával egyidőben jonnének létre, ahogy a commenteket tartalmazó file-ok is.
válasza: válasza:Régen, sok évvel ezelőtt készítettem egy apróhirdetési rendszert.
Idővel, úgy másfél év alatt egészen látogatott lett. Napi két-háromezres látogatószám és száz-százhatvan hirdetés feladás volt a csúcs. A hirdetések 7, 15 vagy 30 nap után automatikusan lejáródtak, így magukat lapátolták ki a rendszerből, de még így is előfordult, hogy negyvenezer aktív hirdetést tartalmazott a szerver, natúr text fájlokban. Ha akkor nem kellett adatbázis kezelő ahhoz a mennyiséghez, akkor ehhez pláne nem fog kelleni.
Realista vagyok, tudom, hogy a blogomat nem fogják ezrek és ezrek olvasni naponta. Ha tegyük fel, lesz is idővel mondjuk ezer látogató egy-egy napon, azok is időben elosztva fogják terhelni a szervert, pár tíz egyidejű látogató miatt meg totál felesleges adatbázis kezelőt igénybe venni ilyesmiért.
válasza:szörnyűnek hangzik
egyrészt ha változtatni akarsz rajta fájdalmas lesz
"A harmadik sor fejlesztesre fenntartva"
mivan ha több is lesz? olyan helyeken is, ahova eddig nem gondoltál
"A negyedik es minden tovabbi sor maga a komment."
problémák: pl. az újsort a kommentben hogy fogod megoldani?
és még pár probléma, amire nem gondolok, de összezavarja/zavarhatja a beolvasó cuccodat
az ilyen saját fájl megoldás helyett, én inkább JSON-t használnék vagy valami más hasonlót
de még inkább SQLite-t
+ ugye ott a probléma, hogy mivan, ha akkora forgalom, hogy folyamatosan írni, olvasni kéne a fájlokat
esetleg törölni belőle vagy módosítani valamit
és ha mindenképp fájlban tárolod, esetleg tárold le a verzióját, így azt kiolvasva tudod, hogy a további részeit melyik függvényeddel olvasd (így nem kell + sort fenttartani egy nem létező dologra)
A kommentekben nem lesznel újsorok. Amúgy lehetnének. De én nem fogom engedni. A html-t a weblinket, a space-eket és az új sor karaktereket szűrni fogom. Pontosabban, ez már meg is valósult.
Ismétlem, nem látom szükségét semmiféle adatbázis kezelőnek. Ezt a tapasztalat mondatja velem. Nem is vagyok ezzel egyedül, elég sok fejlesztés akad, amelyik plain textben tárol szöveges információkat.
Amúgy is, adatbázis kezelővel csak lassabb lenne. Az ilyesmire nem éri meg. Ha folyamatosan írni-olvasni kell a fájlokat, akkor azt majd elvégzi az operációs rendszer. Linux, flock.
A sor-sor adatszerkezet azért jó, mert nem igényel semmi pluszt, egyszerű a megvalósítása. Már majdnem a felénél járok és az egész csak háromszázhatvan sor, eddig.
válasza:Miért vagy az adatbáziskezelő ellen? Nem értesz hozzá eléggé? Vagy valami más miatt van ellenérzésed vele szemben?
Az biztos, hogy nem igaz, hogy lassabb lenne adatbáziskezelőben, csak jól kell megválasztod a tábláidnak az indexeket. A lehetőségeid csak megnőnének vele, gyorsabban kereshetnél vagy jeleníthetnél meg posztokat bizonyos szűrések alapján.
Kérdezted a véleményünk, ezt sokan vitális problémának látták, de én úgy látom, hogy már eléggé eldöntötted, hogy ezen nem változtatsz. Biztos vagyok benne, hogy hibát követsz el, megnehezíted a honlapod későbbi fejlesztését, de elfogadom és további sok sikert kívánok neked!
válasza:Maga az elképzelés nem teljesen elvetendő.
Létezik egy metodika, ahol a cikkek a webszerverről statikus állományokként kerülnek publikálásra, de azokat a szerkesztők a cikkek közzétételekor (ami - a hozzászólásokkal ellentétben - nem sűrűn történik, így az nem generál nagy adat/fájlírási forgalmat) dinamikusan állítják elő sablonok és statikus oldalgenerátor használatával.
Bővebben erről:
statikus oldalgenerátorok:
A kérdéses dolog a hozzászólások rendszere.
Ha nem akarsz ezzel vacakolni, vannak külön, a cikkekhez beilleszthető szolgáltatások - mint például a Disqus, a Facebook, vagy a Mastodon.
Kapcsolódó kérdések:
Minden jog fenntartva © 2024, www.gyakorikerdesek.hu
GYIK | Szabályzat | Jogi nyilatkozat | Adatvédelem | Cookie beállítások | WebMinute Kft. | Facebook | Kapcsolat: info(kukac)gyakorikerdesek.hu
Ha kifogással szeretne élni valamely tartalommal kapcsolatban, kérjük jelezze e-mailes elérhetőségünkön!