- Karácsonyfaként világíthat a Thermaltake új CPU-hűtője
- Az USA vizsgálja a RISC-V kínai terjedésének kockázatát
- Kicsit extrémre sikerült a Hyte belépője a készre szerelt vízhűtések világába
- Egészen nagy teljesítményspektrumon fedné le a mobil piacot az AMD
- Kihívás a középkategóriában: teszten a Radeon RX 7600 XT
- Azonnali VGA-s kérdések órája
- OLED TV topic
- Gaming notebook topik
- AMD K6-III, és minden ami RETRO - Oldschool tuning
- Milyen notebookot vegyek?
- Azonnali informatikai kérdések órája
- Multimédiás / PC-s hangfalszettek (2.0, 2.1, 5.1)
- Audiokultúra - Hi-Fi-ről hifisen
- E-book olvasók
- Magyarországra is megérkezik az LG új okosmonitora
Hirdetés
-
Új Beats fej- és fülhallgatók jelentek meg
ma Frissítette a Solo termékcsaládot az Apple házi audiomárkája.
-
Kicsit extrémre sikerült a Hyte belépője a készre szerelt vízhűtések világába
ph A cég megoldása centralizált vezérelhetőséggel, masszív radiátorral és robusztus ventilátorokkal igyekszik vásárlásra csábítani.
-
Konzolokra is megjelenik a Fera: The Sundered Tribe
gp A kooperatív szörnyvadászós játékhoz a minap egy friss trailert kaptunk.
Új hozzászólás Aktív témák
-
B.A.T.
tag
Bocsi, az kimaradt, hogy phpMyAdmin-t használok.
"A vízipipa bölcsességet húz ki a filozófus ajkai közül, és befogja a száját a bolondnak."
-
B.A.T.
tag
A sor meg valójában oszlop Bocsi csak siettem, szóval oszlopot adtam hozzá természetesen, és azt próbáltam elsődleges kulcsnak beállítani.
"A vízipipa bölcsességet húz ki a filozófus ajkai közül, és befogja a száját a bolondnak."
-
B.A.T.
tag
Ugyanazt importáltam, jópárszor újranyomtam a dolgot, a szerkezetet is néztem, nem volt benne elsődleges kulcs.
Arra is gondoltam, hogy zavarja az első adatbázis, amit létrehoztam, és vmiért ütköznek egymással, de ez nem lehet mivel ezeknek elméletileg és gyakorlatilag is teljesen függetlennek kell lenniük egymástól + akkor a többi táblában sem hagyná, hogy ugyanazt állítsam be primary-nak, mint amit az első esetben.
"A vízipipa bölcsességet húz ki a filozófus ajkai közül, és befogja a száját a bolondnak."
-
Male
nagyúr
Siettem, benéztem... a tábla elemei között az adott oszlopban van legalább két azonos.
Próbáld meg így:
SELECT `amitprimarynekakarsz`, COUNT(*) FROM `tablaneve` GROUP BY `amitprimarynekakarsz` ORDER BY 2 DESC;
Ha bármelyiknél több lesz, mint egy a COUNT, akkor megvan miből van több, és mi akadályoz.
-
B.A.T.
tag
Így már megvan mi a gond. Beírtam a lekérdezést, amit adtál. Alapból minden sorban ugyanazt az értéket vették fel az azonosítónak szánt oszlop mezői. A dolgot meg ott szúrtam el, hogy utólag akartam primaryt csinálni a mezőkből. AUTO_INCREMENT-et nem tudtam beállítani mert ahhoz alapból primarynak kellett volna lenniük, így viszont csak akkor működött volna ha egyenként átírom a sorokat.
Aztán észrevettem, hogy amikor hozzáadok a táblához egy új oszlopot (kövezzetek meg, de phpMyAdmin így hívja ) akkor kell az Indexet Primaryra állítani, és így már az A_I-t is engedi. Szóval először jöl csináltam, aztán meg nem
Köszi a helpet
"A vízipipa bölcsességet húz ki a filozófus ajkai közül, és befogja a száját a bolondnak."
-
Amartus
senior tag
Azért itt kérdezem, mert esély nincs rá, hogy a postgresql-nél valaki válaszolna.
Tud valaki a postgresql-hez ingyenes adatbázis designer alkalmazást?A Navicat pl. ilyen, de az fizetős.
Istenem, tele van csillagokkal...
-
Panthera
őstag
Üdv!
Van tapasztalat arra vonatkozóan, hogy Windows Server 2012/2016 alatt a MySQL szerver fut-e rendesen?
Manapság [MySQL Community Server] néven kell keresni?Köszönöm!
-
martonx
veterán
válasz Panthera #1963 üzenetére
Mindenképpen érdemes latest stable-re váltani, ha már úgyis dolgozni kell vele. Viszont ez esetben picit izgi tud lenni a DB migrálás, illetve ha szarul megírt PHP használta (más komolyabb programnyelvet nem tudok elképzelni, ami MySql-re alapozna ), akkor lehet annak is lesznek bajai egy újabb MySql verzióval.
Én kérek elnézést!
-
Keem1
addikt
Sziasztok!
Adott egy sematikus query-m, jelenleg így néz ki:SELECT * FROM tabla WHERE mezo1 LIKE 'kifejezes%'
Szeretném, ha ez úgy működne, hogy a
mezo1 LIKE 'kifejezes%'
a tábla egy másik értékétől (legyen mezo2) függően nyitott végű vagy zárt végű lenne.mezo2 értéke lehet 1 vagy 0. Ha mezo2=1, akkor nyitott a LIKE:
SELECT * FROM tabla WHERE mezo1 LIKE 'kifejezes%'
ellenben ha mezo2=0, zárt a LIKE:
SELECT * FROM tabla WHERE mezo1 LIKE 'kifejezes'
Töröm a fejem, de a megoldás nem ugrik be.
Furcsa egy kicsit, mert a lekérdezés egy értéktől függ, de az a baj, hogy ez fontos, hogy így legyen. És épp ezért nem áll össze nálam.Szerk
Átfogalmazom!
A lekérdezésünk változatlan lenne:SELECT * FROM tabla WHERE mezo1 LIKE 'kifejezes%'
Azonban ma mezo2=1, az eredményhalmazból kizárnánk az olyan találatot, ami csak LIKE 'kifejezes%' esetén adna eredményt, míg LIKE 'kifejezes' esetén viszont nem. Ha az eredmény mezo2 értéke 0, akkor ha amúgy a lekérdezésnek megfelel, akkor mindegy, hogy a % ott van-e vagy sem, találatként értelmezzük.
[ Szerkesztve ]
-
Apollo17hu
őstag
Szia!
Még annyi, hogy az OR operátor használata bizonyos esetekben lassíthatja a leválogatást, ezért - ahol lehet - célszerű CASE WHEN -nel kiváltani. Pl. így:
SELECT * FROM tabla WHERE
CASE
WHEN mezo2=0 AND mezo1 LIKE 'kifejezes%' THEN 1
WHEN mezo2=1 AND mezo1 LIKE 'kifejezes' THEN 1
END = 1 -
Keem1
addikt
válasz Apollo17hu #1970 üzenetére
Mindig tanul az ember valamit!
-
cidalain
veterán
lenne kis szakmai jellegű kérdésem.
legyen egy egyszerű adatbázis:
timestamp | data, ahol timestamp datetime, és data float, timestamp az elsődleges kulcs.
ebbe értékpárokat szúrok be. az érték lehet jó, és lehet rossz. a rossz érték kódja -9999, minden más esetben jó (ez egy tudatosan választott rossz érték, jellemzően -300 nál nincs kisebb jó érték). a rossz értéknek is van információtartalma az időpont miatt, tehát mindenképpen szerepelnie kell.az adatbeszúrás egy bejövő adathalmaz alapján történik, előfordulhat, hogy jön olyan adat is újra, ami már korábban bekerült az adatbázisba. ezért INSERT IGNORE INTO -val tenném a dolgokat az adatbázisba.
ez szuper.ugyanakkor jöhet olyan jó adat is később, aminél az első beszúrásnál hibás érték volt, és ott jelenleg -9999 van az adatbázisba. itt jó lenne ha ez lecserélődne a jó értékre. erre jött a REPLACE INTO ötlet, ami az új adatokat simán beszúrja, a már meglévőket kérdés nélkül update-eli. ezzel viszont az a bajom, hogy egy meglévő jó értéket felül tudja írni ha az új adathalmazban ott rossz érték van.
igazából a kettő kombinációja lenne jó, hogyha van már olyan időpont az adatbázisban, és az értéke jó, akkor hagyjuk, ha nem jó az érték akkor cseréljük. ha nincs még ilyen időpont akkor szúrjuk be, bármilyen érték is tartozik hozzá.
lehetőség szerint, mivel az adatbázis nagyon nagy lesz, nem szeretném előbb lekérni az adathalmazban szereplő időpontokra a bázis aktuális tartalmát, és kiemelezve eldönteni, hogy melyik adatot kell insert-elni/update-elni, hanem csak úgy bezuttyantani, de jó lenne ha replace egy feltétel függvényében futna le.
van lehetőség ilyesmire?
vagy csináljam azt, hogy a bejövő adathalmazt kétfelé veszem?
ha az érték jó, akkor REPLACE INTO
ha az érték rossz, akkor IGNORE INTO
és így ha rossz érték van, akkor csak abban az esetben kerül be, ha ahhoz az időhöz még nem volt semmi?[ Szerkesztve ]
>> GearBest Club Veszprém << >> https://www.facebook.com/gbc.veszprem <<
-
cidalain
veterán
válasz martonx #1973 üzenetére
igen ettől félek én is
azt kell mérlegelnem, hogy mi a fontos, a gyorsaság, vagy az alaposság.
simán előfordulhat hogy a beszúrandó adathalmaz csak 100 értéket tartalmaz, így ez esetben az adatbázisból lekérdezés, és elemzés PHP-ban még vállalható idő alatt lemegy. Viszont az is lehet hogy 15000 adat jön be egyszerre, akkor viszont úgy lekérdezni, és elemezgetni, majd válogatni és úgy beszúrni problémás...>> GearBest Club Veszprém << >> https://www.facebook.com/gbc.veszprem <<
-
cidalain
veterán
válasz cidalain #1974 üzenetére
Az a verzio lesz valoszinuleg, hogy mivel a bejovo adathalmazban nem osszevissza vannak idopontok, es az adatok fejreszeben benne van a kezdo es vegidopont, igy le fogom kerdezni az adatbazisbol elore a start-end idopont kozotti hibas erteku bejegyzeseket.
Ez jo esetben 0 bejegyzest fog tartalmazni, rossz esetben ugye sokat. De a bejovo adathalmaz 80%-ban nem tartalmaz 250-nel tobb adatot, igy az arra az idopontra vonatkoztatott hibas adatok sem lehetnek tobben
A bejovo adatok fajlban vannak soronkent kell feldolgozni, igy tudom csekkolni az elore lekerdezett hibas ertekesek idopontjanal, hogy lett e jo ertek helyette.
Igy ossze tudok allitani egy INSERT IGNORE-t az adatok nagy reszere, es egy REPLACE beszurast azokra amiknel hibat tartalmazott a bazis.Igy egy SELECT lenne csak, egy INSERT IGNORE, es adott esetben egy REPLACE utasitas, ami azert meg vallalhato, a PHP-ban a check sem lesz talan veszes idoben.
A check-et parameterezhetore irom, igy ha nagyon sok adat jonne, vagy valami, akkor ki tudnam kapcsolni.
>> GearBest Club Veszprém << >> https://www.facebook.com/gbc.veszprem <<
-
biker
nagyúr
Lenne egy elméleti kérdésem. Keresés-sebesség kapcsán.
Ha van egy tábla, mondjuk
id, text, date
és ebben keresek szabad szavasan a text mezőben, akkor az ugye egy időegységHa ezt így készítem többnyelvűre, hogy
id, text_hu, text_en, text_de, date
és minden nyelvben keresek előfordulást, az 3 időegység, vagy esetleg kettő, de mindenképpen több mint egy!De ha a többnyelvű szöveget egy text mezőben tárolom pl {:hu}szöveg{:en}text{:de}sprache{:} módon, akkor hiába lesz kbyte-ra ugyanannyi a tábla, mivel minden szöveg egy oszlopban van, a keresés ideje szintén egy időegység nem? és egy keresési parancsal tudok minden nyelvre előfordulást keresni
Persze százezer sorokról beszélünk, több nyelven.
Elektromos autó töltő berendezések | Mesterséges növényvilágítás | Mai ajánlatunk: www.gerisoft.hu | www.e-autotoltokabel.hu | www.agrar-vilagitas.hu |
-
biker
nagyúr
De mysql szempontból kéne megközelíteni.
3 mező az 3 keresés3 üveg 0,33-as sört lassabban iszol meg, mint egy üveg literes sört, mert le kell tenni, és másikat felvenni
Elektromos autó töltő berendezések | Mesterséges növényvilágítás | Mai ajánlatunk: www.gerisoft.hu | www.e-autotoltokabel.hu | www.agrar-vilagitas.hu |
-
Male
nagyúr
3 mező 3 keresés? Szerintem ez nem darabra megy, mivel szövegben keresel... hogy az három mezőre van szétosztva egymás mellé vagy egyben van, mindkét esetben ugyan annyi szöveget kell betölteni, és ugyan annyit kell átnéznie hozzá ...de sonar jól mondja, csinálsz egy próbát, és kiderül ...viszont ha megcsinálod, majd írd be az eredményt, kíváncsi vagyok
( értem, hogy te a 3 cellás megoldásnál beírod OR-ral, és az szemre olyan, mintha háromszor annyi munka lenne a MySQL számára, de nem hinném, hogy ennyire "buta" lenne a MySQL motor, hogy így is hajtja végre, hanem betölti azt a három egymás melletti mezőt, ami esélyes, hogy fizikailag is egymás mellett lesz, és végignézi a szöveget az első találatig, ez pedig szerintem a mérhetetlen különbség tartományába fog esni ) -
biker
nagyúr
Na, kipróbáltam, remélem mindent jól következtettem ki
Leginkább az ÉS lassítja.
Ha ugyanazt keresem 1x, vagy 2x, vagy 2 mezőben egyszer, akkor OR esetén mindegy.
AND esetén ha ugyanazt keresem, nem gond, de ha két külön feltételt AND-el, akkor mindkét esetben lassulPersze, ez a saját gépemen, ahol minden erőforrás itt van a mysql-nek, vhoston lehet hogy jobban kijön a különbség, hogy nem 0,0030 vs 0,0020 hanem egy tizedessel beljebb jövünk, de nem lényeg.
mysql teszt, 242,7mb tábla
v1: 744.000 sor szöveg keresés egy mezőben, egy feltétellel
SELECT * FROM `fitness_naplo_dup` WHERE `esemeny` LIKE '%rendszer%'
Sorok megjelenítése 0-24 (összesen 68691, A lekérdezés 0.0032 másodpercig tartott.)v2: 744.000 sor szöveg keresés egy mezőben, két feltétellel
SELECT * FROM `fitness_naplo_dup` WHERE `esemeny` LIKE '%rendszer%' OR `esemeny` LIKE '%törölt%'
Sorok megjelenítése 0-24 (összesen 100520, A lekérdezés 0.0030 másodpercig tartott.)SELECT * FROM `fitness_naplo_dup` WHERE `esemeny` LIKE '%rendszer%' AND `esemeny` LIKE '%törölt%'
Sorok megjelenítése 0- 0 (összesen 1, A lekérdezés 2.1407 másodpercig tartott.)v3: 744.000 sor szöveg keresés két mezőben, egy feltétellel
SELECT * FROM `fitness_naplo` WHERE `esemeny` LIKE '%rendszer%' AND `esemeny2` LIKE '%rendszer%'
Sorok megjelenítése 0-24 (összesen 68691, A lekérdezés 0.0018 másodpercig tartott.)SELECT * FROM `fitness_naplo` WHERE `esemeny` LIKE '%rendszer%' OR `esemeny2` LIKE '%rendszer%'
Sorok megjelenítése 0-24 (összesen 68691, A lekérdezés 0.0026 másodpercig tartott.)v4: 744.000 sor szöveg keresés két mezőben, két feltétellel
SELECT * FROM `fitness_naplo` WHERE `esemeny` LIKE '%rendszer%' AND `esemeny2` LIKE '%törölt%'
Sorok megjelenítése 0- 0 (összesen 1, A lekérdezés 1.3561 másodpercig tartott.)SELECT * FROM `fitness_naplo` WHERE `esemeny` LIKE '%rendszer%' OR `esemeny2` LIKE '%törölt%'
Sorok megjelenítése 0-24 (összesen 100520, A lekérdezés 0.0026 másodpercig tartott.)Elektromos autó töltő berendezések | Mesterséges növényvilágítás | Mai ajánlatunk: www.gerisoft.hu | www.e-autotoltokabel.hu | www.agrar-vilagitas.hu |
-
Male
nagyúr
Köszi a tesztet!
Akkor csak jól logikáztam, hogy nem számít igazán, sőt, ahogy látom, még a két külön mezős gyorsabb is volt egy picivel ( v1 vs. v3 másodikja, ez volt az eredeti kérdésed, ha akkor jól értettem )
(amikor még én próbálgattam időszükségleteket, akkor a JOIN volt a legdurvább, nagyságrendi eltéréssel a többihez képest... bár ott más volt a teszt, egy weboldal lett kielemezve, hogy milyen lekérések hányszor fordulnak elő a működés során, és ezek mennyi időt visznek el.. a JOIN ritka volt, pár százalék, de az össz időben mégis sokkal többet vitt el, mint bármi más) -
SaNyEe
aktív tag
Sziasztok,
Találkoztam egy érdekes problémával (mysql "újonc" vagyok, Oracle vonalon mozgok alapvetően)
Egy Select rettenet hosszú ideig fut, a problémás selectet "redukáltam" a problémás részre. Ennek explainje a következő:
mysql> explain SELECT a.clock
-> FROM alerts a, events e
-> WHERE e.eventid=a.eventid;
+----+-------------+-------+--------+---------------+---------+---------+------------------+---------+-------------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+----+-------------+-------+--------+---------------+---------+---------+------------------+---------+-------------+
| 1 | SIMPLE | a | ALL | alerts_3 | NULL | NULL | NULL | 3723509 | NULL |
| 1 | SIMPLE | e | eq_ref | PRIMARY | PRIMARY | 8 | zabbix.a.eventid | 1 | Using index |
+----+-------------+-------+--------+---------------+---------+---------+------------------+---------+-------------+
2 rows in set (0.00 sec)a tábla alerts_3 indexe nem kerül használatba. A csatolt mezők bigint(20) unsigned típusúak. Baloldali tábla 166 millió, a jobboldali tábla 3,7 milliós rekordmennyiségű.
Not null constraint van mindkét mezőn, de default null be van állítva (5.6 verzió)
A táblák innodb tárolómotort használnakAmikor nincs alerts_3 index használatban a query futási ideje 48sec.
A force index(alerts_3) megadásával 1.65sec-re redukálódik a futási idő.
Statisztikákat ma frissítettem közvetlen tesztelés előtt, azok aktuálisak.Miért nem használja a mysql a rendelkezésére álló indexet? Ott van és mikor kényszerítem, működik.
Miután elkezdtem játszani a selecttel és kivettem a tábla oszlopát (vagy betettem az index-el rendelkező oszlopot) a select clause-ból így alakultunk át:
mysql> explain SELECT a.eventid
-> FROM alerts a, events e
-> WHERE e.eventid=a.eventid;
+----+-------------+-------+--------+---------------+----------+---------+------------------+---------+-------------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+----+-------------+-------+--------+---------------+----------+---------+------------------+---------+-------------+
| 1 | SIMPLE | a | index | alerts_3 | alerts_3 | 8 | NULL | 3723507 | Using index |
| 1 | SIMPLE | e | eq_ref | PRIMARY | PRIMARY | 8 | zabbix.a.eventid | 1 | Using index |
+----+-------------+-------+--------+---------------+----------+---------+------------------+---------+-------------+
2 rows in set (0.00 sec)Hogy lehetne a forrás SQL átírása nélkül rábírni a mysql-t, hogy az a.eventid oszlopon is használja az indexet annak ellenére, hogy valóban a tábla minden sora candidate row és jó ötletnek tűnhet első körben felolvasni mindent a blokkokból?
[ Szerkesztve ]
-- end of transmission --
-
SaNyEe
aktív tag
Nem segitett, force index kellett, ugy lett 1.65s a futasi ido. Az alkalmazas forrasahoz nincs hozzaferesem, elegans modjat (db szintu) szeretnem valasztani a problema megoldasanak.
Ehhez egy uj app release kene es az is csupan egy szepsegtapasz lenne
Masik erdekesseg amibe botlottam es nagyon meglepett oracle utan A+B tabla inner joinnal letrehozott, mindket tabla oszlopait tartalmazo rendezett, limitalt lista letrehozasanak koltsege iszonyat magas volt. A tabla 4 millio, b tabla 4db rekordot tartalmazott.
Az eredmeny eloallitasa kb 60 sec volt, ha csak a tabla oszlopait jelenittettem meg az kb instant megjelent. (1db where clause volt a tablara, indexelt)
-- end of transmission --
-
martonx
veterán
Egyrészt úgy rémlik mintha írtad volna a MySql verziót, és mintha valami elég elavult verziót használnál. Másrészt a MySql közismerten az Oracle ingyenes alternatívája, és nyilván nem véletlenül ingyenes
Ha mindenképpen az ingyen vonalon akartok mozogni akkor MariaDB vagy PostgreSql sokkal jobb választás, mint a MySql. Szerintem.Én kérek elnézést!
-
martonx
veterán
Simán lehet, de ha megtennéd, hogy pontokba szedve cáfolod (több szinten is ), nem pedig pont hogy az igazamat bizonyítod, a szimpla select, index nem használós bizonyítással? Ettől még persze nincs baj a MySql-lel móricka projektekhez simán jó, és ingyenes, de komoly enterprise üzletmenetet biztos, hogy soha nem bíznék rá. Szerintem.
Én kérek elnézést!
-
SaNyEe
aktív tag
válasz martonx #1989 üzenetére
Már látom, hogy nem a megfelelő fórumhoz fordultam
Enterprise üzemet nem bíznál rá? Hm, titoktartási szerződés miatt nem nyilatkozhatok, de meglepődnél mekkora vállalatok, milyen rendszerei futnak mysql felett Bár kinek mi a móricka szint az relatív(Attól, hogy valahogy konfigurálva van perpill az innodb engine s az optimájzer, nem jelenti azt, hogy más beállításokkal ne működne jobban, vagy épp optimálisan)
Az Oracle-t is be tudom neked úgy állítani exadatán akár, hogy arcpirongatóan gyorsnak tűnjön mellette egy access "adatbázis"[ Szerkesztve ]
-- end of transmission --
-
baracsi
tag
Az index problémára nem tudok mit mondani, lehet tényleg régi a MySQL-ed és azért csinálja, érdemes egy friss verzión megnézni, hogy hogyan viselkedik, másrészt pedig igazad van, elég sok komoly cég használja a MySQL-t ([link]), és valóban elveszik a PH!-s MySQL topic komolyságát az itt megjelenő "móricka projekt"-es hozzászólások. Egy "szerintem" hozzá nem értő véleményét olvassa egy másik hozzá nem értő, majd jövünk mi programozók, hogy MySQL fut a cége rendszere alatt, akkor bizony a másik hozzá nem értő megkérdőjelezheti azt, hogy jó lóra tesz-e adott szoftver választásával, úgyhogy tényleg óvatosan a meggondolatlan kijelentésekkel!
[ Szerkesztve ]
-
SaNyEe
aktív tag
válasz baracsi #1991 üzenetére
Ami a számomra furcsa az optimizerben, hogy preferálja a komplett adathalomhoz való hozzáférést az adott where záradékban, mert olyan oszlopokat sorolok fel a select záradékban, amik végül a select statement eredményeként megjelen(het)nek.
Nyilván ez sokkal-sokkal több szekvenciális és random IO-val jár, mintha csupán az indexekből táplálkozna, majd random hozzáférne a kiadni szükséges blokkokhoz (csupán egyszer egy adatblokkhoz), ahogy a példa jól mutatja is.MySQL ide vagy oda, biztos vagyok benne, hogy ez beállítási kérdés lesz Ekkora multinál, mint aminél felmerült a téma, egy release upgrade még sztem min 1 évet várat magára, addig maradnak a patchek max (:
Megszakértetem a hivatalos supporttal is úgyamúgy, ha valami eredménye lesz azt majd megosztom, csak sokszor szakértői fórumokon néha jön gyorsabban is válasz.
[ Szerkesztve ]
-- end of transmission --
-
martonx
veterán
válasz baracsi #1991 üzenetére
Az oké, hogy ebben a linkelt listában a Facebooktól kezdve egy csomóan benne vannak, de vajon ők tényleg MySql-t használnak out-of-the-box? Vagy az itt szereplő felhasználók döntő többsége már rég saját storage engine-el megy MySql alatt, mint pl. a Facebook is, csak épp lehet rájuk hivatkozni, hogy szegről-végről némi közük van a MySql-hez.
Én kérek elnézést!
-
sonar
addikt
A tudást mástól kapjuk, a siker a mi tehetségünk - Remember: Your life – Your choices!
-
MineFox54
őstag
Sziasztok!
Úgy látom nem túl aktív a topik, de megpróbálkozom.
Van egy táblám.
leegyszerűsítve (jóval több oszlopról beszélünk de most ennyi a lényeges)tábla -> id|keresett
Ebből szeretném megtudni egy lekérdezéssel, hogy hány előfordulása van az keresett oszlopban bizonyos stringeknek, ez most legyen "7","14","22".Tehát ha a tábla
1|7
2|14
3|22
4|22
1|7
Akkor a lekérdezés végén azt kapjam vissza hogy pl
7cnt|14cnt|22cnt
2 |1 | 2Jelenleg ezzel próbálkoztam, de ez csak azt dobja vissza hogy hány sor volt ami a feltételeknek megfelelt.
COUNT("7") as 7cnt,COUNT("14") as 14cnt,COUNT("22") as 22cnt -
Apollo17hu
őstag
válasz MineFox54 #1996 üzenetére
SELECT
SUM(CASE WHEN keresett = 7 THEN 1 ELSE 0 END) AS "7cnt",
SUM(CASE WHEN keresett = 14 THEN 1 ELSE 0 END) AS "14cnt",
SUM(CASE WHEN keresett = 22 THEN 1 ELSE 0 END) AS "22cnt"
FROM tabla...vagy próbálkozhatsz a PIVOT funkcióval is.
Amúgy biztos nem egy mezei
GROUP BY keresett
-re lenne szükséged? -
MineFox54
őstag
válasz Apollo17hu #1997 üzenetére
Igen, a GROUP BY megoldás, de a feldolgozási oldalon macerásabb (nem csak egy echo-ba megy ). Mindegy, megcsináltam, így marad.
-
MineFox54
őstag
válasz Apollo17hu #1997 üzenetére
Köszönöm.
Nos, lenne még egy kérdésem.
Azt kellene megtudnom hogy az éppen vizsgált sor hányadik helyen szerepel, ha a táblát szűrjük bizonyos feltételekre.Tehát kifejtve:
tábla:id|sorrendalkoto|feltétel
1|1250|false
2|1235|true
3|1345|true
4|561|false
5|6235|trueTegyük fel, van egy select-em, amivel ebből a táblából olvasok adatokat. Ebbe a selectbe szeretnék generálni egy olyan mezőt, amellyel megtudom, hogy: egy
WHERE feltétel=true ORDER BY sorrendalkoto desc
feltételek alapján hanyadik helyen szerepel a táblában. Fontos lenne hogy on-the-run működjön a dolog.
Várt result:id|sorrendalkoto|helyezés
5|6235|1[ Szerkesztve ]
-
MineFox54
őstag
válasz MineFox54 #1999 üzenetére
Solved.
A megfejtés így néz ki a valós táblámnál:
(nem biztos hogy a legjobb megoldás, ha tudtok jobbat, hallgatom)SELECT indulas,
beerkezes,
tav,
nev,
Find_in_set(beerkezes, (SELECT Group_concat(beerkezes ORDER BY beerkezes
ASC)
FROM beerkezes
INNER JOIN versenyzo AS x
ON beerkezes.rfiddata = x.rfiddata
WHERE beerkezes <> '00:00:00'
AND v.tav = x.tav)) AS rank
FROM beerkezes
INNER JOIN versenyzo AS v
ON beerkezes.rfiddata = v.rfiddata
WHERE beerkezes <> '00:00:00'
ORDER BY beerkezes DESC
Új hozzászólás Aktív témák
- Elemlámpa, zseblámpa
- Azonnali VGA-s kérdések órája
- OLED TV topic
- Súlyos adatvédelmi botrányba kerülhet a ChatGPT az EU-ban
- Gaming notebook topik
- Elektromos rásegítésű kerékpárok
- AMD K6-III, és minden ami RETRO - Oldschool tuning
- EA Sports WRC '23
- Milyen notebookot vegyek?
- Kínai, és egyéb olcsó órák topikja
- További aktív témák...