- Luck Dragon: Asszociációs játék. :)
- Carlytoo: Pánikszindróma #3
- sziku69: Szólánc.
- sziku69: Fűzzük össze a szavakat :)
- Pánikbetegség, szorongás
- Ndruu: Segíts kereshetővé tenni a PH-s arcképeket!
- gban: Ingyen kellene, de tegnapra
- sh4d0w: Netflix? Ugyan, VW előfizetés!
- D1Rect: Nagy "hülyétkapokazapróktól" topik
- f(x)=exp(x): A laposföld elmebaj: Vissza a jövőbe!
Új hozzászólás Aktív témák
-
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" message
Csak 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?
-
biker
nagyúr
Üdv, milyen szerver beállítás eredményezhet ilyen hibát? Eddig sosem láttam hasonlót
Példa: SELECT * FROM berletek WHERE aktiv!='n' ORDER BY berlet_neve ASC
és az aktiv mező NULL (üres) ha aktiv, ’n’ ha inaktív, akkor ha NULL a mező, akkor eldobja az sql-t. Ilyennel még nem találkoztam.
Explain mód: "Impossible WHERE noticed after reading const tables”
Vagyis ha a mező null, akkor lehetetlen benne where feltétellel keresni?
Próbálom a tárhelyest elérni, állítson valamit, de mit? -
martonx
veterán
válasz
mlaci01 #2194 üzenetére
Áhá, csak kezded kinyögni, hogy mi is a konkrét problémád.
Én a helyedben a következő lépéseket tenném:
1. megcsinálnám az új táblát üresen
2. írnék egy adat migráló scriptet (te tudod milyen programnyelv áll hozzád a legközelebb ehhez, akár SQL is lehet egy kurzorral), ami minden egyes soron végigmegy, az azokban talált adatokat összefűzi az új struktúrának megfelelően, majd azt beleírja az új táblába
3. a régi táblát átnevezném régitáblanév_backup-ra
4. az új táblát átnevezném a régi tábla nevére
5. amikor látom, hogy minden szép és jó, akkor elpusztítanám a backup táblát (ez időben akár heteket, hónapokat, ha nem zavar ott a backup tábla akár éveket is jelenthet).
-
mlaci01
tag
válasz
martonx #2192 üzenetére
De hogyan ?
Ezekből a meglévő rekordokból kellene:
id,reading_time,N,V,A,W
123,2022-12-17 15:58:41,1,220,1,220
124,2022-12-17 15:58:41,2,230,2,460
125,2022-12-17 15:58:41,3,230,1,230
126,2022-12-17 15:58:41,4,235,1,235
127,2022-12-17 15:58:41,5,234,1,224
128,2022-12-17 15:58:41,6,233,3,699
Ilyet készíteni:
id,reading_time,V1,V2,V3,V4,V5,V6,A1,A2,A3,A4,A5,A6,W1,W2,W3,W4,W5,W6,
1,2022-12-17 15:58:41,220,230,230,235,234,233,1,2,1,1,1,3,220,460,230,235,224,699 -
Formaster
addikt
Sziasztok! Kérnék szépen egy kis segítséget, nem tudom mit rontok el. Egy tábla text oszlopjait (A) szeretném átmásolni ugyanazon tábla másik text oszlopjába (B), de nem sikerül. Az alábbival próbálkoztam, két féle képpen is, de nem történik semmi.
UPDATE tábla SET oszlopB = oszlopA
UPDATE tábla SET oszlopB=oszlopA
szerk: megvan a hiba, lemaradt a végéről a ; -
mlaci01
tag
Sziasztok,
Át kellene alakítanom egy adatbázist, de nem tudom hogyan fogjak hozzá.
Az eredeti így néz ki:
id,reading_time,Rd,Rt,N,V,A,W
Az "id" auto increment,az "N" egy szám 1 -től 6-ig, ezeket szeretném egyesíteni az alábbiak szerint.
id,reading_time,Rd,Rt,V1,V2,V3,V4,V5,V6,A1,A2,A3,A4,A5,A6,W1,W2,W3,W4,W5,W6,
Ezek érzékelő adatok (6 db), amiknek a leolvasása minden esetben egyszerre történik, az "n" jelöli az érzékelő sorszámát.
Ezeket szeretném egyesíteni, hogy 1 leolvasásnál ne 6 db rekord jöjjön létre, hanem csak egy.
Esetleg valakinek van ötlete, hogyan lehetne az adatbázist átalakítani ?
Előre is köszönöm.
L, -
nevemfel
senior tag
válasz
laracroft #2187 üzenetére
Ha Mysql 8.0.1=< vagy MariaDB 1.2.40=<, akkor CTE-vel viszonylag egyszerű:
WITH RECURSIVE cte AS (SELECT 1 AS value UNION ALL SELECT value + 1 FROM cte WHERE value < 100)
SELECT value FROM cte LEFT JOIN naplo ON cte.value = naplo.id WHERE id IS NULLCTE nélkül, pl. 5.7-es mysql alatt nem tudom, talán tárolt eljárással.
-
laracroft
senior tag
Sziasztok
Van egy tábla, amiben van egy számokat tartalmazó oszlop.
Ide szabadon választott számok kerülnek be 1 és 100 között (szerepelhet többször is).
Azt szeretném lekérdezni, hogy - a megadott lehetőségek közül - mely számokat nem írták még be?
Ezzel a paranccsal derült ki, hogy nincs köztük 100 db szám:select count(id) from naplo where id between 1 and 100
Remélem jól fogalmaztam
előre is köszi -
meone
tag
Sziasztok!
Adott egy MySQL-es adatbázis mely perces mérési sorokat tartalmaz.
A sorok'YYYY-MM-DD hh:mm:ss'
DateTime időbélyeggel vannak ellátva.A sorokat szeretném aggregálni.
Aggregációs intervallum: 10 perc
A mért értékeket átlagolni szeretném.
A létrejött eredményt pedig elszeretném tárolni egy új adattáblában.Valakinek valami ötlete, minta példa mi alapján el indulhatok meg valósítani a dolgokat.
Segítséget előre is köszönöm.
-
disy68
aktív tag
válasz
Harcipocok84 #2182 üzenetére
-
martonx
veterán
válasz
Harcipocok84 #2180 üzenetére
Szia, ilyen string konkatenációval nem kellene értéket adnod az SQL-nek, mert ez az SQL injection melegágya.
1. Ettől eltekintve az elképzelés jó, és működhet.
2. hibát fog dobni -
Harcipocok84
tag
Sziasztok!
Nem igazán vagyok képben MySQL téren. Mondhatni kezdő vagyok, viszont egy projektemnek sajnos része a MYSQL is. Felvázolom a helyzetet:
- létrehozok egy táblát, hozzáadok 4 db mezőt.
- létrehozok egy user-t, akinek teljes jogot adok a táblához
- felépítem az adatbázis kapcsolatot:$db = new mysqli(DB_HOST, DB_USERNAME, DB_PASSWORD, DB_NAME);
Nyilván itt behelyettesítem a változókat, így az adatbázis kapcsolat megvan. Majd ezután egy külső eszközről HTTP Post utasításokat adok át a PHP-nek, és 3 db értéket adok át POST-al az alábbi linkkel:
http://weboldal.hu/data.php?vnev="Próba"&knev="Elek"&cim="fing utca 2"
A data.php pedig az alábbit tartalmazza:$sql = "INSERT INTO tabla_szemely(vnev,knev,cim,created_date)
VALUES('".$vnev."','".$knev."','".$cim."','".date("Y-m-d H:i:s")."')";
Nyilván előtte a változók értékeit kiveszem a $_GET[]-ből
A 4. értéket nem adom át, azt szeretném ha azt az SQL saját maga adná hozzá a rendszeridő szerint.
Ezzel kapcsolatban lenne pár kérdésem:
1. Ez így működik ahogy leírtam, vagy kihagytam valamit?
2. Mi történik ha valaki meghívja a linket, és HTTP post üzenetet küld de hibásan? Tehát nem olyan változónévvel, vagy nem annyi paramétert amennyire vár a PHP? -
Sziasztok, egy kérdésem lenne:
Ugye az order by záradék 'jellege miatt' ez a véletlenszerű tábla lekérdezés ismétlődés nélküli? (mondjuk 100-ból választunk véletlenszerűen 10 rekordot)
SELECT * FROM tábla WHERE valami = érték ORDER BY rand() LIMIT 10
-
laracroft
senior tag
Sziasztok
Van egy ilyen MySQL táblám.
Az id a primary key és auto increment.
Azt szeretném elérni, hogy ha új a rekord, akkor insert, ha létező, akkor update legyen.
Hogyan kéne a táblát beállítanom ahhoz, hogy a uniq_id-n belül ne fogadjon el már létező number rekordot (ekkor legyen update).
Egy ilyen paranccsal próbálkozok, de sosem update-el, mindig csak hozzáadja:INSERT INTO table (uniq_id, date, number)
VALUES(acd0e7f0f6e2e6d5968f84d8fcb307b0, date=NOW(),3)
ON DUPLICATE KEY UPDATE number = 3;
Bocsánat, ha nem jól fogalmaztam
Előre is köszi -
Agostino
addikt
sziasztok
csoportot szeretnék lekérni a következőek szerint:
+----+----------+
| id | date |
+----+----------+
| 1 | 20210701 |
| 1 | 20210801 |
| 2 | 20210601 |
| 2 | 20210401 |
| 3 | 20210801 |
| 3 | 20210501 |
| 3 | 20210501 |
+----+----------+a 20210701 lenne az érdekes dátum, tehát minden egyes olyan sort szeretnék visszakapni, ahol az id ugyan az, ez jelentené a csoport alapját, de van olyan sora, ahol szerepel a 20210701. a fenti tábla tehát a móka után a lenti tábla szerint nézne ki (vagyis a 2-es id kiesik, hiszen ott egyetlen sor mellett sem szerepel a 20210701). igazán attól izgalmas az egész, hogy select only opcióm van, te se temporary table, se update se semmi. teljesen basic lehetőségek
+----+----------+
| id | date |
+----+----------+
| 1 | 20210701 |
| 1 | 20210801 |
| 3 | 20210701 |
| 3 | 20210501 |
| 3 | 20210501 |
+----+----------+ -
Ablakos
őstag
(windows10 / Msql80)
Workbench-ben nem tudom megállítani/elindítani a servert. (Így igen: net start mysql80 )
Jó néhány okfejtést végignéztem, de nem találom a magyarázatot mit rontok el. -
martonx
veterán
válasz
Dißnäëß #2172 üzenetére
A MySql cache-e nagyon nem egyenlő egy Redis-el. Ettől még simán lehet felesleges a redis.
Nekem már önmagában az is fura, hogy ha a DB bőven belefér 10-30 gigába, akkor ehhez minek cluster?
Szóval fingom sincs, hogy mi a célotok, milyen egyéb cachelési stratégiát használtok rendszer szinten, egyáltalán mennyi request fog beesni percenként
Nem mindegy, hogy 20 vagy 2 millió. Ehhez képest a DB mérete kb. lényegtelen. -
Dißnäëß
nagyúr
Sziasztok Szakik !
MySQL (innoDB) cluster lenne a célpontja egy nagyobbacska adatbázisnak. Mennyire érdemes egy ilyen elé betenni egy Redis-t, cache-ként ? Szerintem ágyúval verébre lövés, de cáfoljatok.
Én úgy tudom, a MySQL-nek is elég fejlett a cache-ing mechanizmusa és az egyes node-ok ha komolyabb mennyiségű memóriával vannak ellátva, akkor a MySQL (cluster) ismétlődő, ugyanazon rekordokat érintő, 99%-ban READ lekérdezéseknél meglehetősen hatékonyan tud memóriából dolgozni, azaz marhagyors lenni, jól sejtem ? Túl azon, hogy a mysql router el-load-balance-olja a kéréseket a PRIMARY (R/W) és a két SECONDARY (R) között.
Csak általánosan érdeklődök, nincs a leendő DB-re vonatkozóan egyéb adatom, de az első sejtések alapján a DB mérete úgy 10-30 gigába bőven beférne.
Köszi.
-
bsh
addikt
üdv,
új kérdésem lenne, még az előbbi "projekthez". a bonyolult sok joines lekérdezés már frankón működik (és gyors is), de még kéne bele egy dolog, és ezt nem bírom megoldani.
adott egy tábla, amiben pdf fájlok helyei vannak (így gyorsabb mint fájlrendszerben keresgélni). van ebben egy RelativePath oszlop, ami ez elérési út fájlnév nélkül UNC formában, egy FileName oszlop, ami csak maga a fájlnév rész, és egy LatModified oszlop a fájl dátumával.
egy adott tétel pdf-jének a fájlneve elvileg 'rajzszám'+'revízió'+'.pdf' mintával generálható és lekérdezhető a táblából, hogy hol van a fájl.
több ugyanolyan nevű fájl is van (sajnos), különböző elérési utakon. ezekből úgy szoktam lekérdezni, hogy LastModified szerint csökkenő sorrendbe rendezve, és a legelső találat akkor a legújabb verziója a fájlnak.SELECT RelativePath, FileName, LastModified FROM pdflist WHERE FileName = 'valamiizébigyó.pdf' ORDER BY LastModified DESC LIMIT 0,1;
ezt kéne valahogy join-nal beintegrálni a nagy bonyolult lekérdezésbe. ezt így próbáltam:
LEFT JOIN (SELECT FileName, CONCAT(RelativePath, '\\', FileName) AS hely FROM `pdflist` ORDER BY LastModified DESC) pdf ON pdf.FileName = CONCAT(t.rajzszam, t.revizio, '.pdf')
ezzel az a baj, hogy így visszaadja az összes találatot, ha több ugyanolyan fájlnév is van, nem tudom hogy lehetne itt is megoldani, hogy csak egy találatot adjon vissza fájnevenként. a LIMIT nem jó. próbáltam GROUP BY FileName is...
a másik probléma hogy ez így tetű lassú. -
-
bsh
addikt
válasz
instantwater #2168 üzenetére
és az miért lesz úgy jobb?
-
Akkor viszont tényleg kell egy kapcsolótábla 2 oszloppal.
Megrendelés ID, Szállítólevél IDMajd egy unique composite index a 2 oszlopra együtt, hogy garantálja, hogy egy megrendeléshez egy szállítólevél csak egyszer szerepelhessen.
A 2 oszlopon legyen foreign key a konzisztencia miatt.
Külön-külön is tegyél rájuk egy indexet, hogy megrendelés alapján gyorsan lekérdezhesd a szállítóleveleket, és szállítólevél alapján gyorsan lekérdezhesd az adott szállítólevélen szereplő megrendeléseket.
-
bsh
addikt
válasz
instantwater #2166 üzenetére
egy szállítólevél több több rendeléshez is tartozhat, mivel egy megrendelés kb. mindig több tételből áll (azaz több sor a táblában). ezeket ahogy egy nagyobb részmennyiség kész van és kiszállítható, csomagolják és egy fuvarlevéllel szállítják ki, de sokszor van olyan, hogy tételekre várni kell, ezért ezeket később egy másik fuvarlevéllel szállítják ki, és olyan is van, hogy mondjuk egy vagy több tételből csak X mennyiség van raktáron, ezeket kiszállítják, a maradékot meg később, amikro a hiányzó mennyiség beérkezik, akkor újabb szállítóval szállítják ki.
magyarán: egy szállítólevéhez több tétel is tartozhat (ez nem probléma), és egy tételhez tartozhat több szállítólevél is (jelen esetben max. 3)
próbáltam még olyat is, hogy:
... LEFT JOIN `szallitolevelek` sz ON m.Kisz1_flev = sz.id OR m.Kisz2_flev = sz.id OR m.Kisz3_flev = sz.id
de az úgy nemjó.
végülis működik a dolog, csak nem tudom, lehet-e "szebben". -
Ok, még kapcsolótábla sem kell amennyiben egy szállítólevél csak egy rendeléshez tartozhat.
Rakj be egy megrendeles_id oszlopot a szállítólevél táblába, és tegyél rá egy foreign keyt.
Így akármennyi szállítólevél tartozhat egy megrendeléshez, és megrendeles_id alapján könnyen le tudod kérdezni őket.
-
bsh
addikt
válasz
instantwater #2164 üzenetére
SELECT (...) m.Kisz1_menny, m.Kisz1_datum, sz1.szam as Kisz1_flev, sz1.hely as Kisz1_hely, m.Kisz1_szla, m.Kisz2_menny, m.Kisz2_datum, sz2.szam as Kisz2_flev, sz2.hely as Kisz2_hely, m.Kisz2_szla, m.Kisz3_menny, m.Kisz3_datum, sz3.szam as Kisz3_flev, sz3.hely as Kisz3_hely, m.Kisz3_szla FROM `megrendelesek` m LEFT JOIN `szallitolevelek` sz1 ON m.Kisz1_flev = sz1.id LEFT JOIN `szallitolevelek` sz2 ON m.Kisz2_flev = sz2.id LEFT JOIN `szallitolevelek` sz3 ON m.Kisz3_flev = sz3.id WHERE m.id > 0;
ez csak a kérdéses rész, a többit kitöröltem. -
-
bsh
addikt
sziasztok.
lenne egy problémám, amit ugyan megoldottam, de nem biztos, hogy ez a jó/legjobb megoldás. ebben kérnék segítséget.
van egy tábla, amolyan megrendelés-áttekintő-összefoglaló akármi, aminek a lekérdezésekor több másik táblából jönnek product id-k, számlák, stb, több join is van. a probléma az ,hogy a megrendeléske kiszállításáról szállítólevelek is egy táblából jönnek. viszont előfordulhat olyan, hogy egy megrendelést több részletben szállítanak ki, ekkor több szállítólevél is tartozhat egy megrendeléshez. ezért minden megrendelés sorhoz 3 oszlop van, 3 lehetséges rész-kiszállítási szállítólevéllel. de ezek mind ugyanabból a táblából jönnek.
ezt úgy tudtam megoldani, hogy a lekérdezésben a szállítóleveles tábla háromszor is join-elve van, mindig az id oszlop, de 3 külön néven.
erre van esetleg más egyszerűbb megoldás? vagy ez így normális? -
-
Keem1
veterán
válasz
instantwater #2159 üzenetére
Feltételezem, a kérdés nem valós
De ha mégis, attól függ, dilettáns módon csinálják-e. Sajnos még mindig látok olyan elvetemült, magát programozónak nevező embert, akinek a mínusz 1 hónap az, hogy levon 30 napot az aktuális dátumból
Pedig minden normális nyelv, a MySQL-t is beleértve tökéletesen csinálja.PS C:\> (Get-Date("2021-03-31")).AddMonths(-1)
2021. február 28., vasárnap 0:00:00
PS C:\>Szökőév:
PS C:\> (Get-Date("2024-03-31")).AddMonths(-1)
2024. február 29., csütörtök 0:00:00
PS C:\>Viszont ha már amúgy is MySQL:
MariaDB [(none)]> SELECT DATE_SUB(STR_TO_DATE("2021-03-31", "%Y-%m-%d"),INTERVAL 1 MONTH);
+------------------------------------------------------------------+
| DATE_SUB(STR_TO_DATE("2021-03-31", "%Y-%m-%d"),INTERVAL 1 MONTH) |
+------------------------------------------------------------------+
| 2021-02-28 |
+------------------------------------------------------------------+
1 row in set (0.001 sec)
MariaDB [(none)]> -
-
Agostino
addikt
-
Keem1
veterán
Srácok, valószínűleg nagyon egyszerű amit akarok, csak én nem látom a fától az erdőt.
Van egy timestamp-em (tstamp), kellene nekem a mindenkori "múlt hónap".Amim már van (a
WHERE
részeként):
- ma:DATE(`tstamp`) = DATE(NOW())
- ebben a hónapban:YEAR(`tstamp`) = YEAR(NOW()) AND MONTH(`tstamp`) = MONTH(NOW())
- ebben az évben:YEAR(`tstamp`) = YEAR(NOW())
Először valami ilyesmire gondoltam (gugli):
MONTH(CURRENT_DATE - INTERVAL 1 MONTH)
De ebben az esetben nem fog kelleni (ha a mai napot nézzük, amikor is április van) a 2020-as március, csak a 2021-es március. A
YEAR(NOW()) AND MONTH(NOW()-1)
meg elvérzik januárban.Tehát a kérdésem: hogy kapom meg azokat a sorokat, ahol a
tstamp
az aktuális év előző hónapjának bármelyik napja? Annyi még, hogy a tstamp nem date, hanem timestamp, és egy napra akár több sor is lehet (2021 márciusára jelenleg 872 van összesen).Fontos: pure mysql kell, nem a host programozási nyelvben szeretném tovább filterezgetni, mivel a hívó program beágyazott kis teljesítményű hardveren fut, ami DB-related, azt végezze csak szépen a DB szerver. Ráadásul magának a programnak és a kapott DB query resultnak is robusztusnak kell lennie, éjjel-nappal futó service-ről van szó Linuxon, nem szállhat el egy hibás query miatt (pl. a fenti januári anomália). Ezért a legegyszerűbb, legegyértelműbb és legbiztonságosabb query-t kell megalkotnom, amit a futó service maga már nem igazán fog ellenőrizni.
Előre is köszi
-
coco2
őstag
Kíséri valaki figyelemmel a fejlesztési trendet? Mennyi esélye lehet annak, hogy a memory engine-t kivezetik a jövőben a mysql free verzióból?
-
Dißnäëß
nagyúr
-
Dißnäëß
nagyúr
Sziasztok, mennyire MySQL ? MariaDB-ért köveztek ?
Talán még nem nyílt nagyot az olló a kettô között.
-
-
Panhard
tag
válasz
instantwater #2146 üzenetére
ai, date, time oszlopok voltak az adatbázisban. Az ai volt az auto increment, csak a rendezés miatt kellett, más haszna nem volt. Ez a három oszlop helyett lett a datetime, a másik három majd törölve lesz.
A datetime mezőben soha nem lesz két egyforma adat. De ha mégis valamiért feltöltődne, a primary key index megakadályozza.
A datetime oszlop tartalmát a date és time oszlopokból generáltam. Csak az a baj, hogy 2018 előtt nem figyeltem arra, hogy ne töltődjön fel két egyforma adat, így most van egy pár táblázat, ahol kb: másfél millió sorból van átlagban 500 duplikált. Azokat kellen törölnöm. -
válasz
Panhard #2145 üzenetére
Kérlek használj parameter bindinget, mert így sérülékeny a rendszer SQL injectionnel szemben.
Bármi SQL beküldhető a paraméterben és némi okoskodás után csúnya dolgokat lehet művelni.Sima indexet állíts be, ne unique indexet.
Egy időbélyeget nincs értelme unique indexbe tenni, hiszen egy adott pillanatban történhetett több minden amit el akarsz tárolni, és ha unique az index akkor hibát fogsz kapni.Korábban írtad, hogy a dátum meződ a primary key.
Erre van valami ok?
Primary key általában egy auto increment mező, az user email címe, uuid vagy hasonló szokott lenni. -
Panhard
tag
válasz
instantwater #2144 üzenetére
SELECT * FROM tabla WHERE datetime between '".$_GET["datum"]." 00:00:00' and '".$_GET["datum"]." 23:59:59' ORDER BY datetime DESC
Így működik.Viszont lenne még egy kérdésem: Van pár tábla, ahol elég sok duplikált bejegyzés van a datetime oszlopban, és ezért nem engedi beállítani az indexet. Neten találtam pár megoldást a duplikált bejegyzések törlésére, de egyik sem működik. Erre tudsz valami működő megoldást?
-
-
Panhard
tag
válasz
instantwater #2140 üzenetére
"column BETWEEN dátum 00:00:00 AND dátum 23:59:59 ?"
Így működik.
Köszönöm!
-
Panhard
tag
válasz
instantwater #2140 üzenetére
"column BETWEEN dátum 00:00:00 AND dátum 23:59:59 ?"
ezt nem értem.Sajnos a tárhely szolgáltatóm nem használja a 8-as MySQL-t.
Vannak oszlopok is, amikben a dátum és idő van külön-külön, azokon az indexelés jól működik.
Gondoltam lecserélem őket egy datetime oszlopra. De akkor lehet marad ahogy van. -
-
Panhard
tag
Sziasztok. Adatbázisban van egy oszlopom, ami DATETIME formátumú, így vannak benne az adatok: "2021-02-04 20:00:00". Én ebből az oszlopból mindig csak a dátumra kérdezek le így: CAST(DATETIME AS DATE).
Hogyan lehet indexelni ezt a dátumra történő lekérdezést? Ha az egész oszlopot indexelem, úgy nem jó, mert csak a dátumra kérdezek le, így az indexelés hatástalan. -
válasz
Agostino #2137 üzenetére
Mivel egy táblában egy mezőt updatelsz, esetleg meg lehet próbálni a 2 forrástáblát összekapcsolni UNIONnal vagy JOINnal, és azt átadninaz updatenek.
Mi a baj a 2 külön updatevel?
Az a baj, hogy látni kellene a valós neveket, célokat, és okokat.
Lehet, hogy te az updatet akarod megerőszakolni, de lehet, hogy a valóságban egy másik megközelítés lenne jobb. -
Agostino
addikt
válasz
instantwater #2136 üzenetére
1064 syntax, azért kell kétszer mert - bár ezek csak kitalált táblanevek - mindkét tábla ugyan olyan adatokat tartalmaz, viszont ki kell egészítsék egymást. mert lehet, hogy az egyik táblában ugyan azon id-hez nincsen adat.
Ha nagyon minden kötél szakad 2 külön UPDATE utasításba lehetne szétszedni.
igen, ez van most -
-
Agostino
addikt
sziasztok
az egyik updatemet szeretném továbbfűzni és sejtem is, hogy mi a baja, miért nem fut le, de azért ha lehetséges és van megoldás, akkor élnék vele. a következőt kell elképzelni:
UPDATE rendeles SET
datum = CONCAT(datum,'01'),
mennyiseg = (
SELECT rendeles_mennyiseg
FROM rendelestabla1
WHERE rendeles_id1 = mrendeles_id
) WHERE mennyiseg IS NULL, /*ez tudom fölös*/mennyiseg = (
SELECT rendeles_mennyiseg
FROM rendelestabla2
WHERE rendeles_id2 = mrendeles_id
) WHERE mennyiseg IS NULL;egyetlen oszlopot kellene kétszer updatelnem de mindig csak azokat a sorokat, ahol a mennyiseg NULL, azért, hogy a már lefutott első updatet a második ne bántsa. tippre az a baja, hogy zárójelben lévő select utáni WHERE nem jön be neki. ha külön-külön lemegy a három UPDATE nincsen semmi gond, egyszerűen csak jó lenne, ha egyetlen menetben lefutna minden.
-
coco2
őstag
Sziasztok!
Használ valaki mysql ndb cluster-t mostanában? Üzemeltetési tapasztalatok / stabilitás érdekelne főleg, meg hogy a folyamatos frissítések mennyi hibával érkeznek hozzá?
Memory engine-t használok jelenleg, és a mysql doksik azt tanácsolják, érdemesebb átnézni az áttérés lehetőségeit, azért tettem fel a kérdést.
-
Hege1234
addikt
működik köszönöm
elkerülte a figyelmem
esetleg azt hogyan tudom elérni hogy be is töltse a találatokat?
mert most engedi már görgetni de pár ezret azért hosszadalmas..
(20-30 at betölt és ahogy görgetek úgy tölti be folyamatosan)kodi adatbázisáról van szó
ami most még csak a gépemen fut
de tervezem hogy routerre teszem
ott tényleg nem lenne jó egyszerre mindent betölteni
köszi a fegyelmeztetést -
sonar
addikt
válasz
Hege1234 #2130 üzenetére
Workbenchnél ott a legördülő menü, ahol lehet variálni a limiteket. De ahogy nézem ennél az ETL-nél is ott a lehetőség, jobbra fent. Szerintem ha 0-ra állitod akkor nem lesz limit a lekérdezésnél.
De azzal legyél tisztában, hogy ha nagy a tábla akkor egy fullos lekérdezés meg tudja akasztani az adatbázis szervert. -
Hege1234
addikt
Sziasztok!
a etl database browser-be megoldható valahogy a limit eltörlése vagy megnövelése?
most alapból 1000-en van
vagy a mysql workbench-nél van esetleg egyszerűbb és tudja a limit állítást? -
SunyaMacs
aktív tag
válasz
Atomantiii #2128 üzenetére
Örülök, hogy megoldódott
Régebben a logout-on volt egy kisebb fanyalgásom a témáról, lehet érdekes lesz számodra. -
SunyaMacs
aktív tag
válasz
Atomantiii #2126 üzenetére
Én a biztonság kedvéért a batch script elején a cmd kódlapját 65001-re állítanám, hogy egyezzen. A --default-character-set=utf8mb4 paramétert a #2125 hsz-ed utolsó sora szerinti kódhoz írnám a jelszó után, úgy remélhetőleg nem kéne hibát dobnia.
-
Atomantiii
addikt
Most nézem, hogy elvileg a cmd kódlapját is lehet állítani, most 852-esen (OEM - latin II)-őn van. De annak jónak kellene lennie, mert abban benne vannak a magyar karakterek.
-
Atomantiii
addikt
válasz
SunyaMacs #2124 üzenetére
Most így van benne:
SET MYSQLEXE="c:\Program Files\MySQL\MySQL Workbench 8.0 CE\mysql.exe"
SET MYSQLDUMPEXE="c:\Program Files\MySQL\MySQL Workbench 8.0 CE\mysqldump.exe"Viszont akárhogy próbálom nem akarja elfogadni, hogy lefusson hiba nélkül. Bár biztos én bénázok.
Illetve utána így mondja meg neki, hogy melyik adatbázissal és felhasználóval csinálja meg.
SET MYSQL=%MYSQLEXE% -h adatbázis név -u felhasználónév -pjelszó
-
SunyaMacs
aktív tag
válasz
Atomantiii #2123 üzenetére
Igen, oda, ahol meghívja az exe fájlt és oda utána írva paraméterként.
-
SunyaMacs
aktív tag
válasz
Atomantiii #2121 üzenetére
Az SQL queryt milyen környezetből / honnan futtatod? Pl. ha cmd-ből, akkor lehet, hogy régebbi Windowson az nem utf-8 módban van, vagy a csatlakozásnál valamilyen ok miatt nem utf8mb4 a charset az, amit a kliens használ és külön be kell állítani a
--default-character-set
paraméterrel. -
Atomantiii
addikt
válasz
Ivy.4.Ever #2120 üzenetére
Ugyanaz a helyzet MySql Workbenchben is, mint phpmyadminban. Ha sql-ként hozom létre nem jó, ha átírom utána jó lesz.
-
Ivy.4.Ever
őstag
válasz
Atomantiii #2119 üzenetére
Megnézted pl. Mysql Workbenchben?
-
Atomantiii
addikt
válasz
Atomantiii #2118 üzenetére
Kezdem feladni...
Ha sql-ből csinálok egy új táblát phpmyadminba egy már létezőbe beszútrva, akkor azt megcsinálja szépen, csak az ékezetes karakterek nem jelennek meg normálisan a komment részben az oszlop fejlécében.
Ha van egy másik táblám aminél jók phpmyadminban a komment résznél az ékezetek és úgy ahogy van átmásoltatom sql-ben egy másik táblaként, akkor ugyanúgy rosszak lesznek a komment részben a karakterek.
Ha az elrontott ékezetes betűket átírom phpmyadminban, utána szépen megjelennek az ékezetes karakterek ott is. Most már nem értem mi lehet a baja, miért nem jó ha sql-ből hozom létre.
-
Agostino
addikt
válasz
Atomantiii #2116 üzenetére
ALTER TABLE parancs nem kellene? emlékeim szerint pusztán a DB charset állítása nem húzza be TABLE-ben is a változtatást. de lehet rosszul emlékszem. megnézném azért a tábla mit csinál...
-
válasz
Atomantiii #2113 üzenetére
Nézd meg terminálban vagy valami desktop klienssel.
Ha ott jó, akkor a PHPMYADMIN karakterkódolása a rossz.
Nézd meg a HTML és HTTP headert is, mindkét helyen UTF8nak kell szerepelni. -
nevemfel
senior tag
válasz
Atomantiii #2113 üzenetére
Nem ismerem a phpmyadmin-t, de valahogy nyilván abban is be kell állítani a charsetet és a collationt is.
Ja nem, ez más. A webszervert kell beállítani, hogy a standard fejlécbe ne tegyen content-type charset beállítást is.
-
nevemfel
senior tag
válasz
Atomantiii #2111 üzenetére
Az összes utf8mb4 kezdetű sorrendezés az utf8mb4 karakterkiosztáshoz tartozik. A te esetedben ez:
DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_general_ci
Egyébként ahogy olvasom, a
utf8mb4_general_ci
heylett jobb azutf8mb4_unicode_ci
-
Atomantiii
addikt
válasz
Ivy.4.Ever #2110 üzenetére
Köszi, sajnos nem szereti. Beírtam így:
DEFAULT CHARSET=utf8 COLLATE=utf8mb4_general_ci-ként beírtam, azt mondja rá, hogy COLLATION 'utf8mb4_general_ci' is not valid for CHARACTER SET 'utf8'
Van amit elfogad, de azok meg nem ismerik ugyanúgy a magyar karaktereket.
-
Ivy.4.Ever
őstag
válasz
Atomantiii #2109 üzenetére
Nekem sima utf8-at nem ismer a MariaDB. Vagy használd a COLLATE szót is. Ilyen van hogy utf8mb4_general_ci pl azon belül. Egyébként az mb4-eseket ajánlott használni ha már utf8. Gyakori probléma forrás.
-
Atomantiii
addikt
Arra van ötlete valakinek, hogyan lehetne megoldani ékezetes problémát phpmyadminban a komment résznél?
Tehát sql-ben meg van írva a tábla szerkezete
CREATE TABLE IF NOT EXISTS `valami`.`valami` (
`oszlop1` int(10) unsigned NOT NULL AUTO_INCREMENT COMMENT 'ID',
`oszlop2` varchar(40) NOT NULL COMMENT 'Név',
stb
CURRENT_TIMESTAMP COMMENT 'Módosítás időpontja',
PRIMARY KEY (`oszlop1`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8 AUTO_INCREMENT=35 ;Ha megnézem az adott táblát phpmyadmin alatt, akkor az ékezetes karakterek helyett más jelenik meg a komment sorban, pedig phpmyadminban a kiszolgáló karakterkódolása: UTF-8 Unicode (utf8)-ra van állítva.
-
Panhard
tag
Sziasztok! Adatbázisban szeretnék utólag legenerálni egy új oszlopba, soronként unixtime-ot, meglévő dátum és idő mezőkből.
Addig megvan a kód, hogy fix dátum, idő értékből megcsinálja, de hogy tudom a dátum és idő helyére beírni a dátum és idő mezők értékeit?UPDATE database SET timestamp = UNIX_TIMESTAMP('2020-09-19 16:00:00') where sorszam < 100
-
JohnD
tag
válasz
Ivy.4.Ever #2104 üzenetére
Jó, azóta meglett már, köszi!
-
mlaci01
tag
Sziasztok,
Hátha tud valaki segíteni.
Van két táblám:
T1: T1m1,T1m2,T1m3,T1m4,T1m5,T1m6,T1m7,T1m8
T2: T2m1,T2m7,T2m8
INSERT csak a T1 táblára van annak mikéntjére nincs ráhatásom.
Szeretném INSERT-kor ha a (T1m7+T1m8) megtalálható a (T2m7+T2m8)-ban,
akkor a T2m1 mező értéke automatikusan beíródna a T1m6-ba.
Remélem érthetően fogalmaztam.
Előre is köszönöm a segítséget.
L, -
JohnD
tag
Helló! Wampserver 3.2.0-t használva a következő probléma adódik: php-ből mysql parancsokkal csatlakoznék a mysql szerverhez, de a mariadb-hez csatlakozik, a phpmyadminban a mariadb alatt létrehozott adatbázishoz csatlakozik, az az alatti táblát tudom csak lekérdezni. Mi lehet a gond? Vmi konfigurációs probléma szerintem. Köszi a segítséget!
Új hozzászólás Aktív témák
Hirdetés
- macOS PC-re
- Luck Dragon: Asszociációs játék. :)
- Samsung Galaxy Felhasználók OFF topicja
- Carlytoo: Pánikszindróma #3
- Autós topik látogatók beszélgetős, offolós topikja
- sziku69: Szólánc.
- Kerékpárosok, bringások ide!
- sziku69: Fűzzük össze a szavakat :)
- Bemutatkozott a Poco X7 és X7 Pro
- TCL LCD és LED TV-k
- További aktív témák...
- Eladó Xiaomi Mi Air Purifier 3C okos légtisztító ár alatt
- Kingston FURY Renegade KF426C15RBK2/64 (128GB KIT)
- Újszerű Samsung Galaxy Tab S8 5G (128GB) 1 ÉV Garancia!
- Csere-Beszámítás! Garancia! Steam Deck OLED 1TB Kézikonzol!
- Csere-Beszámítás! Garancia! Steam Deck LCD 512GB + 256GB Ajándék Micro SD Kártya!
- ÁRGARANCIA!Épített KomPhone i9 14900KF 32/64GB RAM RTX 5070 Ti 16GB GAMER PC termékbeszámítással
- BESZÁMÍTÁS! Gigabyte Aorus B450 R7 5700X 16GB DDR4 512GB SSD RTX 3060Ti 8GB ZALMAN I3 NEO 650W
- Dell Precision 5540 i7-9850H 16GB 256GB 15.6" FHD Nvidia Quadro T1000 15.6" FHD 1 év garancia
- ÁRGARANCIA!Épített KomPhone Ryzen 5 4500 16/32/64GB RAM RTX 3050 6GB GAMER PC termékbeszámítással
- BESZÁMÍTÁS! 3TB Western Digital WD RED SATA HDD meghajtó garanciával hibátlan működéssel
Állásajánlatok
Cég: FOTC
Város: Budapest