egy példa, hogy mire gondolok:

UPDATE FROM tblTransaction AS t
LEFT JOIN tblEmployee as e
ON e.emp_id = t.emp_id
SET t.emp_block = e.emp_block

Én kérek elnézést!

Hát egyelőre nem jött össze, pedig már próbálkoztam mindenféle baromsággal:
UPDATE (
SELECT t_o.main_picture AS main_pic
FROM `tbl_ossze` AS t_o
GROUP BY t_o.kutya_id
) AS t_o_mod
SET t_o_mod.main_pic = 'Y' ;

#1288 - The target table t_o_mod of the UPDATE is not updatable

Egyelőre nem tudom kitalálni a megoldást.
Lehet, hogy holnap, frissebb fejjel... de addig is ha van javaslatod, szívesen fogadom!

Sk8erPeter

Hali!

Lehet valamit felreertek, de szerintem nem sok ertelme van annak amit csinalni probalsz.

SELECT kutya_id AS kutyuli_id
FROM `tbl_ossze` AS tbl_ossze_2
GROUP BY kutyuli_id
Ennek a lekerdezesnek az eredmenye minden olyan kutya_id ami benne van a tablaban. Ha erre meg mukodne is az update, akkor csak azt erned el, hogy minden sorra beallitanad a 'Y'-t nem csak azokra amikre szeretned.

Amit te szeretnel, az valami ilyesmi lenne:
UPDATE `tbl_ossze` SET main_picture = 'Y' WHERE kep_id IN (
SELECT kep_id AS ki_id
FROM `tbl_ossze` AS tbl_ossze_2
GROUP BY kutya_id
)

Bar ez nem segit azon a tenyen, ahogy a hibauzenet is mondja, nem select-elheted es update-eleheted ugyanazt tablat ugyanabban a queryben.

Viszont, ha lenne egy inner temporal table-ed mar mukodne. Persze performance szempontjabol hagy kivannivalot maga utan, de ha jol sejtem ez a script egyszer futna le, szoval...

UPDATE `tbl_ossze` SET main_picture = 'Y' WHERE kep_id IN (
SELECT *
FROM (
SELECT kep_id
FROM `tbl_ossze`
GROUP BY kutya_id
) as temptable
)

[ Szerkesztve ]

''Gee, Brain, what do you want to do tonight?'' ''The same thing we do every night, Pinky: Try to take over the world!''

Nagy király vagy, shev7, pont azt csinálja, amit kell, köszi!

Teljesítményre: jaja, csak egyszer fut le, (Query took 0.0141 sec), nem tartott túl sokáig, mert nem olyan sok sorról van szó egyelőre.

Viszont most hirtelen azt nem értem, miért nem futott le az a lekérdezés, amit én írtam korábban:
UPDATE `tbl_ossze` SET main_picture = 'Y'
WHERE kutya_id IN (
SELECT kutya_id AS kutyuli_id
FROM `tbl_ossze` AS tbl_ossze_2
GROUP BY kutyuli_id
)
? ez ilyenkor nem ahhoz hasonlóan működik, amit Te is írtál, hogy lényegében egy táblát ad vissza eredményül, amely táblát módosítja a lekérdezés UPDATE része? Értem én, a para az, hogy azonos táblát akarok UPDATE-elni és SELECT-elni, de akkor a Te megoldásodban, ahol értelmezésem szerint a legbelső
SELECT kep_id
FROM `tbl_ossze`
GROUP BY kutya_id
visszaad egy táblát, ezt kérdezi le a középső
SELECT *
FROM (
SELECT .......
) as temptable

, ez is visszaad egy táblát, amit a külső

UPDATE `tbl_ossze` SET main_picture = 'Y' WHERE kep_id IN (
SELECT
.......
as temptable
)
megkap, és végül módosít.

Tulajdonképpen ez miben sokkal más, mint az, amivel én próbálkoztam eleinte?
Próbálom megérteni, hogy legközelebb már így álljak a kérdéshez.

Köszi!

[ Szerkesztve ]

Sk8erPeter

ezzel mas: as temptable

Igy letrehoz a memoriaban egy ideiglenes tablat, es a lekerdezest abban hajtja vegre majd az abbol kapott eredmeny alapjan update-el. Szoval itt az update es a select nem ugyanarra a tablara fut le.

''Gee, Brain, what do you want to do tonight?'' ''The same thing we do every night, Pinky: Try to take over the world!''

OK, köszönöm, sokat segítettél!

Sk8erPeter

Hi!

Ha VIEW-t hozok létre MySQL-ben, akkor nem megengedett a szögletes zárójelek segítségével megadott VIEW-név, ami whitespace-t is tartalmaz, ahogy egyes példákban (lásd pl. [Current Product List]) is látható?

az alábbi működött:
CREATE VIEW view_content_hun AS
SELECT content
FROM `tartalom_mod`
WHERE lang = "hun"
AND menupoint = "home"

de így már nem:
CREATE VIEW [legyen valami neve content_hun] AS
SELECT content
FROM `tartalom_mod`
WHERE lang = "hun"
AND menupoint = "home"

lásd KÉP
Annyi lenne a válasz, hogy MySQL-ben ez a fajta elnevezés nem támogatott? Vagy...?

Köszi!

[ Szerkesztve ]

Sk8erPeter

Szia!

Esetleg " " idézőjelek közé téve? Mintha MSSQL-ben, meg PostgreSQL-ben az " " jel lenne erre a megoldás. Bár érdemesebb inkább egybe írni, elvégre minek szivasd magad ilyen apróságokkal, nem?

Én kérek elnézést!

Ja persze, ez csak szimpla szakmai érdeklődés.
Amúgy biztos nem írnék szóközökkel telerakott neveket a kódomba, az valahogy annyira nem szerencsés.

Nos, kipróbáltam, úgy is ugyanazt a hibát dobja. Létezik, hogy MySQL-ben nem lehet ilyen módon szóközös neveket adni a VIEW-knak?

Sk8erPeter

Üdv!

Szóval, újratelepítettem a rendszerem (32 bites Win7-ről 64 bitesre), és az eddig jól bevált fejlesztőkörnyezetem most nem akar működni. mySQL Server 5.5 64-bit, Apache HTTP Server 2.2.14, és PHP 5.2.12

A PHP fordító és az Apache fut, mert a PHP-k lefutnak, de pl. a phpMyAdmin betöltésekor "The mysqli extension is missing" hibát kapok!

Tudnátok segíteni?

[ Szerkesztve ]

Segítek lefordítom: mysqli bővítmény hiányzik.

Komolyra fordítva a szót, mióta a legújabb xampp-t raktam fel, a mysqli nálam is elfelejtett működni. Valami inkompatibilitás van a legújabb mysql-lel, vagy a php-vel, vagy az apache-al? Végülis mindegy, a sima mysql működik, és nem vettem észre, hogy bármiben is rosszabb lenne a mysqli-nél. Ilyen ez az open source szarakodás, de legalább ingyenes a sok fos komponens.

Te egyébként komolyan fejlesztésre használod a phpmyadmin-t, vagy csak vicceltél?

Én kérek elnézést!

A lefordítása nekem is ment, köszi!

Egyébként igen, egy egész végigsz*pott nap után, július 1-én kabátban sz*á fagyva és szétázva azt gondoltam: miért ne dobnák be egy ilyen poént?!

Van ráadásul még egy: nekem a régen jól bevált XAMPP verzióm sem megy, szóval eljött annak az ideje, hogy számomra véget érjen a mai nap!

Majd holnap utánanézek, miért is nagy elvárás mySQL-t 64 biten futtatni!

Semmi baja nincs a mysql-nek a 64 bittel, nekem is azon fut.
A phpmyadmin-os kérdésem után már óvatosan kérdezem, mert nem tudom mikor viccelsz és mikor nem, de te most tényleg azt hiszed, hogy a mysql-ed ben van a hiba?

Mert a hibaüzenetet a php-d küldte, a mysqli az egy php bővítmény. De már tényleg elbizonytalanodtam, hogy ezzel most nem-e összezavarlak?
Azaz a mysql-ednek kutya baja, a php-hoz hiányzik egy bővítmény, azt kell pótolni. Bár ha le tudtad fordítani a hibaüzenetet, akkor miért nem értetted meg?

Mondjuk ettől függetlenül nem kétlem azt se, hogy nem megy a mysql-ed se, ha már ezt írtad, de akkor meg hogy jön ide a mysqli hiány?

Totál elbizonytalanítottál. Majd holnap, ha összeszedted magad, írd le hogy akkor most mi nem megy (PHP vagy a MySQL, vagy a kettő együtt nem megy, csak külön-külön)???

én biciklizve húztam le ezt a napot, és hidd el más is betegre melózza magát, csak nem hittem el, hogy a phpmyadmin-t a hoszting szolgáltatókon kívül bárki is használja, fejlesztésre meg pláne. Bearanyoztad a napomat ezzel

Én kérek elnézést!

"csak nem hittem el, hogy a phpmyadmin-t a hoszting szolgáltatókon kívül bárki is használja, fejlesztésre meg pláne. Bearanyoztad a napomat ezzel "
Már miért ne lehetne használni a phpMyAdmint vagy alternatíváit? Pl. ott a kisebb tudású, de kis erőforrásigényű, gyors, és próbalekérdezésekre, az adattáblák áttekinthető felületen való gyors megnézésére tökéletesen használható SQL Buddy is...
Már miért ne lennének ezek jók? Pl. a phpMyAdmin-felületen keresztül statisztikákat is lehet nézegetni, ha az ember kíváncsi rá. Az SQL Buddy kevesebbet tud, de ahogy eddig próbálgattam, egész megfelelő alternatíva az említett gyors célokra. Miért kellene ezekhez valami nagytudású, de legalább erőforrásigényes program? Vagy ha mégis van olyan alkalmazás, ami nem webes felületen keresztül működik, gyors, meg tud mindent, amit kell, az miért csökkentené a phpMyAdmin vagy ahhoz hasonló programok hasznát? Egyáltalán miért kellene élből hülyegyereknek nézni azokat, akik még mindig használják ezt is (mint én)?
Engem mondjuk a phpMyAdmin eléggé elavult, frame-es kialakítású szerkezete eléggé zavar, ezért is kerestem rá alternatívát, de ettől függetlenül tökéletesen megfelelőnek találom ezt és az ehhez hasonló programokat webfejlesztés esetén egyszerűbb célokra.
Ha valaki birtokában van némi adatbázis-kezelési ismereteknek, az nem feltételezi egyből azt, hogy robusztus, nagy vaddisznó programokat használ adatbázis-kezelésre, plusz hatalmas táblái vannak iszonyat komplex struktúrával, bonyolult összekapcsolásokkal, százsoros lekérdezésekkel, stb. Ettől még lehet jó fejlesztő. Vagy csak én értem félre, hogy eleve ujjal mutogatva kineveted azokat, akik még ma is használják a phpMyAdmint és társait...
Főleg, hogy az olyan csomagokhoz, mint az AppServ, XAMPP (Windows), WAMP és társai, általában ez szokott kapcsolódni, ezeket a csomagokat meg elég egyszerű telepíteni, ha az ember nem akarja szopatni magát feleslegesen az egyenkénti telepítéssel+konfigurálással (személy szerint az elsőt használom).

(#661) martonx :
"Végülis mindegy, a sima mysql működik, és nem vettem észre, hogy bármiben is rosszabb lenne a mysqli-nél. Ilyen ez az open source szarakodás, de legalább ingyenes a sok fos komponens."
Újabb hozzászólás, amit nem értek... A mysqli eleve objektumorientált használatot is lehetővé tesz, támogatja a prepared statementek használatát, és még elég sok minden elérhető vele, amit gondolom nem kell neked felsorolnom, mert sejtésem szerint van róla némi fogalmad...
Miért lenne ez egy "fos komponens"?

[ Szerkesztve ]

Sk8erPeter

Nem az a baj, hogy ezeket használod, én is használom a hoszting tárhelyeken. Na de ezeket fejlesztésre használni??? A szükség esetén használatával egyetértek, de amikor azt mondja valaki, hogy ezen fejleszt, az a szememben vicc kategória. Jó, mondjuk ki mit ért fejlesztés alatt. Két táblát létrehozni, meg köztük egy join-os selectre, valóban jó tud lenni bármi, még a mysql parancssora is. Ha már itt tartunk minek a phpmyadmin, ha ugyanezt tudja a parancssor is?

A mysqli többet tud, mint a mysql, viszont mysql is jó (ha akarod azt is beágyazhatod egy osztályba, és akkor megvan az objektum orientáltság is), és ott legalább nincsenek ilyen szívások, mint amikor én is pont a héten vettem észre, hogy a mysqli nem hajlandó a legújabb php, mysql, apache verziókkal működni. Egy rakás mysqli-s cuccal a gépemen nem volt felemelő felismerés.

Így magamban el is könyveltem fosként (ettől még nem kezdtem el átírni a régebbi munkáimat, hátha megint kijön majd egy stabil php - mysqli kombó), és egyszerűbb projektekben kerülni is fogom a használatát, mert az végképp nem hiányzik, hogy élesítéskor derüljön ki legközelebb, hogy az éles környezeten éppen nem hajlandó működni. A sima mysql-lel ilyen gonddal még sosem találkoztam.

Egyébként ha már phpmyadmin-t használ valaki fejlesztésre (lásd feljebb kéttáblás select), akkor nem mindegy, hogy mysql, vagy mysqli futtatja a végén a select-et?

Én kérek elnézést!

"Jó, mondjuk ki mit ért fejlesztés alatt."
Hát erről van szó... Lehet, hogy a srác csak ugyanarra használja, mint mi: néha megnézegetni a táblákat, lekérdezéseket futtatni, indexeket, kulcsokat megváltoztatni grafikus felületen, mert minek tökölni ilyennel mondjuk PHP-kódból?
Amúgy igazából Te sem tudom, mit értesz fejlesztés alatt, ezt kifejthetnéd.
Én pl. táblák létrehozására, azok összekapcsolgatásának próbálgatásaira is használom a phpMyAdmint vagy alternatíváit.
Most akkor ez szerinted megvetendő?

"Ha már itt tartunk minek a phpmyadmin, ha ugyanezt tudja a parancssor is?"
Ezzel csak az a probléma, hogy a legtöbb olcsó vagy ingyenes tárhely esetén egyszerűen nincs parancssor-elérés, SSH-val sem.

"ha akarod azt is beágyazhatod egy osztályba, és akkor megvan az objektum orientáltság is"
Jó, hát ilyen alapon mindenhez írhatsz wrapper osztályt, ami nem objektumorientált, ha azzal akarod szivatni magadat, hogy feltaláld a spanyolviaszt, és olyat implementálj, amit már valaki helyetted elkészített, és bőven készültek hozzá bugfixek is.

"ott legalább nincsenek ilyen szívások, mint amikor én is pont a héten vettem észre, hogy a mysqli nem hajlandó a legújabb php, mysql, apache verziókkal működni. Egy rakás mysqli-s cuccal a gépemen nem volt felemelő felismerés"
Ez melyik verzióknál jelentkezett nálad? Most már kíváncsivá tettél, kipróbálnám, nálam is problémás-e. Nálam jelenleg PHP 5.2.6 és MySQL 5.0.51b van fent, ezekkel mindjárt ki is próbálom, de előbb elmegyek kajálni.
Egyébként én személy szerint a PDO-t javaslom, ez is OOP-s, kényelmes, rugalmasan használható, nagytudású. Korábban én is sima mysql-es és mysqli-s funkciókkal szivattam magam, de a PDO használata után vissza nem térnék ezekre a módszerekre (bár a MySQLi-s módszerrel sincs sok baj).

Sk8erPeter

Nálam php 5.3.5 van, és MySql 5.5. akárhány van (amiket a legújabb xampp tartalmaz). Ha ezekkel megy neked a mysqli, akkor le a kalappal.

Én SQL fejlesztés alatt masszív tárolt eljárás írást értek kurzorokkal, deklarálásokkal, temporary táblákkal. Szeretem amennyire csak lehet adatbázishoz közel tartani a logikát. Aztán az már, hogy az adott tárolt eljárást mysql-lel vagy mysqli-vel hívom meg számomra kb. mindegy.

Mivel innentől kezdve a mysqli-t mellőzöm, a javasolt PDO-t ki fogom próbálni, felkeltetted az érdeklődésemet, köszi!

Én kérek elnézést!

Nincs mit!
Ja okés, így már más, az általad említettekhez mondjuk egy ilyen viszonylag egyszerű felület meg egy sima textarea a lekérdezések, stb. megírásához tényleg nem elegendő. Nekem még bőven van mit tanulnom, hogy az általad említetteket alkalmazzam, és több logikát ültessek át MySQL-re. Nálam egyelőre a logika nagy része PHP-ban dől el.
Te mit szoktál használni/mit javasolsz SQL-fejlesztésre?

Hmm, hát majd lehet, hogy virtuális gépre felpakolom az általad említett verziókat, hogy kipróbáljam, mert meglep, hogy nem megy a mysqli. Habár melós.

Sk8erPeter

Szeretem amennyire csak lehet adatbázishoz közel tartani a logikát. Aztán az már, hogy az adott tárolt eljárást mysql-lel vagy mysqli-vel hívom meg számomra kb. mindegy.
Szerintem ezzel az esetek többségében csak lábon lövöd magad.
Például ha használsz valamilyen verziókövető rendszert, akkor az hogy működik együtt az adatbázis tárolt eljárásaival? A tesztelés is nehézkesebb, mint ahogy release esetén is több meló van, több hibalehetőséggel.

A phpmyadmin pedig valóban nem a legjobb eszköz, mert ugye nem valami natív szoftver, hanem egy weboldal. Ettől függetlenül az esetek többségében a tudása megfelelő, és nem kell megoldani azt, hogy kívülről csatlakozz az adatbázis szerverhez. (Mert ugye általában nem lehet, marad a tunnel vagy a vpn, futhatod a köröket a rendszergazdával, stb.)

[ Szerkesztve ]

Toad for MySQL-t szoktam használni. Nagy tudású, debug-ot is tud.
MySQL-nek van valami ingyenes menedzsment felülete is, állítólag az se rossz, de még sosem próbáltam.
A Toadban azt szeretem, hogy a felületénél megadható, hogy hasonlítson az MS SQL Mangement Studio-hoz, így nem kell mindent máshol keresnem, mint ahol megszoktam.

Én kérek elnézést!

Toad for Mysql-ben egy kattintás és sql fájlban elmenti a komplett adatbázisomat. Ezt szoktam svn-ezni, sőt ezt szoktam futtatni az éles hoszting phpmyadmin-jában is.

A tesztelés is nehézkesebb??? Ezt hogy érted? Lehet sok PHP hívőt megsértek vele, de a PHP-t eleve nem egyszerű (mondhatni rémálom) tesztelni, debugolni.

Én kérek elnézést!

Toad for Mysql-ben egy kattintás és sql fájlban elmenti a komplett adatbázisomat. Ezt szoktam svn-ezni, sőt ezt szoktam futtatni az éles hoszting phpmyadmin-jában is.
Ez fasza, csak ha az éles adatbázisban ott vannak az éles adatok, akkor sokat nem érsz azzal, hogy a dev. adatbázisból csinálsz egy dumpot. Ha nagy az adatbázis, akkor megint csak szívsz ezzel az elgondolással.

Nem azt állítom, hogy nem lehet így fejleszteni, csak szerintem sok lehetséges szívástól kíméled meg magad, ha az alkalmazáslogika nagy részét nem az adatbázisban tárolod. (Arról nem beszélve, hogy így függetleníteni tudod magad az adatbázis szerver nyűgjeitől, gyakorlatilag az alkalmazást nem fogja érdekelni, hogy milyen típusú adatbázisból dolgozik)

A tesztelés is nehézkesebb??? Ezt hogy érted? Lehet sok PHP hívőt megsértek vele, de a PHP-t eleve nem egyszerű (mondhatni rémálom) tesztelni, debugolni.
PHP-hez vannak szép automatizált eszközök unit tesztekhez, nem tudom, tárolt eljárásoknál ez hogy van. (Elvileg nyilván megoldható, gyakorlatilag meg még nem próbáltam)

[ Szerkesztve ]

OK, köszi, majd kipróbálom.

Amúgy a másik témához: vannak debug-eszközök PHP-hoz bőven, bár tény, hogy nem olyan egyszerű debuggolni, mint mondjuk egy C-, C++-, C#-, stb. alkalmazást, más módszereket igényel. Szóval tényleg van vele szopás.
De ilyen alapon SQL-ben hogy debuggolsz? Kipróbálod, vagy jó, vagy nem.
Eszerint a PHP még mindig jobb egy fokkal.

Amúgy szerintem esetleges MySQL-memóriakorlátok miatt sem biztos, hogy érdemes átpakolni mindent adatbázis-oldalra (pl. olcsó vagy ingyenes tárhelyek problémája ismét), meg hát szerintem a rétegelésnek is megvan a maga haszna, hogy adatbázist elsősorban tárolásra használunk, legalábbis webalkalmazásoknál. Nyilván azért egyszerűbb tárolt eljárásokat bőven lehet írni.

Egyébként szerintem építő jellegű egy ilyen vita, úgyhogy mindenki elmondhatja a saját érveit, engem legalábbis érdekel, akkor is, ha nem értünk egyet. Olyan szempontokat is mondhattok, amik mondjuk nekem nem jutottak eszembe, így legalább részben előfordulhat, hogy bizonyos szempontokról meggyőzzük egymást. Vagy nem, de legalább kiveséztük a szempontokat.

Sk8erPeter

Ezzel a hibával mit lehet kezdeni?

Mindenki tudja, hogy bizonyos dolgokat nem lehet megvalósítani, mígnem jön valaki, aki erről nem tud, és megvalósítja. (Albert Einstein)

Tipp: Automatikusan kitöltött mező, melynek értéke nem lehet 0 / értéket kell adni?

"hacsak nem jön a jó tündér break utasítás képében..."

Először is kösz a választ, de nem jó a tipp...
Elnézést, csak szétb...sz az ideg ez miatt, és kicsit nagyon leegyszerűsítettem a kérdést. Szóval tudom a hiba okát: az a változó nem létezik 4.1-es mysql előtt. Na most amikor beszéltem az illetékes elvtárssal, érdeklődve többek közt a mysql verzió felől, akkor azt nyilatkozta, hogy a legújabbat használják. Most meg kiderült, hogy 4.0.24-es...

A problémát még tetézi, hogy egy fórum motort használtam, ha szerencsém lesz, akkor utólag tudok módosítani 4.0-ás mysql kompatibilitásra...
Nyilván a szolgáltatót nem kötelezhetem, hogy cseréljen mysql-t(bár illene)

Szóval a kérdés inkább úgy lett volna jó, hogy van-e valamilyen konverter, bármi, amivel a meglévő adatbázisokat "visszabutíthatnám"...

Még1x, elnézést a nagyon leegyszerűsített kérdésért...

[ Szerkesztve ]

Mindenki tudja, hogy bizonyos dolgokat nem lehet megvalósítani, mígnem jön valaki, aki erről nem tud, és megvalósítja. (Albert Einstein)

A programod jó eséllyel akkor is működni fog, ha kihagyod az sql script-ből azt a sort, ahol a hibát dobja.
A normális megoldás az adatbázis szerver frissítése, a 4.0.24 az egy ősrégi verzió, valószínűleg befoltozatlan biztonsági lyukak tucatjaival.

xdebug-ot én is használom, nem is azt mondtam, hogy PHP-t nem lehet debugolni, hanem azt, hogy sokkal nehézkesebb, mint más nyelveket. Egyébként SQL-t is lehet debugolni, legalábbis MS SQL-t 2008 fölött, illetve a MySQL-t 5-ös verzió felett.

Az indokaim, hogy miért jobb SQL szinten tartani az adatlogikát (félre értések elkerülése végett én sem 100%-ban SQL szinten valósítom meg, csak törekszek rá).

1. Az SQL nagyon buta, cserében bődületesen hatékonyan, akárhány szálra, akármennyi memóriára optimalizálva kezeli az adatokat, adatműveleteket. Rengeteg konkurens felhasználó kiszolgálására van optimalizálva, akárhány magot, akármennyi memóriát ki tud használni.

2. SQL szerverek általában jóval erősebb hardverek, mint a webkiszolgálók.

Hozhatnék itt ezeregy példát, ebben a fenti két pontban minden benne van, hogy miért érdemes az SQL szintre törekedni. És hangsúlyozom, nem a Pistike-féle olcsó hosztingokra gondolok, ahol egy Core2-es szerver egymaga a webkiszolgáló, és az adatbázis szerver is (bár kis mértékben, de az 1-es pont miatt itt is kijön az SQL-es megközelítés előnye), hanem a nagyvállalati infrastruktúrákra. Nálunk pl. a webkiszolgálók (igaz több is van belőlük), 1-4 processzormaggal és 2-4 Gb memóriával rendelkeznek. Míg a legkomolyabb SQL szerverünk 128 maggal, és 320 Gb memóriával rendelkezik.

Egy komolyabb programkód logika már néhány tíz konkurens felhasználónál kifekteti a webkiszolgálót, míg ugyanaz SQL szinten megvalósítva, mondjuk kisebb mint 5%-os processzorterhlést jelent az adatbázis szervernek, és emiatt szintén minimális terhet a webkiszolgálónak.

Én kérek elnézést!

Hát ez nehéz szülés volt, de most úgy ahogy...
Mint kiderült, ez egy kis cég és igazából ez az első honlap, ami a tárhelyükre kerül(szerveren 20 percet sietett a vekker, még sosem volt beállítva ). Hosszú telefonos beszélgetés alatt sikerült a saját /adatbázis jogaimat beállíttatni, hogy végre a phpmyadmin-ban is tudjak "mozogni"...

A feladat ezenfelül is kihívás, mert 100Mbyte tárhely áll rendelkezésre(adatbázissal együtt) és ebbe kell egy fórum-ot, meg egy külön weblapot belepaszíroznom, Beszélve a település polgármesterével, azt szeretnék, ha kb 5 évre visszamenőleg, az összes rendezvényről készült kép felkerülne a honlapra, van vagy kb 1000...

Azért néha jó is egy ilyen feladat, mert milyen unalmas is folyamatosan több gigás tárhelyekkel dolgozni, ahol hely hegyek, minden megy elsőre, gond nélkül... Teljesen ellustul szürkeállományilag az ember...

Mindenki tudja, hogy bizonyos dolgokat nem lehet megvalósítani, mígnem jön valaki, aki erről nem tud, és megvalósítja. (Albert Einstein)

Tárold külső helyen a képeket.

Flickr, Picasa ad saját API-t is, azaz úgy tudod a honlapba beágyazni, mintha tényleg ott lennének a képek. Cserébe kevés tárhelyet adnak.

Skydrive nem ad saját API-t, csak simán linkel tudsz oda mutatni, viszont baromi jó képnézegetője van, és 25 Gb tárhelyet ad. Én egy óvodának több éve ide töltöm fel a képeit és még mindig csak néhány Gigabájtot foglalnak.

Én kérek elnézést!

Sziasztok!

Van egy ilyesmi lekérdezésem:

SELECT lada,kod FROM tabla GROUP BY lada,kod;

Ennek hogy tudnám lekérdezni, hogy hány sort ad vissza?

Valami ilyesmi formában kéne, hogy csak egyetlen sor egyetlen mezőjében szerepeljen a sorok száma:

... AS cnt ...

MySql:[link]
MySQLi: [link]

"hacsak nem jön a jó tündér break utasítás képében..."

Köszi, de ez nem jó nekem. Azt szeretném, hogy a MySql adja vissza egy mezőben a sorok számát. Olyasmi kellene nekem mint a COUNT() ...

[ Szerkesztve ]

Igen! Köszönöm szépen!

Sziasztok!

Már jó régen nem jártam itt, de belefutottam egy dologba, amit nem bírok megoldani és ehhez kérem a segítségeteket....

Van három táblám: users, friends és pics.

Az első táblában vannak a userek, amit egyedi id azonosít.
A második táblában vannak a baráti kapcsolatok self és contact mezőkkel duplán (két felhasználó 2 sor pl.: 1 és 5 barátok, akkor id: 1 self: 1 contact 5 és id: 2 self: 5 és contact: 1). - Biztonsági okokból volt szükség rá...
A harmadik táblában a user id-k alapján vannak a felhasználók profil képei (location mezőben).

A probléma az, hogy le kellene kérnem egy adott user id alapján (legyen 999) azokat a usereket, akik nem szerepelnek a friends táblában és mellé csatolni a pics táblában lévő képek location mezejét is.

Az alapötletem ez volt, de ez nem jó:

SELECT
uu.*, upp.location
FROM
user as uu
LEFT JOIN pics as upp ON uu.id = upp.userid
INNER JOIN friends as uf ON uu.id!=uf.self AND uf.contact!=999
WHERE
uu.id != 999
;

Valakinek esetleg valami ötlete? (Már két órája próbálkozom és sürgős lenne....)

[ Szerkesztve ]

http://www.redsign.hu

Valami hasonló?
select users.*, pics.location from users
left join pics on (users.id=pics.userid)
where not exists
(select * from friends where friends.self=users.id or friends.contact=users.id)

[ Szerkesztve ]

SELECT
uu.*, upp.location
FROM
user as uu
LEFT JOIN pics as upp ON uu.id = upp.userid
LEFT JOIN friends as uf1 ON uu.id=uf.self
LEFT JOIN friends as uf2 ON uu.id=uf.contact
WHERE
uf1.id is null and uf2.id is null and uu.id = 999
;

ha jól értem

nem tudom, jol ertem-e, de le akarod kerni azon felhasznalok kepet, aki egy adott (ezesetben a 999-es) felhasznalonak nem baratai?

Igen jól érted...

jeges, cucka - Köszönöm a válaszokat, rögtön ki is próbálom...

http://www.redsign.hu

cucka - Ez sajnos nem lett jó... ...nem ad vissza találatot, pedig van 30 felhasználó, akiből csak 8 barát jelenleg...

jeges - Hát üres válasz jött vissza, igaz ezeket javítottam - jól tettem?:
LEFT JOIN friends as uf1 ON uu.id=uf1.self
LEFT JOIN friends as uf2 ON uu.id=uf2.contact

rt06 - Jöhet az ötleted...

http://www.redsign.hu

igen, persze, én nem írtam át

szerk: a where-ben lévő id=999 csak a te példád miatt van, azt ki kéne szedni

[ Szerkesztve ]

Köszönöm, igen átírtam és üres az eredmény...

http://www.redsign.hu

Szia!

Lehet nagyon mezitlábas megközelítés, és komplett sql-t sem fogsz kapni tőlem, de gondolom azt le tudod gyűjteni, hogy kik 999-es user barátai?
Nos ha ez megvan, akkor:

select k.helye from users u
inner join kép k on blablabla
where u.id not in (itt lesz a 999-es user barátainak legyűjtése, ami csak id-kat kell, hogy visszadjon)

Ez lehet nem a leghatékonyabb módja a legyűjtésnek, de hacsak nem az iwiw-nél dolgozol, akkor így is elég gyorsan le kell futnia a lekérdezésednek.

Én kérek elnézést!

Szia!

Köszönöm szépen a választ, közben én is erre az eredményre jutottam :

SELECT
uu.*, up.location
FROM
user as uu
LEFT JOIN pics as up ON up.userid=uu.id
WHERE
uu.id NOT IN (SELECT contact FROM friends WHERE self=999);

Hm, nagyobb terhelésű rendszer lesz, így lehet hogy majd később ki kell javítani, de most a célnak megfelel...

Köszönöm mindenkinek a segítséget!!!

http://www.redsign.hu

Sziasztok,

Azokat a rekordokat szeretném kilistázni amik régebbiek, mint 10 nap (Create_Time)
Itt alább a query, de valahogy nem igazán működik
Mi lehet a gond?

SELECT * FROM tdc_lc_lot_info where order_no like 'TDC%' and Create_Time < date_sub ('today',interval 10 DAY);

A tudást mástól kapjuk, a siker a mi tehetségünk - Remember: Your life – Your choices!

nem próbáltam ki, és nem írtad mit ad vissza, de nekem a 'today' nagyon gyanús. Ehelyett Currdate() vagy now() kellene, nem?

Én kérek elnézést!