Aktív témák
-
cucka
addikt
Egyébként a szerver ugyanabban a formában tárolja az adatokat, mint ahogy .sql-be le lehet menteni myadmin-ból?
Nem. A MySQL binárisan tárolja az adatokat, az sql-ben történő mentés pedig egy sql scriptet eredményez. Amúgy ezt hogy képzelted, hogy az adatbázis file-jában "insert into.." sorok találhatók és azokban vannak az adatok, amin dolgozik a mySQL?
A phpmyadmin-ban amúgy írja, hogy melyik tábla mennyit foglal. 50 mega nagyon sokra elég, ha mégis kifogysz a tárhelyből, akkor pedig majd szólsz a rendszergazdának, hogy többre van szükséged, szóval kár ezen pörögni.Minden cikknek, és képnek külön táblája legyen, ahol a hsz-ek vannak, a pontszámokat meg külön táblában tároljam?
Kell egy cikk tábla, benne egy id mezővel, ami azonosítja a cikket.
Kell egy képek tábla, amiben van egy cikk_id mező, ami megmondja, hogy melyik cikkhez tartozik az adott kép.
Kell egy hozzászólás tábla hasonlóan a képekhez.A pontszámokat tárolhatod egy külön táblában (ilyenkor eltárolod az összes szavazás értékét). A másik megoldás, hogy a cikk táblába lerakod az átlagot és a szavazatok számát, új szavazatnál ezt frissíted.
Kb. ennyi. Így minden cikkhez tetszőleges számú képet és hozzászólást tudsz eltárolni.
-
#1600
Louloudaki
aktív tag
Bici
#1598
Louloudaki
aktív tag
háttőőő nekem van egy 4000 soros adatbázisom, 18 táblával, a termékek és users tábla 14-15 oszlopos és az egész alig több mint fél mega. ebből tudsz kalkulálni. szerintem elég lesz. a galériaképeket ne blobban tárold
a nagyon régi cuccokat majd archiválod valahogy ha mégse elég de szerintem elég lesz. -
#1537
Louloudaki
aktív tag
Bici
#1536
Louloudaki
aktív tag
szard le. operát alig használ valaki, és mi az esélye annak statisztikailag, hogy valaki beregel valahova, majd otthagyja az oldalt/böngészőt nyitva és más odamegy, backet nyom és újra használja? nullához konvergál... koncentrálj végre a lényegi részekre mert év végiég se leszel meg a cuccoddal ilyen tempóban.
-
cucka
addikt
Mysql-ben stringekre varchar-t használunk, nincs sok értelme nchar-t használni. (Az nchar annyival több, mint a sima char, hogy alapból utf8-as kódolású, hacsak a rendszergazda át nem állította ezt a beállítást). [link]
Set names, set character set és hasonlókat minden esetben közvetlenül a mysql_connect után add ki egyszer. (Tehát nem minden egyes query előtt) -
Nos, változatlanul nem műxik, akármit szenvedek.
- Az sql fájlból feltöltött utf8-as adatbázis a weben rosszul jelenik meg, de a phpmyadmin jól mutatja.
- A webről feltöltött mezők viszont jól jelennek meg a webről visszanézve, de a phpmyadmin, és a belőle exportált sql file is csupa krix-krax.Már 100%, hogy a szerver beállításai nem jók, mert az extra.hu-n oda-vissza tökéletes - minden utf8-ra, vagy uft8-general-ra van állítva, ahogy a saját tárhelyen is.
Ezeket találtam a phpmyadmin infói között azon a tárhelyen, ahol működnie kellene:
[link] & [link]
Nem kellene mindennek utf8-ban lennie? (nekem az alsó adatbázissal van dolgom)
Ezen tudok változtatni?Köszi!
-
-
"A set names utf-8 még nem volt, de kipróbálom. Ez beleszólhat a szövegbevitelbe is?"
Erről konkrétan úgy tudom, hogy az aktuális kapcsolat karakterkódolását határozza meg. Nekem ugyanez volt a problémám még az elején, amikor tanultam mysql-t, mint neked. Szóval elvileg megoldja, ha a karakterkészlet is utf8_general_ci, ahogy Cucka is mondja.
(#1520) cucka: Hát igen, az úgy gáz. Egyébként a szolgáltatók nagyon hajlamosak ősi rendszert pénzért árulni. Pl A*W-nél is php4 és mysql4 van, a sima webtárhelynél (fizetős és nem fizetős is).
-
cucka
addikt
Tovább olvastam a topikot..
Miután a php-ban csatlakozol az adatbázishoz, futtasd le a set names utf8 query-t.
A char-varchar különbséget kipróbáltam, nálam jó.
Ugye nem valami ősrégi mysql-t használsz? 4.valahányas verzió előtt a varchar hosszát nem karakterekben, hanem byte-okban mérte.
Esetleg utf8_unicode_ci helyett próbálj utf8_general_ci kódolást használni. Unicode-osat soha nem használtam még, de a general-al még nem voltak ilyen problémáim, mint neked. -
cucka
addikt
Char helyett használj varchar típust a szöveges mezőknek.
A char előre lefoglalja a megadott karakterszámnyi helyet. A gond valószínűleg az lesz, hogy egy utf8 karakter 1 vagy 2 byte-ot foglalhat, a mysql pedig 1 byte-al számol, amikor előre lefoglalja a helyet. (Ezt igazából nem próbáltam, szóval lehet, hogy más lesz a gond, de logikus magyarázatnak tűnik ) -
Kifutottam az időből.
Szóval a saját weblapomról nézve jól jelenik meg, csak fele annyit ment el, mint ami beleférne a mezőbe.
Csak a phpmyadmin-ből nézve adódik a linkelt hiba.Az adatokat a webes felületről töltöttem fel, ami utf-8-as. A fájlok, és a html fejléc is.
A set names utf-8 még nem volt, de kipróbálom. Ez beleszólhat a szövegbevitelbe is?
"Ja és a weblapon ha megnézed az oldal kódolása UTF-8-on van?"
A HTML fejlécre gondolsz?
Mert az ilyen:<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> -
-
zhagyma
őstag
Normális lehet. Egy unicode karakter (UTF-16) 2 byte-t foglal el. Ha egy unicode karaktert beírsz egy html oldalba, akkor több byte-t is elfoglalhat. Valami ilyesmi kódokat látsz?
[C]
<p></p>
<p>XHTML karakter kódok (ISO 8859-2, latin 2)</p>
<p>á - á</p>
<p>Á - Á</p>
<p>é - é</p>
<p>É - É</p>
<p>í - í</p>
<p>Í - Í</p>
<p>ó - ó</p>
<p>Ó - Ó</p>
<p>ö - ö</p>
<p>Ö - Ö</p>
<p>õ - ô</p>
<p>Õ - Ô</p>
<p>ú - ú</p>
<p>Ú - Ú</p>
<p>ü - ü</p>
<p>Ü - Ü</p>
<p>û - û</p>
<p>Û - Û</p>
<p>UNICODE karakter kódok (UNICODE: latin1 U0080, latin extended-A U0100)</p>
<p>UTF-8 kodolas</p>
<p>000 - 127 ASCII</p>
<p>128 - 255 LATIN 1</p>
<p>255 felett - hosszu ö</p>
<p>255 felett - hosszu ü</p>
<p>á - á</p>
<p>Á - Á</p>
<p>é - é</p>
<p>É - È</p>
<p>í - í</p>
<p>Í - Í</p>
<p>ó - ó</p>
<p>Ó - Ó</p>
<p>ö - ö</p>
<p>Ö - Ö</p>
<p>õ - ő</p>
<p>Õ - Ő</p>
<p>ú - ú</p>
<p>Ú - Ú</p>
<p>ü - ü</p>
<p>Ü - Ü</p>
<p>û - ű</p>
<p>Û - Ű</p>
[/C] -
cucka
addikt
- először beolvasom az öszeset mysql_query-vel, és utána mysql_fetch_array-el listázom,
vagy
- már a mysql_query-vel is csak annyit olvasok be, amennyit ki akarok írni?
Értelemszerűen ha van 1 millió sorod és csak 30-at akarsz kiírni, akkor nem kéred le az összeset az adatbázisból.A kérdés, hogy hogy érdemes rendszerezni a képeket, hogy a szervert ne terhelje nagyon.
Ahogy jól esik. Szerinted tényleg az terheli a szervert, hogy egy könyvtárban 100 vagy 200 kép van? Amíg nincs 10-20ezer képed, addig kár ezen pörögni, bőven elég, ha logikusan gondolkozol és jó kódot írsz.
Egy átlagos webszervert egy ésszerűen megírt, párezer soros adatbázisból és párszáz képből álló oldal kb. egyáltalán nem terhel le, szóval ne pazarold az idődet arra, hogy azon agyalj, mi mennyire terheli a gépet. -
Hopp, kifelejtettem valamit.
Képeket szeretnék feltölteni a szerverre. Scriptet találtam.
A kérdés, hogy hogy érdemes rendszerezni a képeket, hogy a szervert ne terhelje nagyon.
Valami olyasmit hallottam, hogy ha egy könyvtárban sok a kép, akkor belassul, mert az egész könyvtárat beolvassa, vagy csak a neveket, vagy ilyesmi.
Guglizok, de hátha gyorsabban tudtok valami okosat.Köszi!
-
cucka
addikt
A fordfairlane által írt kód alapján indulj el.
Kicsit átfogalmazom. Van egy regisztrációs folyamatod, amit mondjuk képzelj el úgy, mint egy windows-os varázslót. Első állapotában ott a regisztrációs űrlap, második állapota a regisztrációs folyamat vége. Ha az űrlapot hibásan töltöd ki, a varázsló nem ugrik át a második állapotra.Sematikusan így néz ki a reg.php
//post-olt adatok ellenőrzése, amennyiben már nem regisztrált a tag
$eredmeny = (empty($_SESSION['regisztracio_sikeres']) ? adatok_ellenorzese($_POST) : true;
if ($eredmeny===true){
// az adatok jók, tehát berakod a regisztráló tag adatait az adatbázisba
adatok_mentese();
//elmentjuk a session-ben, hogy már sikerült az adatbázis
$_SESSION['regisztracio_sikeres']=1;
//kiirjuk a "kikuldtuk a szöveget" html-t
require('regisztracio_vege_sablon.php');
} else {
//kiirjuk a regisztracios urlapot.
require('regisztracio_urlap_sablon.php');
}A regisztrációs űrlap a korábbi adatellenőrzés, a $_POST vagy a session alapján találja ki, hova milyen hibaüzenetet kell írni (ha kell egyáltalán). Sablon alatt itt azt kell érteni, hogy ott csak html kód, illetve a html kód megjelenítéséhez szükséges php részek vannak, maga az adatfeldolgozás nem.
A kódot igyekeztem érdekesre venni, a ?: és az === operátornak, az empty függvénynek, az include és a require közötti különbségnek nézz utána. -
#1482
fordfairlane
veterán
Bici
#1480
fordfairlane
veterán
Mutatok egy egymezős skeleton modellt, én így csinálnám:
<?
if($_SERVER["REQUEST_METHOD"] == "POST") {
if(!$_POST["nev"]) {
$error["nev"] = "A név üres";
} else {
$res = mysql_query('SELECT COUNT(*) FROM felhasznalok WHERE nev="'.mysql_escape_string($_POST["nev"]).'"');
if($res && mysql_num_rows($res)) {
list($no) = mysql_fetch_row($res);
if($no) $error["nev"] = "Ez a felhasználónév már foglalt!";
}
}
// további ellenőrzések
if(!$error) {
$query = 'INSERT INTO felhasznalok SET ';
$query .= 'nev="'.mysql_escape_string($_POST["nev"].'"';
// további mezők queryhez fűzése
mysql_query($query);
header("Location:".$_SERVER["SCRIPT_NAME"]."?ok=1");
exit;
// ez az átirányítás azért kell, hogyha az oké üzenetre refresht nyom,
// ne kapjon hibaüzenetet, miszerint ez a felhasználónév már foglalt.
// felhasználók lassú reagálású oldalnál hajlamosak refreshelni
}
} elseif($_GET["ok"]) {
include("fejlec.php");
?><p>Minden oké</p><?
include("lablec.php");
} else {
include("fejlec.php");
?>
<form method="post">
<input type="text" name="nev" value="<?=htmlspecialchars($_POST["nev"])?>" /> <?=$error["nev"]?><br />
<input type="submit" value="Regisztráció" />
</form>
<?
include("lablec.php");
}
?>Remélem nem maradt ki semmi, nem próbáltam ki. 19 mezőnél persze nem biztos, hogy célszerű így ömlesztve, de a vezérlési szerkezetet ebben a formában szoktam csinálni. Így egy oldalban benne van:
1. form kirakása, hiba esetén a mező tartalma megmarad, és a mező mellett megjelenik a hibaüzenet.
2. Ha minden oké, kirakja az oké szöveget, meg ami kell.
3. refresh esetén nem produkál mást, mint első betöltődésnél, ez a sikeres submit után okozhat problémát, a felhasználó megzavarodhat a nem várt üzenetektől.Fejlécet és láblécet külön fájlból szedi be, ez ízlés szerint változtatható (include("fejlec.php") és include("lablec.php"));
-
cucka
addikt
Azért ugyanoda, hogy pl. a reg.php újratöltésekor (F5) ne regeljen mégegyet, és ne is fárassza a felhasználót azzal a szöveggel, hogy már foglalt a név, inkább legyen üres a sok mező
Session-ben eltárolod, ha sikerült a regisztráció. A fárasztó üzenetek csak akkor jelennek meg, ha a session-ben nincs meg a kérdéses érték.Ott tartok, hogy megy a reg, POST-al átadom a cuccot a ment.php-nak, és ha valami gebasz van, akkor a ment.php beinclude-olja a form-ot tartalmazó php fájlt (ami őt meghívta) és egy globális változó segítségével visszaadom neki, hogy mely hibaüzeneteket kell kiírnia.
A reg.php adatait lehetőleg a reg.php-val ellenőrizd. Ha az ellenőrzés sikerült, akkor include-al a "sasold a mailed" oldalt rántod be, különben a regisztrációs űrlapot.Amiben viszont most elakadtam, hogy hogy tudom az ellenőrzés után visszaírni a mezők adatait a helyükre
Mezők kiírásánál megnézed, ott van-e a POST-ban a korábbi érték, ha igen, akkor beírod az értéket az űrlap elem megfelelő részébe. Ha bonyolult a navigáció (pl. több oldal megtekintése után is visszakeveredhetsz az űrlapos oldalra, és akkor is ott kell legyen az utolsó állapot), akkor pedig az elpost-olt adatokat rakd le a session-be, az űrlapod pedig mazsolázza ki onnan a rá vonatkozó adatokat.Lehetőleg úgy akarom megoldani, hogy fürge legyen az oldal, és ne terhelje a szervert a kelleténél jobban.
Ezen egyelőre ne görcsölj szerintem, a fentiek alap műveletek, szerver terhelésük konvergál a nullához.Ja, és alap jótanács - a session-t lehet bátran használni, sok dolgot könnyebb vele megoldani, mint mindenféle trükközéssel.
-
#1477
fordfairlane
veterán
Bici
#1475
fordfairlane
veterán
Ezek szerint ajax+post nem is működhet egyszerre?
Működhet, de az nem világos, hogy miért az ajaxot akarod használni a felhasználónév ellenőrzésére? Nem mondom, hogy olyan bonyolult lenne, de nem is egyszerű dolog, különösen neked nem, hiszen most kezdtél el foglalkozni a PHP-vel. Ahhoz, hogy bánni tudj az ilyen összetettebb dolgokkal, sok tapasztalat kell, jobban át kell látnod, hogyan zajlik a böngésző - szerver interakció, és nem csak szerve-, hanem kliensoldali programozásra is szükséged lesz.
Szerintem első körben a form - submit után hajtsd végre a felhasználónév foglaltságának ellenőrzését, és ha foglalt, jelenítsd meg a formot a begépelt adatokkal, és a hiba üzenettel. Erre amúgy is szükséged lesz, hiszen lehet más probléma is a felvitt adatokkal, pl. nem töltött ki kötelezően kitöltendő mezőket stb... Ez egy klasszikus form - validálás feladat, ha kell, segítek a részletekben, de a haladó technikát (AJAX) inkább csak akkor ajánlom, ha már ezek az alapvető dolgok rutinszerűen mennek.
-
cucka
addikt
A form-okkal nem értem, mit akarsz kezdeni. HTML-ben a formok úgy működnek, hogy küldéskor a form action-jében megadott url-je töltődik be. GET típusú űrlap esetén az url-hez hozzá lesznek csapva az űrlap változói, POST típusú űrlap esetén a HTTP üzenet POST részében lesznek megtalálhatók. Tehát jól látod, bármely HTML űrlap elküldése mindenképp oldal újratöltést fog eredményezni.
Az ajax általánosan úgy működik, hogy az oldal "megtekintése közben" egy url-re elküld valami adatot (ez mondjuk a php program, ami ellenőrzi, hogy helyesen töltötték-e ki az űrlapot). A php program visszaküld valami szöveget (ez tulajdonképpen a php program standard kimenete), amivel a javascript kódod csinál valamit (pl. az eredménytől függően kiírja, hogy jól töltötted-e ki az űrlapot vagy sem). Az ajax lényege, hogy ehhez nem kell újratölteni az oldalt, mert nem küldesz el semmilyen html űrlapot sehova.
Ha nagyon nem megy, később írok egy kis rövid ajax gyorstalpalót, amúgy is akartam valami közhasznút írni a logout-ra
-
cucka
addikt
Ezt meg lehet tenni úgy, hogy a második linken csinálják, vagyis, hogy mögé lehessen írni, hogy class=akármi...
Ezt nem értem, írhatsz elé-utána amit akarsz, de ha lefut a kérdéses esemény, akkor elküldi a form-ot, mint ha egy input type=submit-al küldted volna.Amúgy jobban megnéztem az első linkedet, hát azt sem ajánlom tutorialnak, a javascript kódjában nulla komment van, ráadásul a sima szabványos httprequest létrehozás helyett valami előre megírt, direkt olvashatatlanra alakított cuccot használ.
Most komolyan, így mi értelme a tutorialnak, ha a példa kódod direkt úgy van megcsinálva, hogy ne lehessen megérteni? Amúgy a hozzászólások is tök jók azon az oldalon, az emberek 98%-ának fingja nincs, hogyan működik a kód, de a legérdekesebb, hogy nem is nagyon érdekli őket. -
cucka
addikt
Az első megoldás ajax-os, abból lehet tanulni, csak ugye nem űrlapokkal dolgozik.
A másodikat kicsit erős tutorial-nak vagy cikknek nevezni. Annyit csinál, hogy amikor ráklikkelsz a linkre, a szövegdobozba írt szöveg alapján átirányít a search.php-ra.
Más szóval erről a negyed sornyi beágyazott javascript kódról szól a cikk, és amúgy semmi ajax nincs benne. (Ráadásul jó szarul is csinálja, mert elég lenne meghívni a form submit metódusát küldésre, és akkor menne POST-al is meg akárhány űrlapelemmel)Esetleg nézd meg ezt: [link]. A W3Schools-on is van javascript és ajax tutorial, azzal is lehet kezdeni.
-
#1448
fordfairlane
veterán
Bici
#1447
fordfairlane
veterán
Ez a sor szerintem mindenképp hibás:
$eredmeny = mysql_query( "SELECT * FROM fotabla WHERE felhnev = $sz ");
Kell valami $sz köré, ha a felhnev oszlop szöveg (varchar, text) típusú:
$eredmeny = mysql_query( "SELECT * FROM fotabla WHERE felhnev = '$sz' ");
vagy
$eredmeny = mysql_query( 'SELECT * FROM fotabla WHERE felhnev = "'.$sz.'"');
Az más téma, hogy van-e olyan felhnev érték, amire a query találatot ad. Nálad nem az a gond, hogy nincs találat, hanem hogy hibás a query.
-
#1446
fordfairlane
veterán
Bici
#1445
fordfairlane
veterán
Az előtte levő lekérdezés valami oknál fogva nem ad ereményt, így $eredmeny változó nem mysql result set típusú lesz. Lehet, hogy $sz változó üres, így a query string nem lesz helyes szintaktikailag. Illetve most nézem, bizonyára felhasználónév lesz benne. Akkor ez így nem jó, a queryben idézőjelek közé kell kerüljön a string.
-
cucka
addikt
Például itt egy Netpincér rendelés igazolás fejlécének spam-el kapcsolatos része. Ingyenes levelezőkkel nem tudom, mi a helyzet, olyannal nem teszteltem.
X-ELTE-VirusStatus: clean
X-ELTE-SpamScore: -0.4
X-ELTE-SpamLevel:
X-ELTE-SpamCheck: no
X-ELTE-SpamVersion: ELTE 2.0
X-ELTE-SpamCheck-Details: score=-0.4 required=5.9 tests=BAYES_00,SUBJECT_NEEDS_ENCODING,SUBJ_ILLEGAL_CHARS autolearn=no SpamAssassin version=3.2.5
1.1 SUBJ_ILLEGAL_CHARS Subject: has too many raw illegal characters
-1.5 BAYES_00 BODY: Bayesian spam probability is 0 to 1%
[score: 0.0000]
0.0 SUBJECT_NEEDS_ENCODING SUBJECT_NEEDS_ENCODINGAmúgy nyilván szerverbeállítás kérdése, hogy berakja-e ezeket a fejlécbe. Ha nagyon nem megy, küldd át a teszt levelet az adatlapomon látható címre és megmondom, mi a probléma a levéllel.
Mod: közben eszembe jutott, hogy jó lenne mutatni valami olyat, ami több ponton vérzik el a spamszűrőnél, szóval itt van egy valódi spam, amit hajszál híján megfogott a spamAssasin:
X-ELTE-VirusStatus: clean
X-ELTE-SpamScore: 5.7
X-ELTE-SpamLevel: sssss
X-ELTE-SpamCheck: no
X-ELTE-SpamVersion: ELTE 2.0
X-ELTE-SpamCheck-Details: score=5.7 required=5.9 tests=BAYES_50,HTML_MESSAGE,RCVD_IN_PBL,RCVD_IN_SORBS_DUL,RDNS_DYNAMIC,URI_HEX autolearn=no SpamAssassin version=3.2.5
0.4 URI_HEX URI: URI hostname has long hexadecimal sequence
0.8 HTML_MESSAGE BODY: HTML included in message
1.0 BAYES_50 BODY: Bayesian spam probability is 40 to 60%
[score: 0.5197]
2.5 RCVD_IN_SORBS_DUL RBL: SORBS: sent directly from dynamic IP address
[87.16.175.134 listed in dnsbl.sorbs.net]
0.9 RCVD_IN_PBL RBL: Received via a relay in Spamhaus PBL
[87.16.175.134 listed in zen.spamhaus.org]
0.1 RDNS_DYNAMIC Delivered to trusted network by host with
dynamic-looking rDNS -
-
cucka
addikt
A "szépség" alatt nem az esztétikát értettem, hanem hogy nem kezelted le, hogy a mysql_num_rows egyaránt visszatérhet false-al és 0-val is. Ettől még működőképes a kódod, valószínűleg soha nem fogod észrevenni a weboldal tesztelése során, hogy valami gond van vele, de ettől még nem 100%-osan helyes a fentiek miatt.
-
cucka
addikt
Például
select count(*) as cnt from tabla where nev='Rezső'
Pont ugyanannyira szerverkimélő, mint a te megoldásod, ugyanakkor rákényszerít a lentinél szebb php kód írására
Konkrétan azzal a mysql_num_rows-al van a baj:
Egyrészt így nem fog működni, mert meg kell adni neki a mysql_query által visszaadott resource-t. (jelen esetben a $eredmeny-t)
Másrészt ez a függvény egyaránt visszatérhet 0-val (nincsenek sorok) vagy false-al (hiba történt). Ha így rakod be a feltételbe, akkor mindkét esetben false-ra fog kiértékelődni, tehát a hibás esetet nem kezelted le. A felhasználói oldalon meg annyit látsz majd belőle, hogy bármit írsz be, el fogja fogadni, mint érvényes felhasználónév. -
cucka
addikt
Concat függvény.
select * from tabla where concat(mezo1,mezo2,mezo3) like '%szoveg%'
Nem a legjobb megoldás, nagy adatmennyiség esetén elég lassú lesz, de kis forgalmú oldalakhoz megteszi ez is. Ha ennél több kell, lehet trükközni, pl. létrehozni egy mezőt, amiben ott van az adott rekord összes szöveges adata és abban a mezőben keresni - ekkor a rekord beszúrásánál/frissítésénél ezt a mezőt is frissíted, cserébe megspórolod a concat-ot. Ezen kívül lehet cache-elni a kereséseket külön táblában, stb. Erre nincs igazából szabály, kreatívnak kell lenni.
-
Na, mégis:
Hogy tudok úgy keresni egy táblában, hogy nem csak egy mezőben, hanem az összes mezőben nézze meg?
OR-ral elálasztva pakoljam egymás mögé az összes mezőt?
Valami kelyettesítő szó, vagy karakter létezik? *-gal nem műxik.
Guglizok, de még nem találtam megoldást.Köcce!
-
#1413
fordfairlane
veterán
Bici
#1412
fordfairlane
veterán
Ezzel mindent lehet, új táblát létrehozni, meglévőt átvariálni, tartalmat szerkeszteni, keresni benne stb... de minimális relációs adatbázis ismeret, pl. MS Access nem árt hozzá. Kifejezetten Excel stílusú grides szerkesztőt nem ismerek. Én a SQLyogot használom [link], de ez nem webes, hanem telepíthető Win32 alkalmazás, és ez sem olyan, mint egy Excel.
-
#1411
fordfairlane
veterán
Bici
#1410
fordfairlane
veterán
Ilyenre gondoltál? Phpmyadmin
-
#1405
fordfairlane
veterán
Bici
#1403
fordfairlane
veterán
-
#1402
fordfairlane
veterán
Bici
#1401
fordfairlane
veterán
CREATE TABLE customer
(First_Name char(50),
Last_Name char(50),
Address char(50),
City char(50),
Country char(25),
Birth_Date date);Ez egy mysql query, nem php parancs, ennek megfelelően kell kezelni:
mysql_query("CREATE TABLE customer
(First_Name char(50),
Last_Name char(50),
Address char(50),
City char(50),
Country char(25),
Birth_Date date);"); -
#1386
fordfairlane
veterán
Bici
#1385
fordfairlane
veterán
Ezt a könyvet többen is dicsérték, én nem olvastam:
-
cucka
addikt
a phpmyadmin egy php-ban írt szoftver amellyel mysql adatbázisokat tudsz kezelni, gyakorlatilag egy olyan webes eszköz, amivel az adatbázisokat tudod matatni.
természetesen a szerveren fut, te böngészőből tudod elérni. próbáld ki és rájösz, hogy mire jó, konkrétan weboldal adminisztrálásához nem igazán megfelelő.
)
Aktív témák
Hirdetés
- Bomba ár! Dell Latitude E5570 Touch - i5-6300U I 8GB I 256SSD I 15,6" FHD I HDMI I CAM I W10 I Gari
- BESZÁMÍTÁS! GIGABYTE AORUS MASTER RTX 3070 8GB GDDR6 videokártya garanciával hibátlan működéssel
- Azonnali készpénzes AMD CPU AMD VGA számítógép felvásárlás személyesen / postával korrekt áron
- Csere-Beszámítás! AMD Ryzen 7 7700 Processzor!
- 129 - Lenovo Legion Pro 7 (16ARX8H) - AMD Ryzen 9 7945HX, RTX 4080
Állásajánlatok
Cég: Promenade Publishing House Kft.
Város: Budapest
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest