Lekerdezest szeretnek egyszerusiteni amit eddig 3 egyszerubbel oldottam meg gondolom meglehet ezt egybol is csinalni csak en nem tudom. A pelda kedveert legyen 2 tabla:
szinek:
id|leiras
---------
1 | piros
2 | kek
3 | sarga
stb ....
satirozas:
id|szin1|szin2
----------------
1 | 1 | 1
2 | 2 | 3
3 | 99 | 34
stb.
SELECT szin1, szin2 FROM satirozas WHERE id=2 lekeresre ugyebar azt kapom hogy 2 , 3 en viszont azt szeretnem megkapni hogy kek, sarga. Ezt eddig ugy oldottam meg hogy az elso lekerdeze utan ahol megkapom a 2 es 3 eredmenyt, egyenkent lekerdezem az id=2 es az id=3 ertekkel a szinek tablat ahol megkapom azokat az ertekeket amik nekem kellenek. Vagyis valami olyasmit szeretnek hogy amikor a satirozas tablabol lekerdezem hogy id=2 akkor azt kapjam hogy kek, sarga.
Olyan erzesem van hogy itt valami relaciot kell felallitani de errol nemsokat tudok, vagyis inkabb semmit. Es az a gondom hogy mostani munkam soran tobb ehhez hasonlo esetem is lessz.
Egy masik eset:
felhasznalok:
id|nev
---------
1 | sanyi
2 | pista
3 | eva
stb ....
uzenetek:
id | irta | uzenet
-------------------
1 | 1 | aaaaaa
2 | 1 | bbbbbb
3 | 2 | ccccc
stb....
Itt mindket tabla az id szerint van indexelve
SELECT felhasznalok.nev , uzenetek.uzenet FROM felhasznalok, uzenetek WHERE uzenetek.id = 3 AND uzenetek.irta = felhasznalok.id
Ez igy jo? Vagy ezt sem jol csinalom?
- 3828 megtekintés
Hozzászólások
google://left|right|inner|natural join
SELECT id, szin1,
sz2.leiras AS leiras1
sz2.leiras AS leiras2
FROM satirozas AS s
LEFT JOIN szinek AS sz1 ON (s.szin1 = sz1.id)
LEFT JOIN szinek AS sz2 ON (s.szin2 = sz2.id)
"SELECT felhasznalok.nev , uzenetek.uzenet FROM felhasznalok, uzenetek WHERE uzenetek.id = 3 AND uzenetek.irta = felhasznalok.id"
Így _NE_, jól indultál el, de ritka undorító és nehezen áttekinthető, ha így írod.
----------------
Lvl86 Troll
- A hozzászóláshoz be kell jelentkezni
+1
"Es az a gondom hogy mostani munkam soran tobb ehhez hasonlo esetem is lessz."
Szerintem akkor sürgősen ásd mélyebbre magad az sql-ben, mert a join az sql-ben eléggé alap...
Wikipédia idevágó oldala jó lesz kezdésnek:
http://en.wikipedia.org/wiki/Join_%28SQL%29
----------------------------
http://jailhouse.blogozz.com
- A hozzászóláshoz be kell jelentkezni
Igen, az ásás folyamatban van ... :) Eppen csak a join-t nem alkalmaztam eddig sosem de most probalom minnel jobban osszehozni az egeszet. Sajnos gyakorlatom nemsok van es most ugyjott hogy egybol salyat magamnak kell elkesziteni az egeszet php, mysql, html ... Szoval mindent magam csinalok...
A tanulastol nem riadok vissza csak neha kell egy kis lokes rajtam hogy a lendulet megmaradjon :)
Koszi.
- A hozzászóláshoz be kell jelentkezni
Nagyon szepen koszonom, mar par gondal kevesebb van :)
- A hozzászóláshoz be kell jelentkezni
- A hozzászóláshoz be kell jelentkezni
+1
- A hozzászóláshoz be kell jelentkezni
+1
- A hozzászóláshoz be kell jelentkezni
Egy masik kerdesem is volna :) Ez a reszlet egy uzenetek tablabol (ebben az esetben konkretan a kuldo) torli vagyis toroltkent allitja be az uzenteket. Uzenetenkent ki lehet oket "pipazni" es van ugyebar egy Submit gomb ...
if(isset($_POST[submit]) and isset($_POST[delete_msg]))
foreach($_POST[delete_msg] as $xelem) {
mysql_query("UPDATE uzenetek SET `sender_delete` = 'y' WHERE (`uid`=".(int)$xelem." AND `sender_uid` =".$_SESSION['uid'].")");
}
Annyi lenne a kerdesem hogy ezt igy szokas, vagy van ennek optimalisabb (jobb, szebb) modja is? Tekintettel hogy itt uzenetenkent kulon kulon UPDATE megy ... Az az erzesem hogy ezt valahogy egy UPDATE -val is meglehetne oldani... Valahogy az egesz $_POST[delete_msg] tombot atlehetne adni? Itt en a biztonsag erdekeben (SQL Injection) mindeg atalakitottam egesz szamra (int) a tomb elemet mielott atadtam volna a MySql-nek ...
Tevedek?
- A hozzászóláshoz be kell jelentkezni
en a biztonsag erdekeben (SQL Injection) mindeg atalakitottam egesz szamra (int) a tomb elemet mielott atadtam volna a MySql-nek ...
ennél biztosabb megoldás, ha ellenőrzöd, hogy tényleg szám kinézetű-e a paraméter (preg_match), ill. a paraméter hossza emberi limiten belül van (ne lehessen több ezer karakteres számmal fejreállítani valahol a rendszert).
- A hozzászóláshoz be kell jelentkezni
Ez igy most jobb? :) Most egy UPDATE -vel megoldja az egeszet vagy ez az sql sebessege szempontjabol nem is annyira jelentos? Na meg persze a php is fontos hogy mennyi ideig dolgozza fel nem csak az sql ...
$xx= $_POST[delete_msg][0]; // persze itt meg ellenorizni kell hogy szam-e
for($i=1;($i<count($_POST[delete_msg])) and (i<100);$i++) { // max 100 sort enged torolni
$xx = $xx . ", " . $_POST[delete_msg][$i]; // persze itt meg ellenorizni kell hogy szam-e
}
mysql_query("UPDATE uzenetek SET `sender_delete` = 'y' WHERE `uid` IN (".$xx.") AND `sender_uid` =".$_SESSION['uid']);
Es valami ilyen lekerdezest kapok ...
UPDATE uzenetek SET `sender_delete` = 'y' WHERE `uid` IN (3, 2) AND `sender_uid` =1
A for ciklusban levo hozzaadogatosoktol van valami szebb megoldas arra hogy egy tombbol valami ilet csinlajak: 1,2,33,44,555 ??
- A hozzászóláshoz be kell jelentkezni
"A for ciklusban levo hozzaadogatosoktol van valami szebb megoldas arra hogy egy tombbol valami ilet csinlajak: 1,2,33,44,555 ??"
pl: implode
http://php.net/manual/en/function.implode.php
- A hozzászóláshoz be kell jelentkezni
Azért figyeljünk a lezárásokra
--
http://www.buster.hu
--
- A hozzászóláshoz be kell jelentkezni
Irtam trey-nek, sajnos a kommentelo attol a pillanattol nem tud tenni semmit, amint valaszolnak neki.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.
- A hozzászóláshoz be kell jelentkezni
implode + in()
t
- A hozzászóláshoz be kell jelentkezni
Arrol az in() -rol tudnal valami linket vagy par szot mert en valahogy sehogyan sem talalom...
Eddig erre jutottam:
implode(",", array_slice($_POST[delete_msg],0,100 ));
Itt fogom a $_POST -bol az elso 100 elemet es szetszedem oket, csak meg megkellene oldani hogy SQL Injection biztos legyen a dolog. Megtudom oldani egy for vagy foreach ciklussal de gondolom ugy nem szep ...
- A hozzászóláshoz be kell jelentkezni
select a, b from c where d in (1, 2, 3, 4);
t
- A hozzászóláshoz be kell jelentkezni
Koszi de azt mar megoldottam es irtam is par uzenettel feljebb :) Kulonben az uzidbol arra gondoltam hogy az in() is valami php fuggveny ... :)
UPDATE uzenetek SET `sender_delete` = 'y' WHERE `uid` IN (3, 2) AND `sender_uid` =1
Mostmar csak az a gond hogy SQL Injection biztossa tegyem, az implode -val is mar szettudom szedni meg csak az kell hogy a tombon belul atkonvertaljam az elemeit szamokka...
Eddig erre jutottam:
implode(",", array_slice($_POST[delete_msg],0,100 ));
- A hozzászóláshoz be kell jelentkezni
foreach + is_numeric() + intval + tomb[] + implode
t
- A hozzászóláshoz be kell jelentkezni
Koszonom! Szoval akkor azt az egy foreach ciklust nem tudom kikerulni ... Mukodik. A vegeredmeny ez lett:
$delete_array = array_slice($_POST[delete_msg],0,100 );
foreach($delete_array as $xelem) {
if (is_numeric($xelem)) {
$new_delete_array[] = intval($xelem);
}
}
$xx = implode(",", $new_delete_array);
mysql_query("UPDATE uzenetek SET `sender_delete` = 'y' WHERE `uid` IN (".$xx.") AND `sender_uid` =".$_SESSION['uid']);
Esetleg meg az a kerdesem hogy erdemes-e azzal foglalkoznom hogy a $_POST tombbol kivegyem az elso pl. 100 elemet vagy ha mar idaig bejutottak az adatok akkor mar itt csak egyszeruen dolgozzam fel akarhany is van belole? Mondjuk hogy valaki szanadekossan (rosszindulatbol) valami hatalmas tombot kuld el? Persze a rosszindulatu torles ki van zarva mert az SQL csak a bejelentkezett felhasznalo sajat uzeneteit engedi meg updatelni a $_SESSION['uid'] alapjan.
- A hozzászóláshoz be kell jelentkezni
ki tudod kerulni:
implode(",", array_filter($new_delete_array, "is_numeric"));
a 100-as limit esetleg indokolhato, de pl. a max_packet_size (vagy valami hasonlo alaku) kulcs beallitasa a mysql configban pl. default 100mb folott szokott lenni ujabban (ebbe belefer tobb mint 100 szam:))
- A hozzászóláshoz be kell jelentkezni
Először is nem $_POST[submit], hanem $_POST['submit']. Azon kívül, hogy mindig végig nézi a konstansok tábláját, majd miután nem talál, csinál egy konstans->string konverziót, dob még egy notice-t is, legyünk már tisztába azzal, hogy mit csinálunk.
(fejlesztésnél legyen már alap a display_errors=On és az error_reporting = E_ALL beállítás és nem mindenféle szerveren kell beletúrni, hanem fejlesztői gépre apache+mysql fel és ott kell fejleszteni.)
Másodszor: mysql_real_escape_string
Harmadszor: használj valami SQL réteget réteget, lehetőleg olyat, ami ad paraméterezési lehetőséget és escapel magának valamint van benne hibakezelés.
----------------
Lvl86 Troll
- A hozzászóláshoz be kell jelentkezni
$_POST['submit'] Ezt most megtanultam, errol eddig nem tunt fel hogy olvastam vola, biztos elsiklottam felette.
/etc/php5/apache2/php.ini fajlban (Debian Lenny) :
display_errors=On
error_reporting = E_ALL & ~E_NOTICE
gondolom ez igy jo de a fenti submit-es esetben nem vettem eszre semmi hibajelet vagy figyelmeztetest, lehet hogy valami megsem jol van beallitva?
A mysql_real_escape_string -et ismerem termeszetessen, de ebban az esetben mivel kizarolag szamokat kell atadnom az SQL -nek ugy gondoltam hogy egyszerubb ha szamma alakitom. Szoveges reszeknel termeszetesen escapelem a dolgokat.
Elgondolkozok az sql retegen meg gondolkoztam mar a smarty -n is de mar elegge jol elorehaladtam ezzel es mostmar menet kozben nem valtoztatnek ebben a porjektben. Majd a kovetkezonel :)
Sajnos az a gondom hogy ilyen temakban nem talatam olvasnivalot, ami ilyen dolgokkal foglalkozik hogy mit hogyan erdemes, kell, illik stb. Szoval amiket tanulmanyzok azok sima mysql, php stb. konyvek. Viszont jol jonne valami olyasmi ami egy portal vagy minek nevezzem az elkeszitesenel az altalanosabb dolgokkal foglalkozik. Nemtudom ez a mondatom mennyire volt egyaltalan ertheto :)
- A hozzászóláshoz be kell jelentkezni
Nem jo. A tilde jel itt a negallast jelenti, tehat kiveszi az E_ALL-bol az E_NOTICE-ket. Csak E_ALL legyen, vagy ha nagyon szigoruan be akarsz tartani mindent, akkor E_ALL & E_SRICT.
A notice szintu hibauzenetek ugyan aprosagok altalaban, de nagyon sokszor ramutat valami olyan gepelesi vagy logikai hibara is a szepseghibakon felul, ami komolyabb problemakhoz is vezethet.
----------------
Lvl86 Troll
- A hozzászóláshoz be kell jelentkezni
Javitottam a php.ini -t :) De valahogy egy arva hibat vagy warningot sem dob ki pedig biztos lenne valami ....Lehet hogy meg mindeg nem jo valami?
Akkor a $_SERVER[REMOTE_ADDR] helyett is $_SERVER['REMOTE_ADDR'] meg akkor a $_SESSION['valami'] is igy kell hogy kinezzen ugye?
Es ha van egy tombom pl.: $tomb[akarmi] helyett is akkor a $tomb['akarmi'] kell? Vagyis ha jol ertem akkor mindeg kellenek csak kivetelesen akkor nem ha van olyan nevu konstans definialva?
- A hozzászóláshoz be kell jelentkezni
Igen. Mivel, ha csak önmagában egy ilyen, hogy VALAMI egy konstansként kezeli a PHP. Ilyenkor az értelmező végigszalad a konstansok tábláján, hogy megkeresse az értékét. Mivel nem találja, normál esetben dob egy notice-t, hogy ilyen nincs, innentől úgy használja tovább, mint egy string. Ellenben ez felesleges idő, míg végigfut, és nem szép.
De próbáld ki:
define('VALAMI', 'AKARMI');
$a = array(
'VALAMI' => 'v',
'AKARMI' => 'a',
);
echo $a[VALAMI];
echo $a['VALAMI'];
----------------
Lvl86 Troll
- A hozzászóláshoz be kell jelentkezni
Meg egy kerdesem lenne aminel nem tudom eldonteni hogy igazan mi is a helyes ut... Legyen a felhasznalok tabla benne 'id' a felhasznalo azonositoja es 'nev' legyen a neve. Tovabba legyen egy vendegkonyv nevu tabla ahova a felhasznalok hozzaszolasokat tudnak irni (valamihez). Na most az a kerdesem hogy ebben a vendegkonyv tablaban csak a hozaszolo felhasznalo 'id' -jet taroljam le vagy az 'id' es a 'nev' is keruljon bele? Ezzel az a gondom hogy ha belerakom a nevet is akkor mar nem lessz az egesz a megfelelo normalformaban. Mert ugyebar a nevek ismetlodnek 2 tablaban. Viszont masfelol igy ha a hozzaszolast iro felhasznalo idokozben torli salyat magat vagy mas okbol torlodik akkor is a hozaszolasnal legalabb egy nev szerepelni fog...Vagy a felhasznalok tablabol sosem toroljek csak pl. jeloljem be hogy az a felhasznalo torolve van?
Remelem ertheto hogy mi is a gondom? :)
- A hozzászóláshoz be kell jelentkezni
1. a "normál formák" c. fejezeteket nem kell annyira komolyan venni, logikusan végig kell gondolni, hogy az az adat, amit össze tudnál vonni egy táblába, az tényleg ugyanaz az adat-e. pl. esetünkben ha a user nevét meg lehet változtatni, akkor a vendégköny bejegyzéshez a beíráskori vagy az aktuális nevét szeretnéd hozzárendelni - ettől függ, hogy a két adat ugyanaz-e (ilyenkor van értelme, sőt logikus a normál forma szerinti átalakítás), vagy nem is ugyanazt az adatot akarod tárolni (ilyenkor viszont nem is lehet összevonni)
2. ha a user törlésekor ténylegesen szeretnéd törölni a tábla sorát, akkor el kell gondolkodnod, hogy a rá hivatkozó többi sorral mit kezdjél. mármint logikailag mit szeretnél csinálni.
a) megoldás: törlöd azokat a sorokat is (ez vendégkönyvnél nem hangzik értelmesnek)
b) megoldás: a sorokból a hivatkozásokat törlöd (set null) - ezt nyilván kezelnie kell tudni a programnak
c) megoldás: a hivatkozásokat módosítod, és valami dummy user sorra változtatod (pl. "Törölt felhasználó" nevűre)
d) megoldás: a user sorát mégsem törlöd, csak egy flag-et átállítász nála, hogy "törölt".
- A hozzászóláshoz be kell jelentkezni
Igen tobb megoldas is letezik... Nagyon ugy nezem, az lessz, hogy a felhasznalo tabla sorait torlom ha erre kerul sor, a torolt felhasznalora mutato tablak egy reszenel meg a mutato majd a nem letezo sorra (felhasznalora) fog mutatni, de a felhasznalo nev ezekben a tablakban is meglessz...A tobbi tablaknak meg azok a sorok is trolodnek majd ahol a nemletezo felhasznalora mutatnak a hivatkozasok ... szoval valami kevert megoldas lessz...
Vendegkonyvnel, maganuzeneteknel meg hasonloknal a felhasznalo torlesekor az altala irt uzenet bejegyzes megmarad itt ezeknel mindeg ott lessz a 'nev' (username) es az 'id' ami a felhasznalo tablaba mutat de ott olyankor mar nem lessz a sor megtalahato es ilyenkor egy torolt felhasznalo uzenet lessz majd... A felhasznaloknal egy mar valamikor hasznalt 'id' -et ujabb felhasznalo nem kaphat meg (int, auto increment, not null, unique)
A felhasznalo tablaban az uszer nevet nem lehet majd megvaltoztatni ugy gondolom jobb ha vegig ugyanaz marad... ez a nev tulajdonkeppen nem a rendes neve hanem az a nevezzuk becenevnek amin bejelentkezik vagyis mindenki ezt lassa mindenhol es gondolom elobb utobb a tobbi felhasznalo megjegyzi a nasik "nevet" mint itt pl. nalad a "vl" szoval az az username ...
- A hozzászóláshoz be kell jelentkezni
Meg egy kerdesem lenne, az en megoldasom mukodik csak az a kerdesem hogy ez a megoldas igy jo-e vagy lehetne optimalissabban is megoldani?
Az oldal amit keszitek tobbnyelvu, jelen pillanatban ketnyelvu de van ra esely hogy idovel meg tobb nyelv is szobajon ... Ugy oldottam meg hogy a php -ben bevezetem egy $lng[] globalis tombot es amikor a szovegeket ki kell irnom akkor a <?php echo $lng['valami']; ?> megoldast hasznalom, gondolom ez eddig rendben is van. A tombot az oldal elejen a sessionban tarolt nyelvtol fuggoen egy mySql tablabol toltom fel...
function ReadLng($page)
{
global $lng;
$sql = "SELECT id, ".$_SESSION['lang']." AS szoveg FROM lang WHERE page = '".$page."'";
$query = mysql_query($sql);
while ($row = mysql_fetch_array($query)){
$lng[$row['id']] = $row['szoveg'];
}
}
Ket forduloban, egyszer a $page ures ilyenkor azokat a szovegeket olvasom be amik tobb (sok) oldalon is szerepelnek es egyszer a konkret oldal szovegjeit...
CREATE TABLE IF NOT EXISTS `lang` (
`page` varchar(40) NOT NULL default '',
`id` varchar(250) NOT NULL default '',
`hu` text NOT NULL,
`sr` text NOT NULL
) ENGINE=MyISAM DEFAULT CHARSET=utf8;
Amenyiben valamikor ujabb nyelv lenne bevezetve a tablaban csak egy ujabb oszlopot kell letrehoznom...
Az lenne a kerdesem hogy hogyan indexeljem ezt a tablat es egyatlan jo-e ez a megoldas igy? A sebesseg szempontjabol ez a megoldas mennyire optimalis, mivel arra szamitok hogy sok oldallekerdezes lessz, gyenge vason, keves penzel :( szoval olyan kezdo megoldas es jo lenne ugy megoldanom hogy minnel optimalissabb legyen ...Szoval remelem ertheto vagyok :)
- A hozzászóláshoz be kell jelentkezni
Lokalizációt én nem tárolnék adatbázisban, csak ha elkerülhetetlen. Statikus include-ok, vagy .po. .mo fájlok hatékonyabbak.
- A hozzászóláshoz be kell jelentkezni
Ugyerted hogy minden nyelvhez csinaljak egy magyar.php angol.php es azokat includoljam be? az valami ilyesmi lenne?
magyar.php
----------------
$lang['igen'] = "Igen";
$lang['nem'] = "Nem";
angol.php
----------------
$lang['igen'] = "Yes";
$lang['nem'] = "No";
Igy includolnam be a kozos dolgokat amik minden oldalon elofordulnak es lennek pl magyar_bejelentkezes.php ahol pl a bejelentkozo oldalhoz specifikus nyelvi dolgok lennenek?
Vagy az oszes egy pl. magyar.php -ban lenne valahogy?
Azok a .po .mo fajlok azok valojaban micsodak azokrol most hallok eloszor...
erre gondoltal? : gettext
P.S.: Megjegyeznem hogy olyan megoldas kell ami servertol fuggetlen mert lehet hogy olyan vason lessz fent az egesz ahol a server beallitasain nem tudok valtoztatni...Es persze a sebesseg meg a minnel kisebb terheles a lenyeg.
- A hozzászóláshoz be kell jelentkezni
"Ugyerted hogy minden nyelvhez csinaljak egy magyar.php angol.php es azokat includoljam be? "
Igen, csak erre vannak szabványos nevek (hu_HU, en_US), azokat érdemes használni. És a kulcs inkább angol legyen:
$lang['yes'] = "Igen";
$lang['no'] = "Nem";"Vagy az oszes egy pl. magyar.php -ban lenne valahogy?"
Mennyiségtől függ.
Igen, gettext.
- A hozzászóláshoz be kell jelentkezni
Huha akkor ha jol ertem ha erre a gettext -re megyek at akkor nem is kell includolnom semmit...
Minndenestre ennek utannanezek jobban egy kicsit :) feltettem a poEdit -et a debianomra es meglatom mi sul ki belole...
Ez szerinted optimalisabb megoldas akkor annal az en regimnel?
- A hozzászóláshoz be kell jelentkezni
Szerintem igen.
- A hozzászóláshoz be kell jelentkezni
Felraktam mindent, csak az a gond hogy nem mukodik...
Letrehoztam a szukseges mappakat a var/www/xxxxx/locale/sr_RS/LC_MESSAGES benne a messages.mo es messages.po falokat sot meg a apacsot is ujraundotottam :)
// $locale = "sr_RS";
$locale = "hu_HU";
if (isSet($_GET["locale"]))
$locale = $_GET["locale"];
putenv("LC_ALL=$locale");
setlocale(LC_ALL, $locale);
bindtextdomain("messages", "./locale");
textdomain("messages");
echo "
";
echo _("Esik az eso");
echo "
";
echo _("Sut a nap");
echo "
";
Keszitettem egy ilyen php faljt de nem mukodik a dolog .... Persze a bongeszoban a proba.php?locale=sr_RS parameterrel problakoztam ...
a .po es a .mo fajlok gondolom hogy jok .. A poedit szerint :)
GetText Support is enabled :)
- A hozzászóláshoz be kell jelentkezni
Bindtextdomain-ben abszolút elérési utat megadva? Olvasási jogok vannak?
- A hozzászóláshoz be kell jelentkezni
bindtextdomain("messages", "./locale"); ez van benne mit felette irtam is, vagy valahol mashol is be kell allitani? /var/www/xxxx/locale -t kell irmon? Probaltam de azzal sem mukodik ...
Viszont talatam egy ilyesmit amit nem igazan ertek: http://mel.melaxis.com/devblog/2006/04/10/benchmarking-php-localization…
When using the gettext extension on Linux, make sure all used locales are installed on the system. For example, in Debian (and probably other distributions, too), add the required locales to /etc/locale.gen and run locale-gen. For this test, I added “de_DE.UTF-8 UTF-8″ for the German UTF-8 version.
Ha az oldal egy olyan serverre lessz felteve ahol en ezt nem birom allitani akkor ezek szerint ez a megoldas nem fog mukodni?
- A hozzászóláshoz be kell jelentkezni
Apachnak olvashatóak a fájlok és a könyvtárak? Esetleg próbálj meg CLI-ből futtatni egy rövid példát.
"/etc/locale.gen"
Én arra tippelnék, hogy ez csak a generáláshoz kell, a használathoz nem. Az gettext extension persze kell a végleges környezetben, előtte azt nézd meg.
- A hozzászóláshoz be kell jelentkezni
Vegigcsinaltam amit az angolul beidezett reszben irt es most mukodik a dolog.
/etc/locale.gen -ben kiszedtem a kommenteket a megfelelo sorok elol es lefuttattam a locale-gen parancsot es ettol megjavult ...persze az apacs is ujrainditva ....
Viszont ez a megoldas igy nagyon serverfuggo nekem ... Letezik az hogy ha felteszem majd a kesz oldalt valahova akkor ott ujbol nem fog mukodni benne ...Vagy ezek a dolgok csak nalam nem voltak jol beallitva?
- A hozzászóláshoz be kell jelentkezni
Centos-os nyoma sincs hasonló központi beállításnak, a SquirrelMail mégis szépen megy, és lokalizál.
- A hozzászóláshoz be kell jelentkezni
Az a "putenv" gyanús, hogy nem kell.
Nekem ezzel működött bash-ból:
$locale = "hu_HU";
setlocale(LC_ALL, $locale);
bindtextdomain("squirrelmail", "./locale");
textdomain("squirrelmail");
echo "";
echo _("Source");
Output: Forrás
- A hozzászóláshoz be kell jelentkezni
Végeredményben ez a gettext megoldas nagyon tetszik nekem es még majd próbálkozok is vele, meg majd megprobalom egy ket masik gépen is hogy ott hogy mukodik.
Mindenesetre koszonom az oteltet ugylatom ez lessz a megoldas. Csak meg csiszolnom kell a tudasom hozza :)
- A hozzászóláshoz be kell jelentkezni
Ugyan nem vág a témába, de nem bírom nem meg jegyezni, hogy így változókat az sql stringedbe NE tegyél !
Néz utána az SQL injection témának.
2 perc alatt feltörik az oldalt így !
"Computer! Earl Grey 27 Celsius-ost !"
Blogom
- A hozzászóláshoz be kell jelentkezni
Kosz hogy szoltal, termeszetes hogy a valtozokat nem ugy rakom be, de konkretan melyik uzenetemben levo valtozora vagy valtozokra gondolsz, mert az is lehet hogy elkerulte valami a figyelmemet? Itt amiket beideztem azok vagy csak peldak voltak, vagy lecsupaszitott reszletek ...
Sql Injection temaban valamenyire azert otthon vagyok :) En vagyok a Mic..soft szervezeseben megtartott Sinergija 2008 keretein belül rendezett Hackerverseny 3. helyezettje ... Nem nagy valami de azert csak tudhatok valamit ...
Mindenestre orulok hogy szoltal, minden hozzaszolas jol jon mert ilyen portal vagy minek nevezzem kesziteseben nagyon is kezdo vagyok.
- A hozzászóláshoz be kell jelentkezni
Hackerverseny 3. helyezettje ... Nem nagy valami de azert csak tudhatok valamit ...
hmmm... ezek szerint hackelni tudsz, erről papírod van :P
- A hozzászóláshoz be kell jelentkezni
En azert inkabb ugy mondanam hogy konyitok valamit hozza :)
- A hozzászóláshoz be kell jelentkezni
Sql Injection temaban valamenyire azert otthon vagyok :) En vagyok a Mic..soft szervezeseben megtartott Sinergija 2008 keretein belül rendezett Hackerverseny 3. helyezettje ... Nem nagy valami de azert csak tudhatok valamit ...
Taps! Taps! Taps! ...
------------------
http://www.youtube.com/watch?v=Sf8cM7f6P2I
- A hozzászóláshoz be kell jelentkezni
$sql = "SELECT id, ".$_SESSION['lang']." AS szoveg FROM lang WHERE page = '".$page."'";
Erre gondoltam.
Bár nem tudom a $page honnan jön, illetve a session-re használsz-e cookie-t ?
De ha mondjuk a page egy változó az oldalról , mondjuk a következő page id-ja, akkor azt már nem nehéz fel nyomni.
Egyébként én nem vagyok semmilyen hacker verseny győztese, mondjuk indulni sem indultam ilyenen.
"Computer! Earl Grey 27 Celsius-ost !"
Blogom
- A hozzászóláshoz be kell jelentkezni
Igen ez egy reszlet es igy termeszetessen nem teljessen atlathato igy. De termeszetessen azert ettol fuggetlenul orulok az eszrevetelednek.
Egyszoval a fenti reszben a $page erteket maga a php hozza letre es az erteke vagy "" vagy pedig egy array valamelyik eleme ugyhogy oda akarmi nem juthat bele meg veletlenul sem. A $_SESSION['lang'] termeszetessen valahol egy sutivel kezdodik amikor a latogato eloszor kerul az oldalra es a kovetkezo latodatasa soran mar a sutit o adja az oldalnak de ott szigoruan ellenorizve van hogy mi lehet az erteke. Maga a session_id is suti formajaban jon de az is ellenorizva van. A nyelv a sutiben csak legeloszor van hasznalva amikor vegeredmenyben belekerul a session -ban, utanna mar kizarolag a sessionbol van hasznalva az erteke meg persze ha a latogato bongeszese kozben nyelvet cserel akkor $_GET de ott ismet jon az ellenorzes.
Minden suti, $_GET, $_POST ellenorizve van hogy rendben van-e. Sot meg amikor a regisztralt latogato bejelentkezik akkor uj session_id -et kap, az elozo session torlodik, azt mar mas sem tudja hasznalni. Minden egyes session kotve van az IP -hez is. Esetleges session lopasnal igy az ip-t is hamisitani kell a loponak. Ha ugyanazzal a felhasznalonevvel valaki mas bejelentkezik akkor az elozo session torlodik, egyszerre nem lehet ketszer bejelentkezve egy user.
Hirtelen ennyi jutott az eszembe.
Egyebkent nem igazan dicsekvesnek szantam, csak arra kartam utalni hogy azert attol fuggetlenul hogy irogatom hogy ezekben a dolgokban kezdo vagyok, azert nem egy altalanos iskolasra kell gondolni, csak hat eppen eddig nem keszitettem ilyen kaliberu portalt vagy minek nevezzem ...
"Computer! Earl Grey 27 Celsius-ost !"
Nem hideg az 27 fokon egy picit? :P
P.S.: Ha elkeszulok vele szolok es pm-ben akit erdekel megadom a cimet (hogy ne legyen reklam) es amig probauzemben lessz vagyis meg tesztelodik szabad lessz a vasar lehet majd torni ... :)
- A hozzászóláshoz be kell jelentkezni
Ujabb gondom van, kepzeljuk el hogy kulonbozo halakat akarok tarolni egy tablaban amiket egy fa struktura szerint kulonbozo csoportokban rendezek. Ezeket a halakat kellene lekerdezgetnem a csoportok szerint.
fa:
id | bal | jobb | nev | darabszam
--------------------------------------------
1 | 1 | 10 | halak | 547675
2 | 8 | 9 | edesviz | 54578
3 | 2 | 7 | tengeri | 54589
4 | 3 | 4 | ragadozo | 567
5 | 5 | 6 | nem ragadozo | 488
halak:
id | fa_id | stb ....
-----------------------
1 | 5 | egy nem ragadozo tengeri hal
2 | 4 | capa
Ezzel a modszerrel szepen le tudom is kerdezni mindazokat a halakt amik a fa strukturaban a levelekhez tartoznak (fa.id = 4 es 5) De nekem az is kell hogy le tudjam kerdezni az oszes halat vagy csak a tengeri halakat... A fa tabla kb. parszaz sorbol allna viszont a halak tabla kb 100.000 nagysagrendu lenne, es foleg ilyen csoportok lekerdezes lenne benne tulnyomoreszt azt kiveve hogy a halakbol egy konkret id -re lessz lekeres...
A gondom megoldasara az az otletem hogy letrehozok egy ujabb nevezzuk kapcsolatok tablat
kapcsolatok:
fa_id | halak_id
-----------------
1 | 1
1 | 2
3 | 1
3 | 2
4 | 2
5 | 1
Vagyis ha beviszek egy ujabb halat akkor vegigmegyek a fan es a kapcsolatokban beirok minden olyen fa_id -et amelyik csoportba beletartozik az adott hal. Igy le tudom kerdezni pl az osszes tengeri halat (SELECT fa_id = 3) Hogyan kell szepen megoldani az ilyesmiket? Marmint nem magat a lekerdezest hanem ezek a tablak igy jol vannak elkepzelve? Igy szokas? Igy optimalis, mivel hogy rengeteg lekerzeses lessz ...
A masik kerdesem az lenne hogy egy ilyen tablanal jo megoldas-e az hogy a fa tablaban egybol letarolom a darabszamokat is? Tekintettel hogy ujabb adat hozzaadasa azert megis (gondolom) sokkal ritkabban lenne mint a csoportok lekerdezesei ahol a darabszamnak szerepelni kell majd az oldalon. Igy egy ujabb hal bevitelenel tobb dolog lenne mert a fan vegig kell menni es hazzaadni a darabszamoknal mindeg az 1-et...De a lekerdezeseknel nem kell oszeszamolnom oket ...Vagy ha mar bevezetem ezt az uj osszekoto tablat akkor azon mindeg inkabb count -oljak? Hogy kell szepen megoldani az ilyesmiket?
- A hozzászóláshoz be kell jelentkezni
izé ...
tanulásnak nem kattingatnál először egy phpadmin felületen csak hogy lásd mi történik mikor mit akarsz...
No rainbow, no sugar
- A hozzászóláshoz be kell jelentkezni
phpMyAdmin -t es a MySQL Workbench -et szoktam hasznalni ... De nem igazan ertem mire is gondoltal...
- A hozzászóláshoz be kell jelentkezni
Valamiert ez chrome-ban jusztin kommentjetol monotype lett.
--
()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.
- A hozzászóláshoz be kell jelentkezni
En iceweasel -t hasznalok... , de goldolom a forraskodban levo < jel zavart be a Chrome-nak
- A hozzászóláshoz be kell jelentkezni
Mire kell neked az a plusz tábla?
Ha a tengeri halak kellenek (az alatta lévő összes)
select halak.*
from fa
inner join halak on (halak.fa_id = fa.id)
where fa.bal >= 2 and fa.jobb <= 7
A 2 és a 7 a tengeri bal és jobb értéke.
Ha azt szeretnéd, hogy normális sebességű legyen akkor index kell a bal és a jobb oszlopokra.
Szerk: Ahonnan vetted ezt a fa tárolási módszert ott nem voltak leírva az ilyen összefüggések?
Pl (jobb - bal -1)/2 = Az ág alatti ágak számla
vagy: where fa.bal <= :bal and fa.jobb >= :jobb order by fa.bal -> Egy megadott ághoz vezető egyes ágak elemei
...
- A hozzászóláshoz be kell jelentkezni
Igen, ahonnan vettem a modszert ott voltak leirva ilyen osszefoggesek, en csak a sebesseg miatt gondoltam a plussz tablara...
Igen, a bal es a jobb oszlop indexelve van. Sot en meg a halakat is indexeltem a fa_id szerint is. Gondolom az is segit a sebessegen .... Vagy tevedek es azt felesleges indexelni?
A "halak osszeszamolasaval" mi a velemenyed? Jol gondolom hogy a halak tabla elemeinek hozzaadasanal vagy torlesenel modositom a fa tablaban a megfelelo darabszam mezoket? Igy a lekerdezeseknel nem kell szamolgatni es azokbol lessz tobb ...
- A hozzászóláshoz be kell jelentkezni
Csak jótanács: szerezz be egy SQL könyvet
- A hozzászóláshoz be kell jelentkezni
Igen van konyvem, sot olvasgatom is oket...
Nem is arrol van szo hogy nem tudom megoldani csak mivel nincs tapasztalatom, es nagy terhelesu lessz a dolog, vagyis igazabol csak remelem hogy az lessz, jo lenne minnel optimalisabb megoldasokat hasznalni, hogy ne kelljen gyorsan az elejen javitgatnom.
- A hozzászóláshoz be kell jelentkezni
"ne kelljen gyorsan az elejen javitgatnom." programozásban ... tyűűű webfejlesztésbe... mindig akad javítani való :) annak so sincs vége, csak eleje.
- A hozzászóláshoz be kell jelentkezni
Persze tudom en azt. Arra akartam erteni hogy azert most fejlesztes kozben mar eleve ugy kell megirnom hogy ahol csak lehet minnel jobb megoldasokat hasznaljak. Es ennel az utolso kerdesemnel is pont errol van szo mint ahogy irtam is az a legfobb kerdes hogy ez a megoldas igy jo-e vagy van tole jobb, ami kevesbe terhelne le majd eles hasznalatban a szervert.
- A hozzászóláshoz be kell jelentkezni
Azért valamit valamiért, ha azt akarod, hogy ne terhelje le a szervert akkor a legjobb, ha mindet adatot statikusan tárolsz/cache-elsz. Csak hát ez eléggé macerás tud lenni, plusz egy csomó újabb hibaforrás.
Pl. egy count-os select-et megírni nem tart semeddig, de ha nagy lesz az adatbázis lassú lehet.
Viszont ha cache-elsz, figyelni kell egy csomó mindenre, új tétel hozzáadása, törlés, áthelyezés, ha mögé kell nyúlni az adatbázisnak kézzel kell megcsinálni a cache eljárás, ... És megcsinálni is tovább tart mint egy sima select.
- A hozzászóláshoz be kell jelentkezni
Volna egy ujabb gondom. Vegeredmenyben a SELECT mukodik csak igy nekem a php -ban kell kiszednem a lenyeget, vagyis nem szep a dolog ...
Arrol lenne szo hogy egy tablaban tarolom az oszes adatot kiveve a leirasat mert az tobbnyevu is lehet es a kepeket mert abbol is tobb lehet. Van egy ehhez hasonlo lekerdezesem amivel a fo_tabla minden egyes sorahoz hozzacsapom a (jelen pillnantban magyar) leirasat es a kepeket. Nekem a fo_tabla minden egyes sorahoz csak 1 kep kellene (akarmelyik de ha random valtozna meg jobb lenne), viszont nekem ezzel a lekerdezessel a fo_tabla minden egyes sorat megkapom mindegyik keppel. Nem tudom mennyire vagyok ertheto pl. fo_tablaban csak 2 sor van es mindkettonek van 3 kepe akor a lekerdezesben 6 sot kapok viszont nekem csak 2 sor kellene...
SELECT fo_tabla.* , kepek.fajlnev AS fajlnev , leirasok.cim AS cim FROM fo_tabla LEFT JOIN kepek ON (kepek.uid = fo_tabla.uid) LEFT JOIN leirasok ON (leirasok.id = fo_tabla.uid AND leirasok.lang = 'hu')
A masik gondom az hogy ha pl magyarul nincs leiras parositva a fo_tabla bizonyos sorahoz akkor nekem kulon kell lekerdeznem azt a sort masik nyelven. Hogy kell az olyasmit megoldani hogy ha pl a fenti select -ban a leirasok reszeben a join -nak ha nincs leirasok.lang = 'hu' akkor legyen pl leirasok.lang = 'en' vagy akarmelyik masik mai van? Hogyan induljak el merre keresgeljek? Ha pl beirom hogy leirasok.lang = 'hu' or leirasok.lang = 'en' akkor itt is mint a kepnel 2 sort kapok amit ismet a php -ban kell feldolgoznom ...Valami olyasmit szeretnek hogy ha van leirasok.lang = 'hu' akkor azt ha nincs akkor leirasok.lang = 'en' es ha az se nincs akkor ami van ...
- A hozzászóláshoz be kell jelentkezni
s/LEFT JOIN/INNER JOIN/g
?
--
()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.
- A hozzászóláshoz be kell jelentkezni
Ezeket a JOIN -os dolgokat nezegettem mar par alkalommal mielott ide irtam volna de sajnos nem lattam a megoldast ...
A kerdesem elso reszet megoldottam ugy hogy bevezettem a fo tablaba egy ujabb mezot ami a masik tablaban levo primaris kulcsra mutat es ugy nez ki ez igy meg jobb megoldas is lett :)
Viszont a kerdesem masodik resze a tobbnyelvu leirasal meg sajnos megoldasra var ...
- A hozzászóláshoz be kell jelentkezni
Ja, hogy mindketto primary volt, es kozuk nem volt egymashoz? Hat igen, az ugy szivas. Adatbaziselmelet alapok konyvet fusd at.
Masodik resz: (elnezest a tordelesert, de randa volt a gorgetosav)
SELECT fo_tabla.* , kepek.fajlnev AS fajlnev , leirasok.cim AS cim FROM fo_tabla
INNER JOIN kepek ON (kepek.uid = fo_tabla.uid) INNER JOIN leirasok ON
(leirasok.id = fo_tabla.uid) WHERE leirasok.lang IN ('hu', 'en')
Ketto dolog valtozott:
- A JOIN feltelebol kiszedtem a nyelvre szurest, annak ott semmi keresnivaloja nincsen. Lehet ezert szerencsetlenkedtel a JOIN-okkal is.
- A leirasok.lang szurest atalakitottam IN-esre. Lehetne persze OR kifejezes is (leirasok.lang = 'hu' OR leirasok.lang = 'en'), csak azt kesobb nehet boviteni, mert nem eleg az elem neve hozza, igy viszotn gyak egy tombot kell a parametersorba tolni. Asszem sorrendi prioritas van, vagyis eloszor az elsot, masodszor a masodikat nezi meg.
--
()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.
- A hozzászóláshoz be kell jelentkezni
Ja, hogy mindketto primary volt, es kozuk nem volt egymashoz? Hat igen, az ugy szivas. Adatbaziselmelet alapok konyvet fusd at.
De igen volt kozuk egymashoz. A fo tablaban az egyik mezo mutatott a kepek tablaban az egyik mezore ami indexelve volt az szerint. Nem unique mert a fo talba egy sorahoz tobb kep is tartozhat. En most azt csinaltam hogy kinveztem a kepek kozul egyet amit nevezzek fo kepnek es a fo tablabol egy mezo mutat arra a kepre ...Ugyhogy a kerdes kepes resze valojaban ezzel targytalan lett, az mar jol mukodik.
2.) ... WHERE leirasok.lang IN ('hu', 'en') megoldas azert nem jo mert akkor ha pl. megvan a leiras mindket nyelven (magyarul is es angolul is) akkor a lekerdezesben 2 sort kapok vissza ...Nekem viszont az kell hogy csak 1 sor legyen. Pl. ha van magyar akkor csak a magyar es ha nincs akkor csak az angol es esetleg ha az se nincsen akkor ami van ...de akkor is csak 1 sor legyen ...
Megprobalom pontosabban megfogalmazni a lenyeget :) arrol van szo hogy egy magyar latogato a kepnel magyar leirast lasson es csak ha valami oknal fogva nincs magyar leiras akkor kapjon pl. angol leirast. Es forditva angol nezelodo csak akkor kapjon magyart ha nincs angol.
Itt a fenti IN reszt el is hagyhatom ezzel az erovel mert a leiras vagy magyar vagy angol vagy mindketto lessz es igy ha elhagyom akkor is ugyanaz lessz az eredmeny....
- A hozzászóláshoz be kell jelentkezni
(magyarul is es angolul is) akkor a lekerdezesben 2 sort kapok vissza ...Nekem viszont az kell hogy csak 1 sor legyen. Pl. ha van magyar akkor csak a magyar es ha nincs akkor csak az angol es esetleg ha az se nincsen akkor ami van ...de akkor is csak 1 sor legyen ...
order by ... limit 1
- A hozzászóláshoz be kell jelentkezni
Csak az utolso bekezdesre reagalnek: nem, nem hagyhatod el, mert ha a kesobbiek soran igeny merul fel mondjuk klingon (kl) nyelven torteno leiras irasara, akkor mar klingon nyelvu is johet vissza.
Egyebkent meg nem ertem a problemadat meg mindig. Oke ket sor jon vissza, na es? Az egyiket felhasznalod, a masikat eldobod. Nem otezer megagigabajtos anyagok jonnek vissza, hogy kar lenne ertuk, vagy a memoriaert.
--
()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.
- A hozzászóláshoz be kell jelentkezni
Oke ket sor jon vissza, na es? Az egyiket felhasznalod, a masikat eldobod. Nem otezer megagigabajtos anyagok jonnek vissza, hogy kar lenne ertuk, vagy a memoriaert.
Most ravilagitottal a lenyegre :) Szoval mint irtam is eppen azt szerettem volna hogy csak 1 sort kapjak vissza, eddig is ugy oldottam meg hogy magaban a php -ben a megfelelo sort dolgozom fel. Es eppen azert gondoltam hogy talan van valami (a mostanitol) jobb megoldas es mar a mysql csak a megfelelo nyelven levo leirast adja vissza ...
- A hozzászóláshoz be kell jelentkezni
-
- A hozzászóláshoz be kell jelentkezni