- Milyen házat vegyek?
- Komolynak tűnő gamepadekkel gyarapította palettáját a Razer
- Az ADATA legfrissebb XPG SSD-je hisz a piackutatóknak
- ThinkPad (NEM IdeaPad)
- Apple MacBook
- 5.1, 7.1 és gamer fejhallgatók
- Milyen videókártyát?
- NVIDIA GeForce RTX 5080 / 5090 (GB203 / 202)
- AMD Navi Radeon™ RX 9xxx sorozat
- OLED monitor topic
Új hozzászólás Aktív témák
-
martonx
veterán
válasz
Sk8erPeter #1098 üzenetére
php-s méretkorlát problémába biztosan nem futsz vele
-
martonx
veterán
válasz
Sk8erPeter #1096 üzenetére
hehe, no ilyenkor tud jó lenni a Toad for MySQL
-
Sk8erPeter
nagyúr
válasz
Babetta-X #1094 üzenetére
Hát ilyesmit nem nagyon szoktak engedni magasabbra állítani, lehet, hogy kuncsorogni kellene a szolgáltatónál.
Egy phpinfo()-t nézz meg, konkrétan pl. ezeket:
post_max_size
upload_max_filesizeAnnak viszont örülök, hogy sikerült a WP-s mutatvány.
A felülírós parára: exportálásnál meg lehet adni phpMyAdminban, hogy "Function to use when dumping data:" INSERT-UPDATE-REPLACE, ezek közül az utsó kettő közül valamelyik lenne jó, és akkor importálásnál elvileg az történne, amit szeretnél. Csak ahhoz ugye megint exportálni kellene, vagy pedig manuálisan beletenni a megfelelő sorokat, de az macera (bár attól függ, hány query-ről van szó).
-
Babetta-X
senior tag
válasz
Babetta-X #1093 üzenetére
Feladtam végül, feltettem a phpmyadmint, nagy meglepetésemre még magyar is. Lementettem mindent több lépcsőben is, de a legtöbb dologra amikor be akarnám importálni ezt hozza ki:
Nem került importálandó adat fogadásra. Vagy nem került átadásra fájlnév, vagy a fájlméret túllépte a PHP beállításokban engedélyezett legnagyobb méretet. Lásd GYIK 1.16...
Hogyan tudnám ezt a legnagyobb méretet beállítani mégnagyobbra?
-
Babetta-X
senior tag
válasz
Babetta-X #1092 üzenetére
Sikerült feltelepíteni, látom is a táblákat, nagy az öröm, megtaláltam az azt hiszem nekem számomra szükséges dolgokat, de mégjobb, hogy lehet rájöttem mit zavart össze a plugin (néhány táblának a pluginnal megegyező előnevet adta)
Viszont mielőtt bármit kontárkodom, szeretnék egy teljes mentést, meg külön a táblákról is mentést, hogy később vissza tudjam állítani. Itt is jön a probléma, hogy én itt csak export parancsot találtam, semmi mentést meg semmi betöltést. Biztos van valahol, de úgy érzem a szakszavaknál a szótár már nem olyan nagy segítség. -
Babetta-X
senior tag
válasz
Sk8erPeter #1091 üzenetére
Ez a mondat nem hangzott túl meggyőzőnek
Már másolom fel az általad javasolt programot, meglátjuk mire jutok vele. Köszönöm a segítséget!
-
Babetta-X
senior tag
válasz
Sk8erPeter #1089 üzenetére
Nem az egész adatbázist szeretném lementeni, csak az user és a post adatokat (háromszáz valamennyi regisztrált tag van és néhány adagnyi bejegyzés) a többi elvileg nem is olyan fontos nekem. Újratelepítés után ezeket az adatokat szeretném visszaimportálni.
Sajnos én semmilyen hibanaplóról nem tudok wordpress alatt, én eddig csak hobbiszinten foglalkoztam php-nuke-val szóval sok újdonság van a dolgokbanEddig akármilyen tárhelyen voltam volt külön oldal ahol be tudtam lépni az adatbázisba, sajnos ez itt elmaradt.
-
Sk8erPeter
nagyúr
válasz
Babetta-X #1088 üzenetére
"Igazándiból a wordpress cms van most fent, ennek bizonyos tábláit szeretném lementeni majd újratelepítés után visszahelyezni"
És akkor mi értelme van az újratelepítésnek, ha aztán ugyanazokat a táblákat fogod használni?
Sőt, ha ugyanazokat a táblákat használod ismét, akkor nem is lesz újratelepítve.
Nem költöztetni szeretnéd valahova máshova? Vagy mi a cél?Szerk.:
korábban írtak:
"A lényeg, hogy a wordpress CMS által feltett adatbázist kéne lementenem, mivel két rossz pluginnak hála összekeveredett és egyáltalán be sem jön az oldal, így webes felületről nem tudom adatbázis mentést készíteni."
Attól nem fog megoldódni ez a gond, hogy ugyanazt az adatbázist visszarakod... Azzal meg végképp nem, ha a korábbi pluginokat letörlöd, és mégis a korábbi adatbázist használod.
Ezt azért gondold át még egyszer, mielőtt tönkrevágod az oldaladat, inkább a plugin hibáját kéne javítani.
A Drupalnál úgy van egyébként, hogy ha modulban el is van cseszve valami, a hibanaplót elvileg eléred attól még. WordPress-nél nem éred el?Vagy csak az a cél, hogy localhostra lementsd, aztán ott próbáld meg debuggolni a hibát?
-
Babetta-X
senior tag
válasz
Sk8erPeter #1087 üzenetére
Köszönöm, mivel ilyen téren 0 tudással és tapasztalattal rendelkezem, ráadásként az angol nyelv is nehézkes, ezért megpróbálom először az egyszerűbbet. Igazándiból a wordpress cms van most fent, ennek bizonyos tábláit szeretném lementeni majd újratelepítés után visszahelyezni.
-
Sk8erPeter
nagyúr
válasz
Babetta-X #1085 üzenetére
Ahogy írták, telepíts valamelyik alkönyvtárba egy phpMyAdmint, de van lightweightebb is, amit itt már ajánlottak, és nagyon gyors (próbáltam):
http://www.dbninja.com/?page=download
Mondjuk többet tud a phpMyAdmin, de ennek a konfigolása szinte nem tart semeddig, a phpMyAdminnál azért be kell állítani jópár dolgot. -
PazsitZ
addikt
válasz
Babetta-X #1085 üzenetére
Nem teljesen ertem mi a gond. Tokeletesen leirtak, h nincs kulon felulet a db-hez. Tehat vagy egy script-el mented le vagy feltelepitesz mondjuk egy phpmyadmint.
Az elerhetoseget magad irtad le. phpmyadmin configban ugyanazokat a db konfig adatokat kell megadnod, mint amit eddig is hasznaltal. -
Babetta-X
senior tag
Sziasztok! Lenne egy problémám, amit előszörre azt hiszem a nem odaillő topicban kérdeztem meg, ezért bemásolom az alap gondomat:
Lenne egy megfejtésre váro feladatom, hátha ti boldogultok vele.
Az adatbázis szerver elérhetősége az amit meg kéne fejteni.
Erre valami ötlet? Felhasználói nevet, jelszót tudom, de hogy hol kell belépni (gondolom) phpmyadminba, vagy hogy hol van az adatbázis belépőfelülete azt nem. A nordtelekomnál (itt van a szerver bérlet sajnos) a support egyenlő a 0-val, elhajtottak a fenébe szerződésszám nélkül, hiába mondtam, hogy ez baromira nem egy titkos vagy rejtegetnivaló információ (a legtöbb helyen még ki is van írva ingyenes tárhelyeken tudtommal.)Valami ötlet, hogy honnan lehet ezt kivadászni? Próbáltam megnézni, de ingyenes regisztrálás nincsen náluk, illetve a cms (wordpress) config filejában nézegettem de nincs elérési út, csak felhasználói név meg jelszó ilyesmik. Esetleg ha ebből lehet valamit kihámozni ennyit találtam:
MySQL kiszolgáló neve */
define('DB_HOST', '127.0.0.1');A Nordtelekom ma ezt írta vissza:
Tisztelt Ügyfelünk!
Az adatbázishoz nincsen belépési felület. Ha el szeretnék érni, akkor a phpmyadmin-t kellene telepíteni, és úgy el tudják érni.Köszönettel,
Nordtelekom irodaNo hát eddig jutottam, ezután nem tudom mi a teendő
A lényeg, hogy a wordpress CMS által feltett adatbázist kéne lementenem, mivel két rossz pluginnak hála összekeveredett és egyáltalán be sem jön az oldal, így webes felületről nem tudom adatbázis mentést készíteni.
Eléggé nagy probléma ez, kihullott már néhány hajszálam sajna. Válaszotokat előre is nagyon köszönöm!
-
Sk8erPeter
nagyúr
válasz
PazsitZ #1082 üzenetére
Kettőnk közül most nem én tekintettem magam "az igazság bajnokának", nem igazán hajlottál rá, hogy elfogadj a véleményemből bármit is.
Persze nem is kell.
Itt pedig GUI-n megoldható dolgokról volt szó, nem másról, ezt a témát próbáltam kivesézni.
Na, de örülök, hogy Te is megmondtad a magadét.Szóval igazából szerintem elég jól átrágtuk a témát, nem érdemes tovább ragozni.
-
PazsitZ
addikt
válasz
Sk8erPeter #1057 üzenetére
Ha nem finamkodtál akkor én miért nem engedhetek meg magamnak egy kis fricskát?
Egyébként a hozzáállásom attól még nem negatív, hogy te valamiért oda vagy én meg nem. (értsd: grafikus kattintgatós query builder)El kell ismételnem úgy tűnik, még mindig se érdekem, se kedvem védeni a workbenchet.
Nem tudtam, hogy 2 darab pipe-olt konzolparancs felvágásnak számítana?
Nem köcsögösködtem.
Attól, hogy te az igazság bajnokának tekinted magad észrevehetnéd, hogy más véleménye sem fekete-fehér.
Ha azt mondom, hogy én nem látom hasznát, az nem ekvivalens azzal, hogy "hatalmas baromság", amit te mondasz, akárhogy is próbálod csavargatni. -
martonx
veterán
válasz
lakisoft #1074 üzenetére
Mondom alapból 90 napos trial jár.
De ha előtte webspark-on regisztrálsz (linket nem adok, írd be gugliba: webspark), akkor időlimit nélküli ingyen 1GB database, meg 30Gb storage, meg hasonló jóságok járnak a webspark tagsághoz. Én is így használom.
Ha meg jogosult vagy bizspark-ra, akkor évi több száz dollárnyi Azure cuccot kapsz ingyen, az ingyenes full MS ökoszisztéma mellé. Persze a bizspark szvsz úgy lett kitalálva, hogy kb. senki ne legyen rá jogosult, viszont minél nagyobb legyen a hírértéke, hogy elméletileg mennyi mindent adna ingyen az MS. -
biker
nagyúr
válasz
Sk8erPeter #1079 üzenetére
ja, ugyanide jutottam én is
most egész kellemesen dobálja a találatokat gépelés közben. -
biker
nagyúr
válasz
Sk8erPeter #1076 üzenetére
persze, alapvetően jó dolgok.
csak megtalálni az egyensúlyt az erőben, nehéz -
lakisoft
veterán
Létezik ingyenes MySQL cloud szolgáltatás? Esetleg más adatbázismotor is szóba jöhet.
-
biker
nagyúr
Szóval lehet-e match-olni szótöredékre, vagy lehet-e score szerint (relevancia) rendezni LIKE lekérdezést?
-
biker
nagyúr
válasz
Sk8erPeter #1069 üzenetére
mikor a cimkefelhő még LIKE keresésekre ment rá, és jött a googlebot indexelni akkor végigpörgette azokat, termékenként 10-30 cimke, konkrétan 130.000 termékhez 1m feletti cimke, melyek random jelennek meg minden lap alján, ezért mindig változó tartalommal rágerjedt a bot rendesen) + a kereső mezőt is kezelte a bot, akkor 50-60.000 cikkig nem volt gond, aztán betoltuk a LÍRA 40.000 könyvét, és másnap letérdelt a site
és csak néztünk, mi a fene van?
egy keresés hirtelen 15mp lett, és mikor betelt a que akkor cumi, leállt a mysqlmost is megy, ez csak a googlebot(!!):
havi 370.000 keresési lekérdezés
22.000 kattintás1.403.400 egyedinek vélt oldal, amiből 620.000 indexelve (a keresett termékek is egyedi oldalon jelennek meg, becsapva a botot, + egyedi fejléc + egyedi keyword és description oldalak)
napi átlag 38.000 oldal feltérképezés (csúcs 68.000)
átlagos adatforgalom 850Megabyte (csúcs 1,6Giga) (gzipelés nélkül ez elment napi 4-5gigabyteba)
oldalak betöltési ideje átlag 852ms, csúcs 1,4s
(na ez ment át 25-30mp-be a várakozó lekérések miatt)Na ezt nem akarom feladni
-
biker
nagyúr
válasz
Sk8erPeter #1067 üzenetére
mert nem szeretem, ha elérhetetlen az oldal, és ha elkezdi a user írni, átlagos mp-enkénti 2 karakter sebességgel a szöveget, hogy "fűrészlap" akkor az 6-7mp alatt 9 keresés, 9x0,2-0,3mp
ezt szorozzuk fel a napi 1200-1400 látogató oldalbetöltéseivel és keresésével, és kijön egy szép letérdelős oldal
Mint mikor régen másképp ment a kereső, és a google indexelte az oldalt az új cimkefelhővel, és naponta letérdelt az adatbázis emiattEzért alapértelmezett a kereső match-el indexelve, és csak az összetett keresőben tud a user olyat választani, hogy adott mezőkben szótöredékre keres
+ a LIKE lekérést nem lehet relevancia szerint rendezni, a match-ot meg lehet score-ba tenni és úgy megjeleníteni, és így a zsindelyes szőlő pálinka első találatot ad, míg LIKE esetén meg se találja, ha a név zsindelyes pálinka, szőlő
érted?
-
biker
nagyúr
match/against vs LIKE és keresési eredmény problémám van
Van egy termék adatbázis, abban egy kereső, sok féle kereséssel.
A helyes indexeléssel sajnos nem vagyok előrébb, mert a match az csak szó egyezésre keres. a like %% ugye töredékre is, de lassú, a query expansion meg szintén csak teljes szóra keres, de hasonló szavakra is, ami miatt túl sok eredményt ad vissza
130.000 rekord, 200M feletti a táblaméret
plforrasz > LIKE %% esetén kb 0,2s a keresés, és talál kb 300 terméket, forrazstásra
forrasz > MATCH 0 találat
forraszt > MATCH esetén már jobb, kb hasonló mint a LIKE, de 0,002s az eredményforrasz > match with query expansion továbbra is 0 találat
forraszt > match with query expansion 88.000 találat, minden ami forraszt, hegeszt, és sorolhatnám, ez meg túl sok, és nem releváns minden esetben, szótöredékre továbbra sem keresLétezik-e olyan MATCH AGAINST ami töredékre is keres?
-
Peter Kiss
őstag
válasz
laracroft #1062 üzenetére
A COUNT() mindig a paraméterként megadott expression-t vizsgálva NULL-ra. Ha nem NULL, akkor beleveszi az adott elemet a végső összegzésbe. A COUNT(1), COUNT(*) sosem NULL (Oracle alatt a COUNT(1)-ből COUNT(*) lesz elvileg), így azonos a kettő. Ha field nevet adsz át, akkor abban az esetben, ha az adott rekordot adott field-je alatt NULL value van, akkor azt nem fogja összeszámolni.
-
laracroft
senior tag
válasz
Peter Kiss #1061 üzenetére
Jaja ezt olvastam, de továbbra sem értem mi a különbség a count(*) és a count(1) között...
my fault
-
Peter Kiss
őstag
válasz
laracroft #1060 üzenetére
http://dev.mysql.com/doc/refman/5.6/en/counting-rows.html - a dokumentációs oldalak publikusak.
-
martonx
veterán
válasz
laracroft #1034 üzenetére
Az alap SQL kérdéseket már el se szoktam olvasni, de látom egy ideje nem kapsz választ. Tessék:
SELECT ugyfel.account AS account,
ugyfel.line AS line,
COUNT(1) AS darab
FROM ugyfel, naplo
WHERE naplo.account = ugyfel.account AND naplo.line = ugyfel.line AND ugyfel.name1 NOT LIKE "%teszt%"
GROUP BY account,line
ORDER BY darab DESC -
Apollo17hu
őstag
-
Sk8erPeter
nagyúr
válasz
PazsitZ #1056 üzenetére
Tényleg kezd kissé fárasztó lenni.
Nem "pörgök" rajta, írták itt, hogy próbáljam mega progit, megpróbáltam: [link]; később még egyszer előkaptam (igen, 1 hónap múlva! De ettől még nem pörgök azóta ezen a témán, hagyjuk már
), amikor valamire szükségem volt, ismét írtam visszajelzést, mit hiányolok belőle: [link]
kedves reakcióid:
[link]
[link]
[link]
Áá, nincs ám benned egy csöpp szarkazmus és cinizmus sem az igényeimmel szemben...Visszajeleztem valamire, amiről véleménycsere volt. Ha nem finomkodtam, ez nem azt jelenti, hogy neked kötelességed hősködve kiállni a program mellett, szándékos negatív hozzáállás nélkül is lehet vitázni valamiről, ha nem értesz egyet, és akkor valószínűleg meg is találjuk a közös nevezőt, és tudunk érdemben is előnyökről-hátrányokról dumálni, nincs is abban semmi rossz.
"Gizdulni" nagyjából annyit tesz, hogy vagánykodni, nagyzolni.
Sztem maradjunk annyiban, hogy nem kell a másikkal köcsögösködni attól még, hogy az illető a negatív tulajdonságait is bemutatja egy programnak, és ezért összességében kevéskének tartja.
Peace! -
PazsitZ
addikt
válasz
Sk8erPeter #1054 üzenetére
Nekem egyáltalán nem baj, hogy számodra nem lenne hasznos, amit én szeretnék használni
Ha nem, akkor miért ezen pörögsz lassan egy hónapja?Továbbá :
Még mindig nem próbáltam hülyeségnek beállítani az elvárásaidat/igényeidet.
Nem hoztam ki győztesnek semmit.
Még mindig nem mondtam, hogy amit szeretnél hülyeség.Legalább is emlékeim szerint, nincs kedvem visszaolvasni. De lassan belátom, igazából én vagyok a hülye, hogy válaszolok ezekre a posztokra.
Bár feltételezem nem a topikhoz tartozik, de mi az a "gizdulás"?
-
martonx
veterán
Mert a böngészőből meghívott webszerver ugyanazon a gépen futhat, amin a MySQL. Így e kettő lokálisan tud kommunkálni egymással. Amit pedig te akarsz az egy másik gépen futó perl alkalmazás, ami érthető módon nem tud lokálisan kommunikálni, hanem csak távolról.
Nos ezt a távoli elérést kell engedélyezned a MySQL-es gépen, MySQL konfigban, tűzfalon stb... -
Sk8erPeter
nagyúr
válasz
PazsitZ #1052 üzenetére
Nekem egyáltalán nem baj, hogy számodra nem lenne hasznos, amit én szeretnék használni, ne értsd félre szándékosan.
De Te se próbáld beállítani hülyeségnek azt, ami meg számomra elvárás/igény, és van olyan open source, ingyenes program, ami ezt biztosítja. Nem mondom egyáltalán, hogy a phpMyAdmin az teljesen jó, mert azon is bőven van mit csiszolni, és nem vagyok oda érte, de biztosít egy csomó olyan lehetőséget, amit sajna még nem találtam meg ingyenes asztali kliensekben MySQL-hez, és itt a topicban többen is a MySQL Workbench-et hozták ki győztesnek a phpMyAdmin kontra MySQL Workbench párbajban, én pedig konkrétan erre a témára fókuszáltam - nem pedig arra, hogy neked vagy nekem mi az egyéni preferenciám. Próbáltam kiemelni, hogy jelenlegi állapotában miért tud kevesebbet szerintem sok szempontból a MySQL Workbench. Sajnos ezt sikerült elterelned olyan irányba, hogy szerinted amit én szeretnék, az kvázi pitiáner hülyeség, és emiatt ne erőltessem már, hogy kevesebbet tud a MySQL Workbench. Mást tud a kettő, de olyan dolgokban kevesebbet tud utóbbi, ami nálam pl. gyakran felmerülő igény (pl. tömörített dumpból importálni pár klikkre). -
PazsitZ
addikt
válasz
Sk8erPeter #1047 üzenetére
Nem tudom mi az a "gizdulás".
Nem tudom mit nem sikerült feldolgozni azon, hogy én szeretem pl .a konzolt. Elnézésedet kérem ezért.
Tippem szerint te big data kezelés, data mining megoldásokra gondolsz, ami kicsit másik műfaj, szvsz.
De azt még mindig nem értem ,hogy miért kell besértődni, hogy történetesen számomra felesleges, amit te konkrétan szeretsz használni.
Használd, senki nem írta, h ne tedd. Én meg nem használom, remélem ezt meg tudod emészteni. -
p06
senior tag
Sziasztok
A gépen fut egy teljesen alap LAMP. Itt az adatbázisban vannak az adatok amik kellenek és a követklező sorok segítségével le is tudom kérdezni Perl-ben:
#!/usr/bin/perl
use DBI;
use DBD::mysql;
$platform = "mysql";
$database = "kartyak";
$host = "localhost";
$port = "3306";
$tablename = "Jog";
$user = "root";
$pw = "1234";
$dsn = "dbi:mysql:$database:localhost:3306";
$connect = DBI->connect($dsn, $user, $pw);De én egy másik eszközön szeretném ellérni ezt a program segítségével (böngészőből működik). Mit kell beállítanom? (Probálkoztam azzal, hogy a $host-hoz beírtam az adott gép IP-jét de hiba volt nem tudott belépni)
Előre is köszönöm!!
-
Sk8erPeter
nagyúr
Az előbb már írtam: nagyvállalati környezetben, bizonyos adatok kinyerése érdekében, naplózáshoz és egyéb célokhoz is. Ha nem hiszed, megadom az elérhetőségeit egyik haveromnak, ha szeretnél vele erről diskurálni, hogy egy németországi rohadt nagy cégnél miért művelnek ilyen elmebeteg dolgokat. Először én is le voltam hidalva a számokon, amikről mesélt. De félreértés ne essék, NEM MySQL-ben dolgoznak.
-
Soak
veterán
válasz
Sk8erPeter #1047 üzenetére
Akkor szerinted hogyan kapcsolnak össze mondjuk több mint 100 táblát, mikre tippelsz?
Hol létezik olyan, hogy 100 táblát kell joinolni?
-
Sk8erPeter
nagyúr
válasz
PazsitZ #1038 üzenetére
Jaj ne már... magadat sem veheted komolyan. Gizdulásnak is gyenge volt ez a gunzipes példád. Könyörgöm, tényleg ily' nehéz megértened, hogy itt GUI-n keresztüli adatbázis-manipulálásról volt szó, anélkül, hogy hozzányúlnál egyáltalán a konzolhoz/terminálhoz?
Minek kötöd az ebet a karóhoz?
Ilyen alapon a júzerek létrehozására, privilégiumainak módosítására is írhatnék akár egy konzolos kis progit C-ben, vagy sima batch-programot, biztos rendkívül izgi lenne, meg feltalálhatnám a spanyolviaszt. Körbeírjam még párféleképpen, hogy mi itt az alapvető probléma?"Egyébként szerintem meg nem."
Akkor szerinted hogyan kapcsolnak össze mondjuk több mint 100 táblát, mikre tippelsz? -
-
laracroft
senior tag
válasz
Apollo17hu #1039 üzenetére
Szia!
Köszönöm kimerítő válaszod!
Egyenlőre syntax error-t kapok a:COUNT(*) over (PARTITION BY ugyfel.account, ugyfel.line) AS darab
FROM ugyfel, naplokód környékére... Átnéztem a mysql ezen parancsára vonatkozó szintaxist, de szerintem ennek jónak kéne lenni. Tanácsodra elhagytam az order by parancsot is, de nincs változás...
vmi ötlet? -
PazsitZ
addikt
Mondjuk:
SELECT COUNT(*) FROM table WHERE code = 'code_to_find'
Így megkapod, hogy hány darab ilyen kód van. Ha a kód unique, 0 vagy 1 lesz az eredmény.Vagy lekérdezed:
SELECT code, name FROM table WHERE code = 'code_to_find'
Majd szerver oldalon megnézed a query hány eredményt adott.Más konkrét parancs nem jut eszembe ehhez.
-
p06
senior tag
Sziasztok
A LIKE-al lehetséges, olyan lekérdezést létrehozni, ahol megnézi, hogy van e az adott kód az adatbázisban majd erre egyértelmű választ ad (1 vagy 0) és kiírja a kódhoz tartozó másik adatot (ebben az esetben nevet).
Vagy ehhez más parancs használatos?
Köszönöm!
-
Apollo17hu
őstag
válasz
laracroft #1034 üzenetére
SELECT DISTINCT
ugyfel.account AS account,
ugyfel.line AS line,
ugyfel.name1 AS name,
ugyfel.address3 AS irszam,
ugyfel.address1 AS varos,
ugyfel.address2 AS utca,
COUNT(*) over(PARTITION BY ugyfel.account, ugyfel.line) AS darab
FROM ugyfel, naplo
WHERE naplo.account = ugyfel.account AND naplo.line = ugyfel.line AND ugyfel.name1 NOT LIKE "%teszt%"
ORDER BY darab DESCCOUNT(*) over(PARTITION BY ugyfel.account, ugyfel.line) jelentése:
Csoportosítod a rekordokat: az ugyfel.account + ugyfel.line kombó minden csoportot egyértelműen azonosít. A COUNT(*) ezekre a csoportokra vonatkozik. DISTINCT pedig azért kell, mert enélkül a csoportok minden egyes rekordja új sort generálna (azonos tartalommal).
megj.: Erre szerintem az ORDER BY darab DESC nem működik (bár én csak sima SQL-t használok). Allekérdezéssel ez is áthidalható.
-
PazsitZ
addikt
válasz
Sk8erPeter #1037 üzenetére
Belátom.
Nem tudom mit lehet nem belátni azon, hogy ez másnak (nekem legalább is) ez nem egy elgördíthetetlen akadály.
gunzip < [sqls.gz] | mysql -u [uname] -p[pass] [dbname]Ja igen, erre írtad, hogy ez szerinted f@szság
Nem így írtam és túlzásnak érzem ezt a kifejezést. Nem az, csak én nem látom igazi hasznát.
De lehet én szoktam az utóbbi időben túlzottan konzolhoz.
( ma is megkaptam, hogy miért akarok konzolból verziókezelőzni, mindenki GUI klienst használ hozzá)
Nagyvállalati környezetről eddig nincs releváns tapasztalatom, 200 táblás
összekapcsolással kapcsolatosan sem.
Egyébként szerintem meg nem. De majd hátha van valaki, aki nagyvállalatokban jártas és megmondja nekünk. -
Sk8erPeter
nagyúr
válasz
PazsitZ #1036 üzenetére
Valóban, nem hülyeségnek tartottad, rosszul emlékeztem, de ezt írtad:
"Tomoritett fajl import nem tudom van-e alapbol, de nem tudom miert akkora gond ez."
Azért akkora gond, mert ha én tömörített formában exportálom az eredeti szerverről a dumpot, akkor szeretném azt egyből importálni. Nem tudom, mit nem lehet ezen belátni.A kitömörített változat esélyes, hogy működik, majd kipróbálom. De már megint olyan dolog, amivel nekem kell tökölni, ahelyett, hogy a program elintézné ezt helyettem. Szerintem ez alapvető elvárás, és annyira nem nagy dolog, ha a phpMyAdmin is képes rá.
"A grafikus query osszeallitot meg hagyjuk mar, elhiszen, h lehet vele jot jatszani, de azon tul..."
Ja igen, erre írtad, hogy ez szerinted f@szság. Hát nem az, és például kapcsolatok gyors létrehozására a phpMyAdminban is van lehetőség grafikus felületen keresztül is.
Mondjuk erre már korábban is reagáltam, hogy kár, hogy nem tudsz olyan esetet elképzelni, ahol a grafikus query-összeállító igen hasznos tud lenni. Nyilván nagyvállalati környezetben (nem magamról beszélek), egy 200 táblás query-összekapcsolást is bepötyögnek, igaz? Szerintem ott is tök jókat "eljátszanak" grafikus alapú adatbázis-kezelőkkel... -
PazsitZ
addikt
válasz
Sk8erPeter #1035 üzenetére
Emlekeim szerint nem irtam, h tudna ilyet, tovabba azt sem, h felesleges. De nem vagyok benne biztos, h kitomoritve nem tud egyszerre tobb sql dumpot is felnyalni.
-
Sk8erPeter
nagyúr
válasz
PazsitZ #1029 üzenetére
Ó, tényleg, akkor a júzerek kezelésével kapcsolatban én voltam a figyelmetlen, sorry (ahogy ígértem, leírtam
), legalább ez megoldott kérdés, mégsem olyan "ostoba szar" a progi.
(Csak a kedvedért használtam ismét ezt a kifejezést.
Mivel úgy csináltál, mintha a korábban belinkelt hozzászólásaimban ne soroltam volna el azokat a dolgokat, amik viszont tetszenek a MySQL Workbench-ben, pedig de.) A gyökereknek szóló lmgtfy-s linkedet pedig külön köszönöm, eddig fogalmam sem volt, hogy kell ilyesmit a Gúúgölben keresni.
A tömörített, gzippelt SQL-dumpokat viszont továbbra sem lehet importálni, most próbáltam, itt, mielőtt ismét küldenél egy lmgty-s linket:
Eredménye:
Pedig ez manapság elég alapvető elvárás, és ez megint csak olyan, amit a phpMyAdmin vicces, hogy tud, ez pedig nem.
Ja, várj, szerinted ez is nyilvánvalóan egy hatalmas baromság, ahogy korábban kifejtetted, hát ki a büdös franc akarna manapság nagyobb adatbázist tömörítve letölteni az eredeti szerverről, és átvinni egy másikra, miért is ne tartaná a terpeszkedő eredeti .sql-formában, hát ki az a hülye, aki ilyesmit manapság csinál, nyilván ez is csak egy játékszer, az ilyenek azzal játsszanak inkább, ami velük egyidős. Ha így látod, hát nagyon rosszul látod. -
laracroft
senior tag
Sziasztok!
Meg szeretném számolni, hogy kinek van a legtöbb bejegyzése a naplo táblában.
Számomra az bonyolítja a helyzetet, hogy egy ügyfelet nem egyértelműen határozza meg az "account", kell neki a "line" mező is! Ha a count(account)-ot használom az nem jó, mert beleszámol olyat is akinek más a "line" mezője.
Pl létezik ilyen az adatbázisban hogy:
account=1855 line=3
Értéke: Béla
account=1855 line=1
Értéke: JaniSELECT ugyfel.account AS account,
ugyfel.line AS line,
ugyfel.name1 AS name,
ugyfel.address3 AS irszam,
ugyfel.address1 AS varos,
ugyfel.address2 AS utca,
COUNT(ugyfel.account) AS darab
FROM ugyfel, naplo
WHERE naplo.account = ugyfel.account AND naplo.line = ugyfel.line AND ugyfel.name1 NOT LIKE "%teszt%"
GROUP BY account,line
ORDER BY darab DESCelőre is köszi!
-
martonx
veterán
válasz
Sk8erPeter #1020 üzenetére
CMS-nél tényleg hasznos lehet bizonyos esetekben egy ilyen feature. Én mondjuk olyan mélységben sose használtam CMS-t, mint te. Ellenben én meg minden táblámat ismerek, azaz fel sem merül, hogy vajon hol melyikben kezdjek keresni egy-egy értéket.
-
PazsitZ
addikt
Egy mysql hibának kellett volna.
A GROUP BY a WHERE után következik [link]
FROM ... WHERE ... GROUP BY ... ORDER BY ... LIMIT ...;SELECT `id`, `gametypeid`,MIN(`packetid`) AS `packetid`, `discount`, `date_start`, `date_end`
FROM `discounts`
WHERE `date_start` <= $currtime AND `date_end` >= $currtime
GROUP BY `gametypeid`
ORDER BY `id` DESC
LIMIT 4;U.i.: meg most nézem a group by mögött benne maradt még egy pontosvessző is a query-ben.
-
whYz
őstag
-
-
Sk8erPeter
nagyúr
válasz
PazsitZ #1026 üzenetére
Köszönöm a tanácsot, nem is használom.
Ami miatt most előkaptam, hogy hirtelen kíváncsi voltam valamire, és ha már telepítve van, megnéztem, van-e benne ilyen lehetőség, mert jobb' szeretnék faszányos asztali klienst használni, mint a böngészőben használható phpMyAdmint.
Egyébként a programra ajánlottam alternatívát is, ami szerintem tényleg fasza, nem csak a levegőbe hőbörögtem, a dbForge Studio for MySQL-t, csak azzal az a gáz, hogy fizetős."A múltkor konkrétan pl. azért volt rossz, mert te 1-2 funkciót nem találtál meg benne elsőre."
Ilyen mikor volt?
Szerintem erre gondolsz: [link]. Megmutatod nekem, hogy hol írtad le ezekre a megoldást, hogy hol találhatók meg a felületen? Segítek: sehol.Ha megírod, hogy ezek hol találhatók meg, és kiderül, hogy csak az én figyelmemet kerülték el, akkor azt mondom, sorry, én voltam a figyelmetlen, addig viszont ezek továbbra is nyitott kérdések, tények. Szóval?
-
PazsitZ
addikt
válasz
Sk8erPeter #1022 üzenetére
A múltkor konkrétan pl. azért volt rossz, mert te 1-2 funkciót nem találtál meg benne elsőre.
Most azért rossz, mert egy másik alkalmazás feature-e nincs beleépítve.
Továbbá megjegyzem, nem veszem komolyan a dolgot, semmi okom védeni a workbench-et, pláne nem zaklat fel, hogy hányan használják vagy nem használják.
Átjött, hogy szándékos túlzás, szarkazmus az ostoba szar kifejezés, ezért használtam idézetként.Minden esetre "trollozás"om megint csak idézet arra vonatkozik, hogy milyen racionális észérveket szoktál felsorolni.
De még mindig azt tudom, mondani, teljesen komolyan, sértődöttség, trollkodás nélkül (nem egy nyakatekert logika): hogy ha nem jó neked, akkor ne használd.
-
whYz
őstag
válasz
Sk8erPeter #1024 üzenetére
Igen, de a gametypeid es a packetid folyamatosan valtozni fog, tehat igazabol az egyedi gametypeid-re vagyok kivancsi.
-
Sk8erPeter
nagyúr
Igazából amiket írtál, csak kódformába kellett önteni (a zárójeleket az átláthatóság kedvéért pakoltam bele pluszban):
SELECT `id`, `gametypeid`,`packetid`, `discount`, `date_start`, `date_end`
FROM `discounts`
WHERE
(
`date_start` <= $currtime
AND
`date_end` >= $currtime
)
AND (
( gametypeid=1 AND packetid=1 ) OR
( gametypeid=2 AND packetid=3 )
)
ORDER BY `id` DESC LIMIT 4Szerk.:
persze itt a gametypeid és a packetid "be van drótozva", ha a hozzá tartozó "legkisebb packetid-jut" szeretnéd automatikusan kideríteni, akkor ahhoz egy bonyolultabb alselectre lenne még szükség. -
whYz
őstag
Sziasztok
Szeretnek egy kis segitseget kerni.
Itt a jelenlegi kodom:
$db->query("SELECT `id`, `gametypeid`,`packetid`, `discount`, `date_start`, `date_end` FROM `discounts` WHERE `date_start` <= $currtime AND `date_end` >= $currtime ORDER BY `id` DESC LIMIT 4");A mezoben van mondjuk:
gametypeid=1 packetid=1
gametypeid=1 packetid=2
gametypeid=2 packetid=3
gametypeid=2 packetid=4Azt szeretnem megvalositani, hogy csak a:
gametypeid=1 packetid=1 es
gametypeid=2 packetid=3
sorokat valassza ki, tehat gametypeid alapjan, mindegyik gametypeid-bol csak 1 darabot es a legkisebb packetid-jut.Tudnatok segiteni?
-
Sk8erPeter
nagyúr
válasz
PazsitZ #1021 üzenetére
Csak úgy sugárzik belőled a jóindulat, úgy általában, mindig megjelensz, ha valakit lehet cseszegetni.
De mondjuk engem speciel ez nem visel meg különösebben, szívesen reagálok a szándékosan rosszindulatú hozzászólásodra.
Biztos te is művelsz olyan dolgokat, amik meg nekem lennének furcsák.
Hogyhogy miért próbálom használni? Elég hülye kérdés, de válaszolok rá: egyrészt azért, mert ingyenes termék attól a cégtől, aki fejleszti a MySQL-t (komolyan magyarázzam tovább?jó, a kedvedért), és kíváncsi vagyok rá, másrészt azért, mert itt a topicban ketten javasolták, hogy adjak neki még egy esélyt, mert rendkívül fejlett, nagytudású, sokat fejlesztettek rajta az elmúlt időkben, blabla. Ezekre reagáltam, vissza is kérdeztem, hogy konkrétan milyen fejlesztésekre gondoltak, mert én nem vettem észre azt az óriási fejlődést rajta. De te sem mondtál egy nyomorult szempontot sem, csak azért jöttél ide, hogy trollkodj egyet, jó szórakozást kívánok hozzá.
Az "ostoba szar" megfogalmazás meg szándékosan volt eltúlozva, örülök, hogy belőled legalább sikerült kiváltanom azt az érzést, hogy nem direkt szarkasztikusnak és cinikusnak veszed, hanem még személyes sértésnek is veszed szinte, és véresen komolyan kezeled az ügyet, kapsz tapsikolós smiley-t is cserébe:
"Sőt, miért nem írsz jobbat?"
Azért nem vártam, hogy ilyen reakciót pont tőled fogok olvasni, ennél egy csöppet intelligensebbeket szoktál írni. Bocs, ha többet feltételezek, mint kéne.(Na, nehogy ezen is megsértődj.
)
-
PazsitZ
addikt
válasz
Sk8erPeter #1020 üzenetére
Biztos én vagyok ilyen szempontból ingerszegény környezetben, de sosem volt szükségem, igényem ilyenre.
De hála neked legalább most már tudjuk, mitől ostoba szar valami a phpMyAdminhoz képest.
De tényleg, ha minden ilyen fos, szar, akkor miért próbálod használni?
Sőt, miért nem írsz jobbat? -
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.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.
-
martonx
veterán
válasz
Sk8erPeter #1018 üzenetére
bocs, félreértettelek. Fel se merült bennem, hogy valaki ilyet akarna tenni, hogy egy DB összes táblájában keresni akar valamit. Miért teszel ilyet? Ha van jópár több millió soros DB-d, akkor azok mennyire szeretik vajon ezeket a fajta kereséseket? És miért jó az, ha két óra múlva kapsz mondjuk egy választ, de cserébe megölted a komplett SQL szervert az ártatlan kereséseddel?
Az, hogy egy GUI ilyen kényelmi funkciót biztosít, szvsz inkább hátrány, mint előny. -
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. -
martonx
veterán
válasz
Sk8erPeter #1016 üzenetére
ööö lehet én vagyok kocka, de ezekere a keresésekre vannak beépített SQL táblák, amik megmutatják a DB szerkezetét. Erre való az information_schema.
-
Sk8erPeter
nagyúr
válasz
Sk8erPeter #975 üzenetére
Na, még egy dolog tűnt fel, ami hiányzik a MySQL Workbench-ből (nagyon), a phpMyAdminban viszont ötezer éve megvan: az összes vagy megadott nevű adattáblákban való keresgélés egy adatbázison belül.
phpMyAdminban ezek a kategóriák vannak:
- at least one of the words
- all words
- the exact phrase
- as regular expression
aztán meg lehet adni Ctrl-os kijelöléssel, hogy konkrétan melyik táblákban keressen, vagy ki lehet jelölni az összeset, meg lehet jelölni, melyik nevű mezőben keressen, lehet wildcarddal keresni.Szóval egyértelmű, hogy a MySQL Workbench egy ostoba szar a phpMyAdminhoz képest.
-
Lacces
őstag
Itt találtam erről a témáról leírást.
A többit köszi!.
-
Soak
veterán
Most a terhelhetőség nő lineárisan vagy a terhelés? El lehet szurni, mindent el lehet. Nyilván pár száz oldal letöltésnél per nap nem fog senkinek feltünni hogy egy szar az adatbázisod mert megoldja erőből a géped.
Amit tudsz optimalizálni, hogy 1. Az oszlopokat a bennük tárolt adatra alakitod a lehető legjobban 2. Olyan query-ket írsz amik lehetőség szerint indexek mentén tudnak haladni.
De ha nagy terhelésű rendszert tervezel és fontos a rendelkezésre állás akkor érdemes átnézni a nem relációs adatbázisokból egy-kettőt . Bizonyos feladatokra nagyon jók, de elég sok még gyerekcipőben jár . Vannak hatalmas előnyeik a relációs adatbázisokkal szemben (meg hatalmas hátrányaik is nyilván) . De pl egy cassandrával elég jól tudsz egy clusteren belül terhelés elosztani és az adatbiztonságod is lehet jó egyszerre.
-
Lacces
őstag
skálázhatóság alatt olyasmit értek, ha jól fordítom angolról, hogy amikor terhelés történik az alkalmazásnál akkor ha nő a kliensek kérése, akkor a rendszer terhelhetősége lineárisan nő, mint a mysql esetében is, és nem exponenciálisan.
Csak ahogy olvastam el lehet ezt szúrni, és nem lineárisan növekszik hanem rosszabbul... de már nem tudom melyik weboldalon, de azóta találtam más-mást is, és úgy látom, hogy ez inkább a hardverre vonatkozik (cache stb) a skálázhatóság és nem az adatbázis struktúrára. -
Lacces
őstag
válasz
Sk8erPeter #1008 üzenetére
Köszi, elég béna voltam most keresésben... én valahogy nem találtam normálisat... kösz
-
Sk8erPeter
nagyúr
Jó kulcsszavakat beírva elég gyorsan lehet találni válaszokat, például:
Nem tudom, milyen, nem próbáltam még.
A másikra majd a többiek.
-
Lacces
őstag
válasz
Sk8erPeter #1006 üzenetére
Yeap, utána eszembe jutott... mysql workbench
.
Úgy értettem, mint a phpmyadmin, aminek segítségével a mysql adatbázist tudod "kezelni" weblapon keresztül, csak ugye a phpmyadmin-nak kell, hogy a webszerveren legyen telepítve és futattva a php. Ha jól tudom a phpmyadminnak meg mindegy, hogy linux/windows, a lényeg a webszerver neki (apache, iis)
Na én meg ilyesmit akartam java alaponMásik kérdésem ami nekem homály, ez a skálázhatóság dolog. Vannak sémák arra, hogy hogyan lehet egy mysql adatbázist megtervezni, hogy jól skálázható legyen?
-
Lacces
őstag
Sziasztok!
Van grafikus felület mysql adatbázishoz Java alapú szerverhez (java nyelven írt vagy akármi), valami olyasmi, mint a phpmyadmin.
A válaszokat előre köszönöm
-
laracroft
senior tag
Köszönöm a sok hozzászólást, remélni sem tudtam, hogy ennyi segítséget kapok!
Próbálom őket!
Köszönöm! -
martonx
veterán
válasz
laracroft #998 üzenetére
Ötlet látatlanban:
1. csinálsz egy alselectet:
select account, line, leiras, min(ido) as minido, max(ido) as maxido
from naplo
where LEIRAS like '%Helyszínen%' or LEIRAS like '%Leellenõrizve%'
group by account, line2. majd ezt az alselectet felhasználva
select account, line case when timestampdiff(minute, maxido, minido) > 15 then 2 else 1 end as eredmeny
from fenti_alselect -
Apollo17hu
őstag
válasz
laracroft #998 üzenetére
Írtam egyet, talán használni tudod, bár én nem MySQL-t, hanem SQL-t használok:
SELECT sub2.account
,sub2.line
,CASE WHEN sub2.ido_helyszinen IS NOT NULL
AND sub2.ido_leellenorizve IS NOT NULL
AND sub2.diff_fl IS NOT NULL
THEN 2 -- ha helyszínen és leellenőrizve is van 15+ perc különbséggel
WHEN sub2.ido_helyszinen IS NULL
AND sub2.ido_leellenorizve IS NULL
THEN 0 -- ha helyszínen és leellenőrizve sincs
ELSE 1 -- minden más esetben
END db
FROM (SELECT sub1.account
,sub1.line
,sub1.ido_helyszinen
,sub1.ido_leellenorizve
,CASE WHEN (sub1.ido_helyszinen - sub1.ido_leellenorizve)*1440 > 15
THEN 'x'
END diff_fl
FROM (SELECT t.account
,t.line
,MIN(CASE WHEN t.leiras LIKE '%Helyszínen%'
THEN t.ido
END) ido_helyszinen
,MIN(CASE WHEN t.leiras LIKE '%Leellenõrizve%'
THEN t.ido
END) ido_leellenorizve
FROM naplo t
WHERE 1=1
AND (t.leiras LIKE '%Helyszínen%' OR t.leiras LIKE '%Leellenõrizve%')
GROUP BY t.account
,t.line) sub1) sub2 -
Apollo17hu
őstag
válasz
laracroft #998 üzenetére
Töröm a fejem rajta, de kicsit homályos, amit írtál. Pontosan milyen eredményt szeretnél? (Olyan példa jó lenne, amilyet az előző kérdésedben írtál.) A "line" mező biztosan az ügyfelet azonosítja? Arra elég az "account", nem? A "line" gondolom, valamilyen rekordazonosító/bejegyzésazonosító, tehát erre nincs szükséged a lekérdezés eredményében. (Vagy igen?)
Egy ügyfélhez bármennyiszer tartozhat a 'Helyszínen' és 'Lellenőrizve' kifejezéseket tartalmazó bejegyzés vagy csak 1-1 (= 2) db? Tehát ügyfelenként csak 0, 1 és 2 érték várható?
Új hozzászólás Aktív témák
Hirdetés
- LG 27GR95QL - 27" OLED / Limitált LoL Edition / QHD 2K / 240Hz & 0.03ms / NVIDIA G-Sync / FreeSync
- Szép állapotban levő Apple iPhone 12 Pro Max 128GB / 12 hó jótállás
- LG 55G4 - 55" OLED evo - 4K 144Hz & 0.1ms - MLA Plus - 3000 Nits - NVIDIA G-Sync - FreeSync Premium
- Dell Latitude 3340 Core i3-4005U CPU hibás laptop
- Bomba Ár! Fujitsu LifeBook E752 - i5-3GEN I 8GB I 320-500GB I DVDRW I 15,6" HD I Cam I W10 I Gari!
Állásajánlatok
Cég: FOTC
Város: Budapest