- Android alkalmazások - szoftver kibeszélő topik
- iPhone topik
- Okosóra és okoskiegészítő topik
- 45 wattos vezeték nélküli töltés jön az új iPhone-ba
- Apple iPhone 16 Pro - rutinvizsga
- Xiaomi 13 - felnőni nehéz
- Keretmentesít a Galaxy S25 FE
- Magisk
- Milyen okostelefont vegyek?
- Samsung Galaxy A36 5G - a középső testvér
Új hozzászólás Aktív témák
-
#1216
Brown ügynök
senior tag
martonx
#1214
Brown ügynök
senior tag
válasz
martonx
#1214
üzenetére
Köszi, így már működik:
SELECT i.product_id, SUM( i.quantity ) ,
( SELECT SUM( quantity )
FROM stock_deliver_item
WHERE product_id = i.product_id
) AS deliver
FROM `stock_intake_item` i
GROUP BY i.product_idHogy NULL-al is működjön a subqueryben az IFNULL() függvényt lehet használni.
-
futár
senior tag
válasz
martonx
#1169
üzenetére
Simán átmásolva az6 új rendszerre dobta azokat a hibákat. NERO backuppal próbáltam megcsinálni, de akkor adatolvasási hibával leáll. Az adatbázisról van mentésem, valamint a program is megvan korábbról, csak más irányból próbáltam megközelíteni. Azt gondoltam csak én vagyok kevésbé otthon a MySQL-ben. Ezek szerint az egyetlen mód a partíció backup mentés és restore lehet? Lehet valamilyen más megoldás is?
-
#68216320
törölt tag
válasz
martonx
#1155
üzenetére
Csak egy minta volt, nem használom. Nem is futtattam le, mert az elv nem tetszett, hogy minden listázásnál/oldalfrissítésnél folyton kiszámolja ugyanezt. Természetesen vannak indexek.
Köszönöm a segítséget, de mint írtam már a táblaszerkezet esett át változtatáson és így nincs felesleges művelet. Csak akkor számoltatok vele, mikor tényleges változtatás történik és az eredményt update-olom. Így becslések alapján kisebb erőforrás igénye lesz, ugyanis lényegesen ritkább lesz az insert/update a select-nél. -
#68216320
törölt tag
válasz
martonx
#1148
üzenetére
SELECT
p.id AS pinceszet_id,
p.nev AS pinceszet_nev,
(
SELECT AVG(ertek_szam)
FROM ertekelt_borok
WHERE ertekelt_borok.bor_id=b.id
) AS pinceszet_boratlag
FROM pinceszetek AS p
LEFT JOIN borvidekek AS bv ON p.borvidek_id=bv.id
LEFT JOIN telepulesek AS t ON p.telepules_id=t.id
LEFT JOIN borok AS b ON b.pinceszet_id=p.id
LEFT JOIN ertekelt_borok AS eb ON eb.bor_id=b.idEzzel odáig jutottam, hogy listázza a pincészeteket, de amelyiknek a boraihoz mondjuk 5 értékelés van, akkor az 5 sort is ad vissza.
Illetve boronként kapom meg az átlagot minden sorban. -
#68216320
törölt tag
válasz
martonx
#1148
üzenetére
Az, hogy szerintem egymásba ágyazott SELECT-re lesz szükség, amit nem tudom hogyan csináljak meg.
A pincészetek listázása közben a pincészet ID alapján ki kéne jelölnöm az összes borát, azoknak az értékeléseiből pedig átlagot számolni, amit a pincészet többi adata mellett vissza kellene adnom. -
#1046
Sk8erPeter
nagyúr
martonx
#1045
-
#1020
Sk8erPeter
nagyúr
martonx
#1019
Sk8erPeter
nagyúr
válasz
martonx
#1019
üzenetére
- nyilván nagyon nagy méretű, komoly, sok-sokmillió rekordot tartalmazó adatbázisnál nem kezdenék el keresgélni egy stringet; az már vélhetően egy bejáratott, működő rendszer.
- ilyesmit nem illik művelni éles szerveren amúgy sem.
- szvsz nem biztos, hogy meg kell, hogy ölje az egész SQL-szervert a keresés, ha az ehhez tartozó alkalmazás normálisan van megírva: nem kell az összes adattáblát lockolnia addig, amíg végez. Elvileg egyetlen adatbázisban keresek, és a táblákon ciklikusan végig lehet menni, tehát egy lépésben csak egyetlen táblában keresek, string alapon, végignézve az összes szóba jöhető mezőt, kivéve ebből azokat, amiknek köze nincs a string típusú mezőkhöz (tehát elő sem fordulhat például az INT, DATETIME, stb. típusúak közt) - persze abban teljesen igazad van, hogy a string alapú keresés jó qrva lassú, és akkor is végig kell nézni a táblákat, és erőforrás-igényes az egész. Mégis meglepően gyorsan szokott végezni ezzel a phpMyAdmin, még amikor HDD-n volt az adatbázisszerverem, akkor is mindig meglepett, hogy akár 6500 találat esetén (amelyek több táblában voltak szétszórva) is nagyon gyorsan kész volt (de tény, nem tartok nagyon sokmillió rekordot tartalmazó adatbázisokat a gépemen!). Fogalmam sincs, hogyan van mindez megírva phpMyAdminban, de úgy tűnik, egész értelmesen; majd ha egyszer alkalmad nyílik rá, próbáld ki, csak úgy tesztelés gyanánt.
- hogy miért is lehet szükség minderre. Előfordul, hogy egy alkalmazást nem ismerek még teljesen, és ez felgyorsítja a megismerést. Például amikor egy CMS-ben felviszek néhány adatot sok-sok mezővel, kíváncsi vagyok, konkrétan milyen táblá(k)ba szórja szét azokat (pl. string jellegűeket), így meg rohadt gyorsan megtalálom, és mivel ezután tudom, melyik táblába, melyik mezőbe megy a cuccos, így magában a kódban is gyorsan rá tudok keresgélni, és el tudom kezdeni vizsgálgatni, mi is történik benne; kevesebb agyalás, hogy hol is logikus az egész dolog, kevesebb guglizás. Vagy mittudomén, költöztetted a webalkalmazásodat más domainre, alkönyvtárba, és kíváncsi vagy, vajon vannak-e még hivatkozások a korábbi elérési útra valamelyik tartalomban (például egy WYSIWYG-szerkesztőben a képet bepakoló plugin fosul volt beállítva, és teljes hivatkozásokat tákolt bele a tartalomba). De tudok még nyakatekertebb példákat is.![;]](//cdn.rios.hu/dl/s/v1.gif)
Mindenesetre nem egy hülyeség, hogy ilyesmit lehet egy GUI-n keresztül (ahogy lehet a phpMyAdminban), ahelyett, hogy kézzel kéne összeszenvedni a teljes kódot, mondjuk egy tárolt eljárással, ami tényleg megölheti az SQL-szervert, mert épp készülsz feltalálni a spanyolviaszt. -
#1018
Sk8erPeter
nagyúr
martonx
#1017
Sk8erPeter
nagyúr
válasz
martonx
#1017
üzenetére
Ezt most nem egészen értettem. Ki kíváncsi itt a DB szerkezetére?
Konkretizálva például arra vagyok kíváncsi, hogy adott adatbázison belül mely adattáblák mely mezői tartalmazzák azt a stringet, hogy "árvíztűrő tükörfúrógép" (csak hogy egy elvetemült példát mondjak). Hogy nyered ki ezt az information_schema-ból?
De ha meg is tudod ezt tenni, itt arról volt szó, hogy GUI-n keresztül (!!) hogyan lehet kényelmesen kezelni az adattábláidat, anélkül, hogy egyetlen sort le kéne írnod SQL-ben. -
#967
Sk8erPeter
nagyúr
martonx
#966
Sk8erPeter
nagyúr
Hát nem tudom. Sajnos az általad ajánlott Toad for MySQL sem jobb az én tapasztalataim alapján.
Nem biztos, hogy a phpMyAdmin okolható az általa tapasztalt probléma miatt (pl. arról nem esett egy szó sem, hogy kipróbálta-e simán, konzolról). -
#933
Sk8erPeter
nagyúr
martonx
#932
Sk8erPeter
nagyúr
"Teljesen érthető, amikor valaki felrak egy wampp-ot (linuxra érthető, windowsra minden esetben felelsleges)."
He? Nem értem a gondolatmenetet.
Ha Linuxban konzolon rámész, hogy mondjuk telepíteni akarod a phpmyadmint, akkor az összes függőséget is behúzza.
Windows-on meg végül is a külön telepítős macerát oldja meg az egyben telepítős módszer, ahogy a XAMPP is.
A WAMPP mozaikszóban az első pedig a Windows-t jelenti, de gondolom ezt nem kell külön mondanom. Akkor hogy érted, hogy Windows-ra ez felesleges? 
Mondjuk Windows-on én még mindig IIS+Web Platform Installer-párti vagyok, ott is behúzza a függőségeket, és számomra tisztább megoldás. Meg értem én, hogy live serverhez hasonló környezetet akar valaki felrakni, ami esetek többségében Apache-on lesz, ez elfogadható érv, de én sokszor inkább a tájékozatlanságnak tudom be, hogy nem használnak az emberek PHP-zésre IIS-t Windows-on.Most kipróbáltam az általad javasolt Toad for MySQL-t, mert eddig nem tettem, de én sok alapvető dolgot nem találtam meg így elsőre, vagy csak nem kézenfekvő helyen van.
Ilyenek, mint az adatbázis egyszerű átnevezése, adatbázis tartalmának egy klikkre történő átmásolása vagy éppen mozgatása másik adatbázisba. Lehet, hogy ezt exportálni kell először egy scriptbe, és aztán behúzni, de nehogy már... ez phpMyAdminban egyből ott van az arcodba tolva, beírod az új db nevét, és megcsinálja, no para. Be lehet állítani, hogy egyből át is váltson arra az adatbázisra. Aztán továbbmenve importálási lehetőség. Ez miért nincs egyből jól látható helyen? Egyáltalán hol van? Biztos csak türelmetlenül futottam át rajta, de ez azért eleve nem tetszik, hogy nincs ott, egyértelmű helyen. Aztán diagramok létrehozásánál pattog, hogy túl sok a tábla, egy beállítás korlátozza. Miért nem kérdezi meg egyből, mennyi táblára akarom korlátozni épp a megjelenítést? A sokat szidott phpMyAdmin "Diagram" opciójára kattintva egyből kirajzolja az összes táblát, még ha rengeteg is van, aztán ezeket ki lehet szedni, és utólag korlátozni, melyek jelenjenek meg, így gyorsan lehet relationt létrehozni táblák közt.Kezdem átértékelni, hogy mégsem akkora fos ez a phpMyAdmin.
Amúgy nekem a dbForge Studio for MySQL jött be, de arra meg ugye korlátos az ingyen liszensz.
-
#931
Sk8erPeter
nagyúr
martonx
#929
Sk8erPeter
nagyúr
Azért nem egészen olyan ez a helyzet, mint a hasonlatod.
Ha a WAMPP-ot telepíti, akkor abból sejthető, hogy elkezdte érdekelni a webfejlesztés, és most szétnézelődik, elkezd PHP-zni, nézegeti a MySQL-t, próbálgatja az Apache-ot, stb. Én is így kezdtem, csak én eleinte még szopattam magam azzal, hogy egyenként telepítettem őket, és próbáltam rájönni, hogyan kell őket konfigurálni, összehozni, miközben még lószart sem értettem az egészből. Egy csomó időt megspóroltam volna, ha egyszerűen telepítek egy WAMPP-ot, csak akkor még úgy voltam vele, hogy megpróbálom ezeket megismerni. Így utólag úgy gondolom, tök hülyeség ilyennel kezdeni, csak a tököd tele lesz vele már az elején. Miért ne lenne jó telepíteni egy WAMPP-ot? Egyáltalán nem értelek.
Főleg a gonoszkodó stílusodat vele szemben.
Kezdő, Te is voltál az.
Egyébként mi van akkor, ha telepíti a WAMPP-ot, talán megeszi a gépét? Értem én, hogy sok felesleges dolog is felmehet vele, de majd ha akarja, kiszedi utólag, és kész. Úgyis ki akarja majd próbálni élete első PHP-scriptjét, tehát kelleni fog az Apache és a PHP is. Mondjuk Windows-on én még mindig IIS-párti vagyok, de ez már másik kérdés.
Ettől még a kezdőnek ne vegyük el a kedvét, inkább segítsünk neki, nem kérdezett olyan vad dolgokat, nem az volt a kérdése, hogy "nem működik, mit tegyek?", hanem részletezte.Szerk.: mondjuk nem vagyok az ügyvédje, majd megvédi magát, csak ez már nekem is feltűnt.
Biztos neked is szarul esett volna, ha az elején jól beoltanak. -
#927
Sk8erPeter
nagyúr
martonx
#924
Sk8erPeter
nagyúr
Miért röhejes? Kezdőknek hasznos lehet, hogy nem kell szarakodni a külön-külön telepítéssel, egyben van minden, elindítod a setupot, next-next-csá. Van még pár ilyen gyorsan használható cuccos, mint az EasyPHP meg társai. Mondjuk Windows-on IIS + a Web Platform Installerrel is klattyolgatós felületen lehet ezeket telepíteni.
Azért egy kezdőt ne oltogass ilyen durván, ne vedd el a kedvét. Te is elkezdted valahogy, azóta a szokásaid nyilván sokat fejlődtek.
A phpMyAdmin lehet, hogy keveset tud, de a legtöbb hosting cégnél akkor is az van, nem árt, ha megtanulja kezelni.
A phpMyAdminban egyébként sztem az a nevetséges, hogy a mai napig framesetek használatára építenek, meg amúgy sem látok benne túl nagy fejlődést, már az is nagy számnak tűnt, hogy a jQuery UI-t kezdték el használni, meg AJAX-ot kezdtek el alkalmazni. Meg tényleg lassú.(#915) Bishoop :
tényleg "fura" az a tutorial, ahol ahelyett, hogy sql-dumpokat adnának a "kezedbe", inkább azt mondja, irányítsd oda a datadir-t... Lehet, hogy nem a legjobb segédanyag.(#920) Speeedfire :
tényleg könnyen feltörhető? -
#926
Speeedfire
félisten
martonx
#924
-
#853
Speeedfire
félisten
martonx
#852
-
zka67
őstag
Asszem megvan:
SELECT temp.maxdt,temp.user,readers.dir FROM (SELECT MAX(dt) AS maxdt, sid AS user FROM traffic GROUP BY sid) AS temp LEFT JOIN traffic ON traffic.dt=temp.maxdt LEFT JOIN readers ON traffic.reader=readers.id WHERE dir=0 ORDER BY temp.user;
Azért köszi a segítséget
-
pakriksz
őstag
értelmesen fogalmaztam, nyilvánvaló hogy nem egy telepíthető sql szerverprogramot keresek, mert azt nem kell keresni. Amazon RDS nem ingyenes, de regisztrálni sem lehet, mert szokásos amcsi cég módjára alapnak veszik a retkes dombornyomott bankkártyát, ami kell a regisztrációhoz, és nekem nincs.
-
CSorBA
őstag
Erre gondoltam én is, de abból indulok ki, hogy az ügyfél hülye.
Szóval képes beírni ilyen számokat:
70/1234-456
3630/123-456
123-456
+1120-123-456Szóval így nem nagyon tudom, melyiket szánta körzetnek, és melyik a telefonszámnak, vagy épp írt-e elé még országot is. Szóval gondoltam rá, h. tárolásnál csak strippelem, és a számokat hagyom meg, szóval a fentiből lesz:
701234456
3630123456
123456
1120123456De ebből nem fogom tudni, hogy melyiket hogy írta, ezért ha már ezt választom, akkor kénytelen vagyok a telefon oszlopot három felé bontani. (ami mellesleg rögtön 9 lesz, mivel egy rekordhoz 3 szám is tartozhat)
-
CSorBA
őstag
találtam egy ilyen csodát: UDF Repository: preg_replace function [link]
Szóval így megtudnám kb így:
WHERE PREG_REPLACE('/[^0-9]/',"",'phone_number') LIKE '%1234%';
Ami baromi jó lenne, ha saját szerver lenne, és tudnék telepíteni ilyet :S
szerk.:
Bár ha nagyon unatkozom, lehet átalakítom a táblát kb ilyenre:
phone_country
phone_area
phone_numberaztan csak CONCAT()-al összefűzöm, és abban már megy a LIKE....
-
raczger
őstag
evad_szeria az a versenyző profiljánál kell, hogy melyik évben milyen szériákon indul milyen rajtszámmal, egy évben akár 5 verseny széria is lehet, aztán következő évben ez lehet több vagy kevesebb is, más rajtszámmal
pont_qual és pont_race táblákat más okból nem lehet összevonni, ennek más oka van ami ezeknél a tábláknál nem látszik, sokat gondolkoztam, hogyan legyen az adatbázis, amire kell ez a szerkezet tűnt a legésszerűbbnek
sajnos ennél egyszerűbb ez nem lehet, mert akkor csak egy-egy versenyszéria pontozására lenne alkalmas, akartam egy kicsit általánosabb sémát csinálni a problémára
jelenleg egyébként azzal oldom meg a problémát, hogy aki egy hétvégén kvalon vagy valamelyik versenyen részt vesz mindenképp be kell írni akkor már az eredményét (legyen akár 0 pont) és akkor jól számolja ki a pontokat, tudom mi a hiba egyébként, csak a megoldásra nem sikerül rájönnöm, az a baj, hogy a sok left join miatt egy-egy sor duplikálódik, van, hogy ugyanaz a sor szerepel 50x-60x és ezt summolja amit elosztok ezen sorok számával
-
#728
Sk8erPeter
nagyúr
martonx
#727
Sk8erPeter
nagyúr
Igazából amit én nem értek, hogy mi a francnak tárolni a felhasználó korát, és állandóan UPDATE-elgetni egy mezőt. A felhasználó születési dátuma az teljesen biztos, hogy nem változik, tehát az adott, azt egyszer kell feltölteni (vagy ha elrontotta, akkor utólag módosítja, akkor elég UPDATE-elni ezt az egy mezőt (vagy ha szét van bontva évre, hónapra, napra, akkor annyi mezőt), de ez most a lényeg szempontjából tök mindegy), abból meg bármilyen másik művelethez azonnal le lehet kérni az aktuális életkort. Akár megjelenítéshez, akár máshova való felhasználáshoz. Szerintem inkább valami átgondolatlanság húzódhat a dolog hátterében.
-
retrox
csendes tag
Megvan a helyes kód:
<?php
$db_host = "localhost";
$db_username = "e107";
$db_pass = "e107";
$db_name = "e107";mysql_connect($db_host, $db_username, $db_pass);
mysql_select_db($db_name);
mysql_query("UPDATE e107_user_extended SET user_kora=floor(DATEDIFF(now(),user_birthday)/365.2425)");
?>
Kösönöm mindenkinek a segítséget.A feladat ütemezve,így naponta frissíti a kor mezőt. -
retrox
csendes tag
Ezt szeretném futtatni:
<?php
mysql_connect($db_localhost, $db_e107, $db_e107);
mysql_select_db($e107);
mysql_query("UPDATE e107_user_extended SET user_kora=floor(DATEDIFF(now(),user_birthday)/365.2425)");?>
ezt a hibaüzenetet kapom:
! ) Notice: Undefined variable: db_localhost in E:\wamp\www\e107\kor.php on line 2
Call Stack
# Time Memory Function Location
1 0.0021 365376 {main}( ) ..\kor.php:0( ! ) Notice: Undefined variable: db_e107 in E:\wamp\www\e107\kor.php on line 2
Call Stack
# Time Memory Function Location
1 0.0021 365376 {main}( ) ..\kor.php:0( ! ) Notice: Undefined variable: db_e107 in E:\wamp\www\e107\kor.php on line 2
Call Stack
# Time Memory Function Location
1 0.0021 365376 {main}( ) ..\kor.php:0( ! ) Notice: Undefined variable: e107 in E:\wamp\www\e107\kor.php on line 3
Call Stack
# Time Memory Function Location
1 0.0021 365376 {main}( ) ..\kor.php:0Hol rontottam el?Php guruk segítsetek.
-
RedSign
tag
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!!!
-
#674
Sk8erPeter
nagyúr
martonx
#670
Sk8erPeter
nagyúr
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. -
cucka
addikt
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) -
cucka
addikt
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.)
-
#668
Sk8erPeter
nagyúr
martonx
#667
Sk8erPeter
nagyúr
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.
-
#666
Sk8erPeter
nagyúr
martonx
#665
Sk8erPeter
nagyúr
"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). -
#664
Sk8erPeter
nagyúr
martonx
#663
Sk8erPeter
nagyúr
"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"? -
randras
veterán
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!
-
#659
Sk8erPeter
nagyúr
martonx
#658
Sk8erPeter
nagyúr
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?
-
#652
Sk8erPeter
nagyúr
martonx
#651
Sk8erPeter
nagyúr
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! -
#650
Sk8erPeter
nagyúr
martonx
#649
Sk8erPeter
nagyúr
Hali!
Itt a hibaüzenet:
Hibaüzenet:
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
)"#1093 - You can't specify target table 'tbl_ossze' for update in
FROM clause "A korábbi link alapján még próbálkoztam a következővel is, csak hogy lekérjem az adatokat, hogy így egyáltalán működik-e, de lehet, hogy ez úgy hülyeség, ahogy van (ez sem működik, úgyhogy sanszos):
SELECT `tbl_ossze` tabla_1
LEFT JOIN `tbl_ossze` tabla_2 ON tabla_1.kep_id = tabla_2.kep_id
AND tabla_1.kutya_id <> tabla_2.kutya_id
WHERE tabla_2.kutya_id IS NULL;Erre a hiba:
#1064 - You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'LEFT JOIN `tbl_ossze` tabla_2 ON tabla_1.kep_id = tabla_2.kep_id
AND tabla_1.k' at line 2 (KÉP)Konkrétan egyébként nem tudom, mire gondoltál, hogyan lehet esetleg még megoldani.
Köszi az esetleges további segítséget is!
Szerk.:
így néz ki a táblaszerkezet:--
-- Tábla szerkezet: `tbl_ossze`
--
CREATE TABLE `tbl_ossze` (
`kutya_id` int(11) NOT NULL COMMENT 'Kutya azonosítója',
`kep_id` int(11) NOT NULL COMMENT 'Hozzátartozó kép(ek) azonosítója',
`main_picture` enum('N','Y') collate utf8_hungarian_ci NOT NULL default 'N' COMMENT 'Ez a kép jelenjen meg főképként, amikor a kutyáról az első kép látható!',
PRIMARY KEY (`kutya_id`,`kep_id`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8 COLLATE=utf8_hungarian_ci COMMENT='Kutya és képek azonosítójának összerendelése';
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Mindenesetre nem egy hülyeség, hogy ilyesmit lehet egy GUI-n keresztül (ahogy lehet a phpMyAdminban), ahelyett, hogy kézzel kéne összeszenvedni a teljes kódot, mondjuk egy tárolt eljárással, ami tényleg megölheti az SQL-szervert, mert épp készülsz feltalálni a spanyolviaszt.
Nem biztos, hogy a phpMyAdmin okolható az általa tapasztalt probléma miatt (pl. arról nem esett egy szó sem, hogy kipróbálta-e simán, konzolról).
Kezdő, Te is voltál az.
Új hozzászólás Aktív témák
Hirdetés
- Lenovo Legion 5 Pro Gamer Laptop 2év garanciával (i7 13700HX, RTX 4060)
- IPhone 11 Pro max 64GB megkímélt új emelt kapacitású akku!
- Apple Pencil Pro bontatlan 1 év Apple jótállás
- Nitro ANV15-51 15.6" FHD IPS i5-13420H RTX 4060 32GB 512GB NVMe magyar vbill gar
- Apple watch Series 9 41mm cellular hibátlan 2026.02. 24. Apple jótállás
Állásajánlatok
Cég: CAMERA-PRO Hungary Kft
Város: Budapest
Cég: Promenade Publishing House Kft.
Város: Budapest