- Samsung Galaxy Watch (Tizen és Wear OS) ingyenes számlapok, kupon kódok
- Xiaomi 15 - kicsi telefon nagy energiával
- Magyarországon is kapható a Moto G85 5G
- Redmi Watch 5 - formás, de egyszerű
- Heteken belül ár/érték bajnokot avat a Poco
- VoLTE/VoWiFi
- Xiaomi 14T - nem baj, hogy nem Pro
- iPhone topik
- Google Pixel topik
- Csíkszélességben verné az Exynos 2600 a Snapdragon 8 Elite 2-t
Új hozzászólás Aktív témák
-
#2237
hellsing71
tag
biker
#2235
hellsing71
tag
De, összevonhattam, simán megcsinálta. Csak ahogy írtam: minek?
SELECT COUNT(*) FROM `table1`UNIONSELECT COUNT(*) FROM `table1` WHERE MATCH( field1, field2, field3, field4 ) AGAINST( 'Lookforthis' IN BOOLEAN MODE);Eredmény:
count(*)
13500
238sZERK: KÖSZÖNÖM AZ ÖTLETEKET! (HÜJE cAPSlOCK)
-
#2234
hellsing71
tag
biker
#2232
hellsing71
tag
Bocs, ez nekem nem jön át. Neked is 3 sql query-d van:
Összes rekord a táblában:
SELECT COUNT(*) AS allcount FROM fitness_naplo{$_SESSION['helyszin']}Szűrt rekordok teljes száma:
SELECT COUNT(*) AS allcount FROM fitness_naplo{$_SESSION['helyszin']} WHERE 1 ".$searchQuerySzűrt rekordokból a megjelenítendők tartalma:
SELECT * FROM fitness_naplo{$_SESSION['helyszin']} WHERE 1 ".$searchQuery." ORDER BY ".$columnName." ".$columnSortOrder." LIMIT :limit,:offsetÖsszevonhatnánk az első kettőt egy UNION-nal (mindig csak 2db szám az eredmény), de az 1db webszerver-db-webszerver kommunikáció elhagyásán gondolom csak századmásodperceket lehet nyerni, akkora terhelésem meg sohasem lesz, hogy ez bármit jelentsen.
-
nevemfel
senior tag
Mintha a szerveren lenne egy globális default ‘’
Igen, a mysql használ gyári defaultokat, ha nincs megadva saját:
For data entry into a NOT NULL column that has no explicit DEFAULT clause, if an INSERT or REPLACE statement includes no value for the column, or an UPDATE statement sets the column to NULL, MySQL handles the column according to the SQL mode in effect at the time:
- If strict SQL mode is enabled, an error occurs for transactional tables and the statement is rolled back. For nontransactional tables, an error occurs, but if this happens for the second or subsequent row of a multiple-row statement, the preceding rows are inserted.
- If strict mode is not enabled, MySQL sets the column to the implicit default value for the column data type.
MySQL :: MySQL 8.0 Reference Manual :: 11.6 Data Type Default Values
Egyébként érdemes felkészülni arra, hogy a jövőben egyre több mysql szolgáltató tér át a mysql 8-ra, ahol alapból a strict mode van beállítva. Általánosságban azt tapasztaltam, hogy az a query, ami strict módban működik, az működik non-strict módban is, ezért lokálisan már strict mode-ban fut a mysql nálam is, sctrict módban tesztelek mindent, egy-két esetet leszámítva, amikor az adott, jellemzően régebbi web framework egyszerűen nem működik strict mode beállítással.
-
nevemfel
senior tag
Egyelőre úgy tűnik hogy a tábláknál a default null helyett default ‘’ megoldja a problémát
Igen, a megoldás így ezesetben jó lehet, illetve aktiv VARCHAR(1) NOT NULL DEFAULT '' még jobb.
Mert eddig mondjuk 150 helyen ez nem volt hiba, a 150 tár a roossz?
A NULL tudomásom szerint mindenhol így működik, ahogy leírtam, minden relációs adatbázis kezelőben, ugyanis ezt írja elő az SQL 92 szabvány.
-
-
martonx
veterán
a régi jó hányadék MySQL Ez 2012 óta ismert feature, nem bug. MySQL Bugs: #64197: "Impossible WHERE noticed after reading const tables" messageCsak szar az üzenet, ha jól értem nincs hiba, csak valószínűleg nem hozott találatot a WHERE.
Talán ideje lenne a garázs szolgáltatókat örökre elfelejteni a vicc MySQL-jeikkel együtt, és a felhőbe menni?
-
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) -
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 ) -
henny
csendes tag
Közben a jelenlegi tárhelyemmel felvettem a kapcsolatot és segítettek. Azt írták, h felülírta a helyessel és így most működik, megkérdeztem, h mi volt a gond és azt a választ kaptam, h "USE (felhasználó nevem)".
Gondolom az volt a gond, h kolibrip_db volt az adatbázis neve.. -
-
ALFA
senior tag
ok, még egyszer utoljára megpróbálom, hátha megérted...
4, azaz négy adat összekapcsolt kezelésére van szükségem, ami SQL-ben egy nap alatt megoldható.
A hozzád hasonló dilettánsok jönnek ilyenkor az "ágyúval verébre" szövegekkel, hogy szakértőnek tűnjenek, pedig csak a dilettantizmusukat bizonyítják. Az általad misztifikált CRM vállalati adatokra való, milliós nagyságrenddel és ezres nagyságrendű kapcsolattal, ennek megfelelően hatalmas adminisztrációs terhekkel. -
ALFA
senior tag
Oh, a fene egye meg, már megint elfelejtettem egy NAS-t venni, pedig a múltkor is felírta az asszony, amkor elküldött a boltba. Melyiket javaslod, a kéket vagy a pirosat?
A letöltési link egy regsztrációs kötelezettség, amennyit értek angolul, azt írja, hogy fejlesztőknek való.
Nagy valószínűséggel alfa vagy béta verziókat adnak, és tesztelésért cserébe lehet majd frissíten működő verzióra. Nagyon nem nekem való. -
ALFA
senior tag
Nem véletlenül kérek pontos linket és leírást.
Ilyen nevű letöltést nem találtam, sugarCRM-re pedig azt írta, hogy nem free. Van egy community editon-ja, de fejlesztőknek és csak regisztráció után tölthető le.
Egy crm beüzemelése pedig nem egyszerű, sok minden kell hozzá, amiket "elfelejtenek" megemlíteni. -
martonx
veterán
Én a helyedben a dátum mezőt módosítanám mysql-ben, hogy feleslegesen ne is tárolj perc, másodpercet (ennek mellesleg az sql engine is örülni fog). És ha minden igaz, ezzel a huszárvágással meg is oldottad a problémát
Mondjuk lehet, hogy mindegyik dátumhoz ekkor még hozzá kell adni egy napot, te ismered a használt összehasonlító logikáidat. -
#1721
TomyLeeBoy
tag
biker
#1720
TomyLeeBoy
tag
-
úgy néz ki, hogy a mysql erre nem figyel ... vagy az ellenőrzés több erőforrást eszik mint ha a where feltételnél van ilyen feltétel szabva ...
- előtte 2-es loadot csinált ez a script a meglévő cuccok mellett
- most meg 0.5 fölé nem ment ...remélem így is marad :9 egyenlőre nem iszunk előre rá remélem így is marad: )
-
martonx
veterán
Egyrészt szépen felépített adatbázis lehet, ahol ugyanazon témához érdemi információ keresés történhet 10 táblában 200 oszlopban
![;]](//cdn.rios.hu/dl/s/v1.gif)
Másrészt én csinálnék egy jó nagy kereső scriptet (vagy inkább használnék valami kész kereső engine-t, mint pl. Lucene), ami X másodpercenként szépen végignyalná azt a 10 táblát, azoknak mind a 200 oszlopát. És egy külön eredmény táblába betolná az eredményeket. Így végül, amikor a tényleges keresés történik az gyors tud lenni, igaz a megjelenített adatok nem lesznek másodpercre pontosak.
-
#1439
Sk8erPeter
nagyúr
biker
#1434
Sk8erPeter
nagyúr
Ahogy előttem leírták, a kiindulási pont az volt, hogy megkérdőjelezted az indexek jelentőségét, meg a táblák szétválasztásának elvét (amit nem véletlenül szokás alkalmazni), nem pedig az, hogy "szétszedjünk darabokra". Nyilván a fejlesztésben vannak pontok, amikor az újrastrukturálás nehézkes, és az ember a határidő tartása érdekében csúnyább megoldásokra kényszerül, de ettől még az elv nem hibás. Ebben alakult ki a vita, ezekről próbáltunk győzködni, nem az volt a cél (de sztem ez egyértelmű), hogy csak azért is kritizáljunk.
"az akciós kérdésben nem értünk egyet, a többiben igen"
Eddig úgy tűnt, azt írtad le, hogy a termékek alapvető adataival egy táblában kezeled, mikor kezdődött, és zárult le egy bizonyos időszakban bevezetett akció, meg mi az akciós és korábbi ár, és hasonlók, és ezeket kell mindig felülírni módosításkor, de ha utólag ki akarnál egy kimutatást készíteni arról, hogy melyik időszakban milyen áron, milyen akció keretében, mekkora kereslet volt az adott termékre, akkor gondban lennél, mivel nincs history-szerűen nyilvántartva, korábban milyen árakon futott a termék (és mikor), csak felül van csapva a korábbi érték, aztán kész. De lehet, hogy ebben félreértés volt, és nem így kell elképzelni, abból indultunk ki, amilyen információkat leírtál. -
#1435
fordfairlane
veterán
biker
#1434
fordfairlane
veterán
Amikor szóvátették az adatszerkezet problémáit, nem arra hivatkoztál, hogy nem éri meg vele foglalkoznod, hanem hogy akkor redundáns lesz, meg lassítja a lekérdezést, és ehhez hasonlók. Márpedig ezek fals indokok, mert nem attól lesz redundáns az adatbázis, ha a relációkat a megfelelő elvek mentén feldarabolod, hanem attól, ha egyben tárolsz nem egybe tartozó adatmezőket. Ez abszolute szakmai dolog, szakmai téma, és te szakmai alapon kérdőjelezted meg a jogosságát.
Az igaz, hogy az nem igazán jó érv, hogy így "nem szép", meg hogy "nem eléggé tankönyvszerű", én ezért is próbáltam gyakorlatiasabban megközelíteni a témát, de a te indokaid pl. a sebességre vagy a lekérdezés bonyolultságára sem igazán állják meg a helyüket.
-
#1428
Sk8erPeter
nagyúr
biker
#1419
Sk8erPeter
nagyúr
"Ne viccelj, miért ne lehetne kigyűjteni egy selecttel az összes terméket ami mondjuk a köv 10 napban akciós ?"
Senki nem mondta, hogy ne lehetne kigyűjteni, de ezek szerint még mindig nem érted, hogy mi a probléma azzal az elvvel, amit alkalmazol, ami mondjuk elég szomorú. Tényleg ennyire nem vágod az alapvető normalizálási elveket?
A lényeg: az akciós és aktuális árnak, aktuális szállítónak és egyebeknek semmi keresnivalójuk ugyanabban a táblában, amiben a termékek alapvető, ritkán változó paramétereit tárolod. Most ugyanazt mondtam el másként, mint amit már korábban is leírtam."Itt az az alap tézis részetekről, csak rossz lehet mert sok oszlopa van"
Kezd tényleg fárasztó lenni. Tudtommal elég régóta vagy fejlesztő, ehhez képest bevált alapelveken vitatkozol, mint aki az évek során jól begubózott, és a saját jól megszokott tervezési elvein kívül mást nem is hajlandó elfogadni, kritikát meg aztán végképp nem. Pedig ha előveszel akármilyen jobbféle adatbázis-kezelős könyvet, ami a kezdő szinttől indít, hidd el, hogy ezekkel az elvekkel elég hamar találkozol...
fordfairlane amúgy előttem már leírta nagyvonalakban az alapvető problémákat, de erre azt reagáltad neki, hogy "az alapoktol zavaros amit irsz Egyaltalan Te erted?" - most azon kezdtél el kattogni, hogy de hiszen az akció termék nélkül nem is létezhet, de azon még mindig nem gondolkoztál el, hogy vajon miért állítjuk többen is már régóta, hogy alapvető, nem változó paraméterek egyszerűen nem tehetők egy táblába állandóan változó - és például megőrizendő - paraméterekkel (ismét leírtam, hátha átjön), mert az rengeteg kellemetlen problémát szül (átnevezési, törlési, beszúrási probléma, esetleges inkonzisztencia, és az összes többi dolog, amiről már vakerásztunk, vagy amiről még nem). Megdöbbentő ez a vita. Olyan, mintha nem lenne tiszta számodra, mire valók a kapcsolótáblák, az idegen kulcsok, egyáltalán mik azok a normálformák, miért használják manapság ezeket... Ha nem tudod, akkor inkább kérdezz vissza, miért is lenne jobb ezeket használni, de ne úgy pattintsd le magadról az egész témát, mintha még mi lennénk a korlátoltak, hogy nem fogjuk fel, hogy a Te szerkezeted milyen csodálatos (nem az). Kissé türelmetlenné teszed az embert ezzel a stílussal.=====
(#1417) Athlon64+ :
"Mi kérünk elnézést?
"
Jaja, nagyon úgy tűnik. Ne haragudj, biker. -
#1427
fordfairlane
veterán
biker
#1425
fordfairlane
veterán
Igazad van, nem jó példa. Ágyúval verébre. Ez inkább egy-egy feltételes kapcsolat lehet a legtöbb esetben, vagyis hogy a termékek egy része akciós, a többi nem. Mondjuk ebben az esetben is külön táblába tenném az akcióparamétereket, mert már megszoktam, hogy a "dolgokat", amiknek önálló attribútumai vannak (kezdet - vége), önálló objektumoként kezelem, még akkor is, ha csak egy kapcsolódó rekord lehet egy termékhez. Aztán valami ORM könyvtár elvégzi a betöltést-mentést-rekordösszefűzést.
-
#1424
fordfairlane
veterán
biker
#1422
fordfairlane
veterán
-
#1423
fordfairlane
veterán
biker
#1422
fordfairlane
veterán
Mert nalunk ugy megy, hogy kitalaljuk melyik termekunk mettol meddig akcios, nem pedig kitalaljuk holnap valami akcios lesz, de nem tudom mi
Máshol meg másként megy. Minnél nagyobb a kereskedelmi egység, annál inkább jellemnző, hogy az akciózás termékcsoportosító módon kerül kivitelezésre. Például úgy, hogy nem egy termék lesz akciós, hanem egy termékek csoportja. Majd ebbe az akcióba bevonódhat újabb termék. Aztán az akció meghosszabbodhat. Aztán kerül bele újabb termék. Aztán kikerülhet belőle bizonyos termék, mert pl. elfogy. Aztán kiderülhet, hogy túl jól sikerült az akció, ezért az összes termékre csökkenteni kell a mértékét. Vagy épp ellenkezőleg, nem sikerült túl jól, sok termék továbbra is készleten, megromlik pl. ezért növelni kell a kedvezményt az összes terméken.
-
#1421
fordfairlane
veterán
biker
#1419
fordfairlane
veterán
Itt az az alap tézis részetekről, csak rossz lehet mert sok oszlopa van
Nem az oszlopok számával önmagával van a probléma, hanem azzal a fajta adatszerkezettel, amivel letárolásra kerülnek a termékhez kapcsolódó adatok.
Jelen példa esetében a termékhez kapcsolódik egy akció, aminek vannak attribútumai, például kezdeti-, és végidőpontja. Ezt tranzitív függésnek hívják, és a probléma nem az, hogy egyben van, mert lekérdezés szempontjából ez az adatszerkezet kvázi "kész" van, csak ki kell íratni a mezőket, amire épp szükség van
A probléma a következők lehetnek:
1. beszúrási anomália
Addig nem tudsz létrehozni akciót, amíg nincs készen felvíve legalább egy termék, amihez hozzácsatolod.
2. módosítási anomália
Az akciók paramétereit az összes termékrekordon egyszerre kell végrehajtanod, különben inkonzisztens lesz az adatbázis (új akció keletkezik a semmiből, ha valami probléma folytán nem hajtódik végre minden termék rekordján a módosítás)
3. törlési anomália
Ha törölsz minden terméket, akkor az akció is törlődik magától. (Mellékhatás, amit ebben az adatszerkezetben nem tudsz megkerülni)
Ezek olyan nem várt mellékhatásai, amik problémát okozhatnak minden ilyennél, nem csak az akcióknál.
A normalizálás erről szól. Nem véletlenül találták ki több évtizede, és használják mindenhol.
És igen, ez azt eredményezheti, hogy akár egy mezőt is külön táblába kell tenni adott esetben, majd ellátni a megfelelő foreign key-jel, ( és persze erre majdhogynem automatikusan mehet rá az index, így a JOIN gyakorlatilag "költségmentes" lesz). Viszont így az adatszerkezet sokkal karbantarthatóbb lesz.
-
#1416
Sk8erPeter
nagyúr
biker
#1415
Sk8erPeter
nagyúr
Kicsit túlságosan felkaptad a vizet, senkinek nem az volt a célja, hogy itt kifejezetten téged fikázzon, nem a személyedet érte kritika, hanem azt, amit állítottál, és a tervezési/fejlesztési elveket, amiket alkalmazol - szakmai témázás során ez nagyon nem mindegy. Kezdjük ott, hogy először Te állítottad azt egy korábbi javaslatra, hogy az indexelés nem gyorsít látványosan (bullshit), és pluszban remek példaként akartad bemutatni a 30+ oszlopos szerkezetet, erre kaptad a reakciót, hogy egyrészt baromság, hogy az indexelés ne gyorsíthatna látványosan (egyébként már csak azért sem értem az állításodat, mert a Te példádban is 10+ másodperceket javított csak az index már önmagában is, az nem elég látványos? Egészen másképp hangzik, ha azt állítod, hogy önmagában egy oszlopra tett index nem biztos, hogy elég, mert ez így igaz is.), másrészt a 30+ oszlopos táblánál már felmerül a gyanú, hogy tervezési hibáról van szó. Mindkét érv meg lett indokolva, alátámasztva, nem csak levegőben röpködő nagy szavak voltak. Többfelől is kaptál reakciót, mert igen megdöbbentő dolgot állítottál, ami pont szembemegy az alapvető adatbázis-normalizálási elvekkel; erre nem az a megfelelő reakció, hogy "sok lúd disznót győz" (mintha azt üzennéd, hogy nálad van az igazság, csak mi nem értjük) - több emberrel miért ne lehetne szakmai vitát folytatni?
De könyörgöm, egy dolgot magyarázz már meg, mert nagyon kitartasz mellette: komolyan úgy gondolod, hogy az a megfelelő adatbázis-tervezési elv, hogy a termék nevével, leírásával, ehhez hasonló alapvető (ritkán változó) paramétereivel egy táblába dobod be az akciós és aktuális árat, szállítót, hasonlókat? Szerinted az a baj, ha termék_id szerint össze vannak kapcsolva a különböző adatok, és ezáltal a termék_id többször is szerepelni fog? Ezt írod: "akciók pedig símán összeköthetők ak ezdő és vég időponton keresztül, nem is értem a felvetést, miért ne lehetne?". Ez alapján komolynak tűnik, akkor viszont alapvető tervezési elveket sértesz meg, pedig ahogy már írták, ezek szétbontása tényleg az első pár adatbázis-kezelési és -tervezési lecke között van, és akkor ezek szerint az nagyon kimaradt.
Ha meg félreérthető, amit írsz, akkor próbálj meg nem úgy írni, mintha csetelnél, mert nagyon zavaró.Egyébként ezzel kapcsolatos hsz.-eket nem kell OFF-ba tenni, mert szakmai, MySQL-t érintő vitáról van szó, épp, ami a topic címe.
-
#1413
fordfairlane
veterán
biker
#1410
fordfairlane
veterán
akkor minden darabolással egy redundáns termék_ID oszloppal hízlalod az adatbázist...
Mert jellemzően nem attól lesz redundáns az adatbázis, hogy túl sok tábla kerül bele, hanem attól, hogy túl kevés. Például ebben a példában a közös akciókban szereplő termékeket nem tudod összekötni egymással, mert termékenként tárolod az akciók összes attribútumát. Aztán mi van akkor, ha egy adott termék más szállítótól érkezik, hogyan kapcsolod a kettő tételt össze, ha a termék statisztikájára vagy kíváncsi?
Ez az egész téma ráadásul egy adatbázis tervezési tanfolyam első leckéi közé tartoznak. Normálformák, ilyesmi. Alapvető dolog relációs adatbázisoknál. Ez az egész aggódás, hogy túl sok a tábla akkor szokott előjönni, ha a JOIN-ok vagy az indexek használata már lassan és nehézkesen megy, ami adatbáziskezelésnél viszont alapvető dolog.
-
#1412
Peter Kiss
őstag
biker
#1410
Peter Kiss
őstag
Arra hivatkozni, hogy redundás lesz a termék ID-ja, az kicsit megmosolyogtató, egy SQL szervernek ez nem érdekes.
Termékek tábla:
id,
név,
rövid leírás,
hosszú leírás,
cikkszám,
vonalkód,
kat_id,
+ ki mikor módosította és még e mögé a tábla mögé még egy, ami minden sort ment triggerrel.Kellene egy szállítók, és a szállítókkal összerendelő:
szállítói kód,
szállítási idő,
termék_id
+ mettől meddig ki és mikor módosítottaCímkék nyilván nem kerülhetnek ide, szintén: címkék tábla + összerendelés + audit;
ÁFA osztály inkább tartozik a kategóriához, ha egy termék csak egy kategóriában lehet.
Egy termék árát szintén külön táblában vezetjük, hogy lássuk, mettől meddig mennyi volt, és ki módosította. (Nem beszélve arról, hogy már a jelenben beszélhetünk a jövőről.)
Az akciókat belekeverni talán a legdurvább, azt eleve ki kell vezetni, hogy milyen akcióink vannak, meddig tart és mi tartozik bele, nyilván a beállításai (melyik/minden termék hány százalékkal, stb) + az auditálási dolgok megint.
Csík így hirtelen pongyolán ezek jutottak eszembe. A gond az, hogy elég lenne csak egy "ki mit csinált" kérdést feltenni a te szerkezetedhez, fel kellene tenned a kezed, hogy izé, az úgy volt.
. -
#1411
Sk8erPeter
nagyúr
biker
#1410
Sk8erPeter
nagyúr
Csak gyorsan futottam át, amit írtál, de sztem a legrosszabb példákat írtad, például ha van egy adott termék, aminek az alapvető jellemzői nem változnak, de a szállítói adatok bőven változhatnak (például adott hónapban valamiért más a szállítója ugyanannak a terméknek), akkor azok miért kell, hogy ugyanott szerepeljenek, ahol a termék id, név, leírás? Vagy például az akció eleje és vége hogy lehetne már ugyanabban a táblában, sőt, ugyanabban a rekordban tárolható?
Az ára, akciós ára meg aztán végképp állandóan változik... Szerinted nem épp az a feleslegesen redundáns, hogy a leírás ennyiszer szerepel a táblában? Vagy nem is értem az elgondolást.
Az a kijelentés meg, hogy az indexelések nem gyorsíthatnak jelentősen a rengeteg adatot tartalmazó táblában való keresésen, már inkább a vicces kategória szerintem. -
#1408
Peter Kiss
őstag
biker
#1407
Peter Kiss
őstag
A woocommerce sem azért lassú, mert van benne +2-3 tábla, hanem azért, mert nincs benne semmi sem optimalizálva. Szar index-ek lehetnek benne, lehet, hogy még FKEY-ek is hiányoznak, nehogy értelmesen el tudjon rajta menni az optimizer. Emellett nyilván benne van, hogy egyszerűen rosszul futtatják a lekérdezéseket benne (teszem azt termékenként és jellemzőként 1-1 lekérdezés és hasonlók).
Tervezési hiba, mert sem egy SQL szerver sem pedig a programnyelvek, technikák nem úgy vannak kitalálva, hogy ekkora adathalmazt így kezeljenek, gyakorlatilag ez azt jelenti, hogy lenne egy pl. egy sima PHP osztályod 30+ property-vel, ami fed egy sort (2*30+, ha külön getter-setter), ez nem kezelhető. Plusz olyan rugalmas így a cucc, mint az öntött vas.
-
#1406
Peter Kiss
őstag
biker
#1405
Peter Kiss
őstag
"Sima select/where felallast meg latvanyosan nem is gyorsit az index, tapasztalat"
He?
Tehát, ha 3 DATETIME oszlopra szűrök, akkor végül is tök felesleges indexelni mondjuk egy 10 millió soros táblában, mert nem lesz látványos? Vagy az előző példa nem eléggé az? 
MATCH() ... AGAINST FULLTEXT index esetén van, ez egy elég speciális cucc CHAR, VARCHAR és TEXT típusú oszlopokhoz, arról nem is beszélve, hogy 5.6 alatt nem lehet használni InnoDB táblákkal.
Plusz megjegyezném, hogy, ha van egy táblánk, ami 30+ oszloppal rendelkezik, akkor igazából egy tervezési hibával állunk szemben.
-
Jim-Y
veterán
Végül nagyjából így csináltam meg
SELECT
date,
COUNT(*) as Osszes,
COUNT(IF(valami < 72,valami,null)) as below72hours,
COUNT(IF(valami > 72,valami,null)) as above72hours
FROM TABLE
GROUP BY date;biztos nem a legszebb, de működik. Az eredeti kérdés arra irányult volna, hogy ha az above72hours-ot csak az Osszes és below72hours alapján akartam volna számolni ebben az egy queryben, akkor azt hogy kellett volna.
-
#1324
Sk8erPeter
nagyúr
biker
#1322
Sk8erPeter
nagyúr
Ahogy előttem már martonx említette:
http://dev.mysql.com/doc/refman/5.0/en/string-functions.html#function_ltrim
mysql> SELECT LTRIM(' barbar');
-> 'barbar' -
-
a régi jó hányadék MySQL 
Hiszen kiválasztottam a kolibrip_db adatbázist és azon belül is minden ki volt pipálva.
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Nem csodálom, hogy rosszul esett. 
.
Új hozzászólás Aktív témák
Hirdetés
- Renault, Dacia topik
- Házimozi belépő szinten
- AMD K6-III, és minden ami RETRO - Oldschool tuning
- Samsung Galaxy Watch (Tizen és Wear OS) ingyenes számlapok, kupon kódok
- Motoros topic
- EA Sports WRC '23
- Mibe tegyem a megtakarításaimat?
- Windows 11
- Mielőbb díjat rakatnának a görögök az olcsó csomagokra az EU-ban
- Milyen TV-t vegyek?
- További aktív témák...
- Xbox Series X, dobozában, kitisztítva+újrapasztázva, 6 hó teljeskörű gar., Bp-i üzletből eladó!
- Xbox Series X, kitisztítva+újrapasztázva, 6 hó teljeskörű garanciával., Bp-i üzletből eladó!
- Eladó Gopro Hero 10 Black edition sok tartozékkal!!
- Brutál GAMER (I7-9700K/RX 6800 Aorus/Z370-F CHIP)
- Simrig eladó PS5/PC kompatibilis. (olvass leírást.)
- REFURBISHED és ÚJ - HP USB-C/A Universal Dock G2 docking station (5TW13AA) (DisplayLink)
- BESZÁMÍTÁS! Apple Mac mini 2024 M4 16GB 256GB SSD számítógép garanciával, hibátlan működéssel
- BESZÁMÍTÁS! ASROCK H310CM i5 8400 16GB DDR4 256GB SSD 1TB HDD GTX 1060 3GB Rampage SHIVA TT 500W
- BESZÁMÍTÁS! Gigabyte A620M R5 7500F 32GB DDR5 512GB SSD RX 6700 XT 12GB ZALMAN S3 TG CM 700W
- Telefon felvásárlás!! Huawei P20 Lite/Huawei P20/Huawei P30 Lite/Huawei P30/Huawei P30 Pro
Állásajánlatok
Cég: Promenade Publishing House Kft.
Város: Budapest
Cég: PC Trade Systems Kft.
Város: Szeged