Új hozzászólás Aktív témák

• #890 Speeedfire félisten Sk8erPeter #886

  Új Válasz 2012-09-16 19:47:26 #890

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Speeedfire

  félisten

  válasz Sk8erPeter #886 üzenetére

  "Ez itt attól még sztem nem szempont, mert a konkrét hirdetést boncolgatod tovább, arra jelölsz meg külön táblában kiemelést, tehát a hirdetés_id szerint lenne értelme összekapcsolni a két táblát."
  A hirdetőknek vannak jutalom tallérjaik, egyenlegük stb stb.

  Ezt kifejtenéd?
  Ha tinyint vs. varchar, akkor az utóbbi mellett keresés ideje szempontjából nem túl sok szempont szól.....
  Wááá!
  Pont ezt írom, hogy ezeken az oldalakon a keresés nem jellemző. Belép valaki az oldalra és előtte van 100+x hirdető az 1. oldalon a második oldalon meg megint 100+x összesen max 500-600 hirdetés. Nagyon keveset fognak az oldalra látogatók keresni hirdetőket.

  Attól még nem látod, a háttérben hogy oldják meg, az, hogy a frontendre hogyan kerül ki a tartalom, nem befolyásolja azt, hogy hogyan kellene megoldani szépen a háttérben.
  Nem, de látom az oldalon működését. Meg belső infókat kapok!

  A prefix önmagában indokolt lenne, de inkább úgy, hogy egyértelműen jelölsz vele valamit, pl. application id-t vagy hasonlót.
  Jogos, de nekem most itt nem ez volt a szempont. Legyen valahogy jelölve, melyek tartoznak az adott oldalhoz. Így később sem kell bajlódni a nevekkel, ha költözik másik szolgáltatóhoz.

  A tages dolgot meg indokoltam már.
  PH! copy!

  Amúgy csak azért kérdeztem rá, miért nem CMS-t használsz erre a célra, mert mások már eleget szoptak azzal, hogy megfelelő táblastruktúrát kialakítsanak ilyesmire, mint pl. a fórum, ami Drupalnál eleve a core része
  Adott dolgokra jó, most is drupal van rajta. Csak ha már konkrét igények vannak, akkor én azt már drupallal nem tudom megoldani.
  Meg akkor már teljes mértékben úgy alakítom ki az oldalt, ahogy nekem tettszik.

  
  Athlon64+:
  A tbl_forum-hoz nem tartozik status, pedig kellene, illetve szóba jöhet más táblák esetén is még.
  Azóta már azt is beleraktam, illetve egy ordert is. A status csak az aktív/inaktív miatt van benne más egyéb miatt még nem gondolkoztam rajta el.

  sem adatbázisoldalról nem kell keresgetni, hogy az "1"-es állapot mégis mit takar, plusz pl. tárolt eljárások írásánál minden kiegészítőinformáció jól jöhet.
  Nem tudom erre mennyire jó megoldás, de én láttam már olyat, hogy felvesznek a model-ben pár constans változót, ami ezeket hivatott megmondani.
  pl

  const STATUS_DRAFT=1;
  const STATUS_PUBLISHED=2;
  const STATUS_ARCHIVED=3;

  Következetlen a táblák elnevezése, néhol többes, máshol egyes számban írod.
  Hát, ezen még nem agyaltam. Csak írtam, ami eszembe jutott.

  Ugye lesznek majd index-ek is?
  Nyilván lesznek és vannak is.

  Látom mindenki leragadt a salt mellett.
  Ezt a yii-ből vettem.

  A salt regisztrációkor kerül a táblába ami egy unique kulcs és amikor valakit validál a rendszer akkor ezt is nézi.

  public function validatePassword($password)
  {
  return $this->hashPassword($password,$this->salt)===$this->password;
  }
  
  public function hashPassword($password,$salt)
  {
  return md5($salt.$password);
  }

Új hozzászólás Aktív témák