- AMD Ryzen 9 / 7 / 5 / 3 5***(X) "Zen 3" (AM4)
- Samsung QN800D: Neo QLED 8K tévét teszteltünk
- 1000 Hz-es játékos monitor TCL CSOT recept szerint
- Vezeték nélküli fejhallgatók
- Milyen billentyűzetet vegyek?
- Melyik tápegységet vegyem?
- Azonnali processzoros kérdések órája
- Két projektorral bővül az Acer Vero család
- Megérkezett Magyarországra az LG 480 Hz-es OLED monitora
- Gaming notebook topik
Hirdetés
-
AMD Radeon undervolt/overclock
lo Minden egy hideg, téli estén kezdődött, mikor rájöttem, hogy már kicsit kevés az RTX2060...
-
Frissült az IQOO tabletkínálata
ma Az új IQOO Pad2-t és Pad2 Pro-t egyelőre nem láttuk más brand kínálatában, persze ettől még felbukkanhatnak majd Oppo vagy OnePlus címszó alatt.
-
Már tudjuk, hogy mikor jön pontosan az idei Ubisoft Forward
gp Idén is számos friss bejelentésre számíthatunk a cégtől.
Új hozzászólás Aktív témák
-
DNReNTi
őstag
válasz Brett001 #2700 üzenetére
Ne használd a lekérdezésben a WHERE-t, hanem engedd rá az egész táblára. Persze ne konstans adattal, hanem az épp aktuális mező tartalmával, valahogy így:
UPDATE table SET datetime = UNIX_TIMESTAMP(datetime);Nem tudom most kipróbálni, de így mennie kéne.
Ha 1175-ös hibát dob, akkor ki kell kapcsolni a safe mode-ot:
SET SQL_SAFE_UPDATES = 0;Azért egy biztonsági mentést csinálj a tábláról.
but without you, my life is incomplete, my days are absolutely gray
-
Brett001
aktív tag
válasz DNReNTi #2701 üzenetére
Hali! Kösz a gyors választ.
1175-öt nem, jó lett köszi!
Ja,mellesleg gondoltam én a WHERE elhagyására (hisz nem kell feltételt szabnunk, hasonlóval próbálkoztam, (el is hagytam) csak unix_timestamp()-t írtam, hisz tudtam, hogy nem kell konkrét érték. Ez igy persze, hogy ne volt jó.
[ Szerkesztve ]
"Felkészültség és fegyelem a sorsunk urává tesz." Farell főtörzsőrmester
-
#68216320
törölt tag
Honnét lehet beszerezni magyar településlistát, megjelölve, hogy melyik megyéhez tartozik?
MySQL-ben kell majd használnom. -
-
#68216320
törölt tag
válasz martonx #2706 üzenetére
Ingyen szeretném, mivel non-profit dologba menne. Arra gondoltam, hogy a wikipedia oldalaiból összerakom a listát. Ispy által linkelt oldalon pedig van egy régebbi lista, amit összehasonlítok a wiki-féle listával. Aztán egyezés esetén a régebbi listából átteszem a gps koordinátákat. A többi eltérésnek pedig utánanézek.
-
DNReNTi
őstag
válasz #68216320 #2711 üzenetére
Fent van XLS-ben a 2014-es lista. Onnan már csak 1 lépés a csv, és az import adatbázisba. Még nekem is jól jöhet.
but without you, my life is incomplete, my days are absolutely gray
-
rum-cajsz
őstag
válasz #68216320 #2713 üzenetére
Openstreetmap-en nagyon sok geolokációs adat lekérdezhető, ez is. Csak azért nem ezt javasoltam elsőre, mert ennek a minősége nem feltétlenül 100%-os. A KSV listája az.
Itt egy hasonló lekérdezés a magyar településekre, GPS koordinátákkal: http://overpass-turbo.eu/s/6tr
Az adatok kinyerése:
EXPORT -> "raw data directly from Overpass API"Az eredmény egy tab szeparált csv lesz, adatai: id, hosszúság, szélesség,név, KSHkód, besorolás, irányítószám, kistérség
Sajnos ebben a településrészek is benne vannak, így az adattisztítást nem úszod meg. Itt megnézheted az OSM cimkéket, amik a településekre vonatkoznak, így a lekérdezést módosíthatod is: [link]
=Kilroy was here============================ooO=*(_)*=Ooo=======
-
Louro
őstag
Sziasztok!
Van arra lehetőség, hogy egy-egy találatot átnevezzek. Pl:
select * from somewhere
where 1=1
and 1st_IDX = case 1st_IDX when '1' then 'A' when '2' then 'B' when '3' then 'C' endNagyvonalakban ez lenne a kód. De sajnos inkább meg sem jeleníti a találatok ahol a 1st_IDX 1,2 vagy 3. (A példánál maradva.)
Segítségeket előre is köszönm!
Mess with the best / Die like the rest
-
rum-cajsz
őstag
Én szívesen segítenék, de nem értem a kérdésed sem. Tudnál készíteni egy példát az sqlfidle oldalon?
Már azt sem értem, ha ugyanazt a mezőt akarod ugyanazzal a mezővel összehasonlítani, és csak az egyik oldalon konvertálsz, akkor mit vársz? Ha konkrét értékeid vannak, akkor miért nem jó az egyenlőség helyett az IN () ?
=Kilroy was here============================ooO=*(_)*=Ooo=======
-
Ispy
veterán
MS SQL-ben:
SELECT CASE Mezo
WHEN 1 THEN 'A'
WHEN 2 THEN 'B'
WHEN 3 THEN 'C'
ELSE 'D'
END
FROM tabla
vagy
SELECT CASE
WHEN Mezo = 1 THEN 'A'
WHEN Mezo = 2 THEN 'B'
WHEN Mezo = 3 THEN 'C'
ELSE 'D'
END
FROM tablaA 2. opcióban a WHEN részben tudsz OR vagy AND operátorral összetett feltételt is létrehozni.
[ Szerkesztve ]
"Debugging is like being the detective in a crime movie where you're also the murderer."
-
Louro
őstag
válasz rum-cajsz #2722 üzenetére
Szia,
decode-dal még nem néztem, de jó ötlet. Oracle az alap, de valamiért case esetén kiesnek az érintett sorok.
Decode-dal is megnéztem és úgyis csak kiejtette a találatokat.
A kód:
select id,name from somewhere
where 1=1
and decode (id, '1','A',
'2','B',
'3','C',
id) = idNem vagyok öregmotoros. Igyekszek a kérdéseim előtt azért utánanézni, szóval, ha kihagytam egy vesszőt, nem haragszok meg a segítségért
Mess with the best / Die like the rest
-
bambano
titán
postgresql. szerintetek jogosultság mátrixot miben érdemes tárolni?
sok egyedhez kellene letárolnom, hogy 64 jog közül melyik jár neki. ezt lerakhatnám mondjuk 4 darab 16 bites integerben, vagy bitstringként.kösz minden tippet.
Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
Khelben
nagyúr
Sziasztok! Roppant egyszerű a feladat, de egyelőre nem találtam rá a neten megnyugtató megoldást:
Van egy SQL Server 2008-as adatbázis. Bizonyos táblák bizonyos sorait rendszeresen ki kell törölni úgy, hogy semmilyen módszerrel ne lehessen visszaállítani. Ötlet? -
Khelben
nagyúr
válasz rum-cajsz #2729 üzenetére
Van időm rá, nem az a gond, hanem a visszahozhatatlanság. Tehát el kell tüntetni őket fizikailag a táblából, a logokból, esetleg magáról a hdd-ről is. Ha átadják a hdd-t egy sql gurunak, ő se tudja visszahozni.
(#2730) martonx : sajnos nem ilyen egyszerű, a delete csak töröltre állítja a sorokat, nem törli ki őket. De még ha törölné is, a logból bármikor vissza lehet őket állítani.
[ Szerkesztve ]
-
Ispy
veterán
válasz Khelben #2731 üzenetére
Hát ez túl paranoidnak tűnik így elsőre
A HDD-ről is visszalehet hozni az adatokat formázás után is (legalább is részben), szóval nem tudom SQL szinten van-e erre lehetőség, ha más nem a mágnes segít
"Debugging is like being the detective in a crime movie where you're also the murderer."
-
Khelben
nagyúr
Két és fél megoldást találtam eddig, egyikben backupolni kell az adatbázist, ekkor resetelődnek a logok, utána shrinkkel ki lehet ütni a logok helyét vagy lefuttatni pár nagyméretű tranzakciót, ami feltölti a törölt logokat új adatokkal. Itt az a gond, hogy hova backupolok, amit utána el lehet tüntetni. Ramdrive-ra gondoltam pl. első körben.
Második megoldás egy titkosítás, amikor a törölt rekordokat tartalmazó táblát letitkosítom egy új kulccsal és a régi kulcsot eldobom. Ekkor a törölt rekordokat még vissza lehet állítani, de a tartalmuk nem látható a régi kulcs nélkül.
A félmegoldás, hogy ráteszem a gépet egy ups-re és mindent ramban tartok. Nap végén meg lementem adatbázisba azt, ami kell, a többi meg a gép kikapcsolásával megy a levesbe. Itt ugye az a gond, hogy ha lefagy valami, akkor is megy minden a levesbe, az is, aminek nem kéne.Na ezeknél kerestem volna egyszerűbb megoldást, de nem találok.
-
Sk8erPeter
nagyúr
válasz Khelben #2733 üzenetére
"Második megoldás egy titkosítás, amikor a törölt rekordokat tartalmazó táblát letitkosítom egy új kulccsal és a régi kulcsot eldobom. Ekkor a törölt rekordokat még vissza lehet állítani, de a tartalmuk nem látható a régi kulcs nélkül."
Számomra még ez tűnik a legésszerűbbnek a felsorolt lehetőségek közül, tehát hogy hiába tudja valaki visszaállítani extrém esetben a rekordot, a tartalmával nem igazán tud mit kezdeni. A többi megközelítés túl macerás vagy túl kockázatos.Sk8erPeter
-
Khelben
nagyúr
válasz Sk8erPeter #2734 üzenetére
Kérdés, hogy a törölt kulcsot vissza lehet-e valahogy állítani
-
bambano
titán
válasz Khelben #2731 üzenetére
a törlendő rekordokat helyben felülírod azonos hosszúságú szeméttel, majd letörlöd.
utána megkeresed a kottában, hogy amit a postgresql vacuumnak hív, az nálad hogy megy.ha attól félsz, hogy a diszken is megmarad a tartalma, akkor valamilyen karbantartási időszakban állítsd le az adatbáziskezelőt és azon a partíción, ahol az adatbáziskezelő fájljai vannak, nyiss egy fájlt, amit addig írsz nullával, amíg el nem fogy a hely, utána töröld le és indítsd újra az adatbáziskezelőt.
Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
Khelben
nagyúr
válasz fordfairlane #2738 üzenetére
Ezzel csak az a gond, hogy a tranzakciós napló alapján még ez után is vissza lehet állítani, tehát arra is ki kell találni valamit
(#2737) martonx : nem én találtam ki, ez a megrendelő igénye. Van pár olyan adat, ami csak bizonyos ideig élhet a rendszerben és utána nem lehet reprodukálható. Sajnos nem egész adatbázisról van szó, mert akkor egyszerűbb lenne a dolog, hanem csak egy tábla bizonyos sorairól.
[ Szerkesztve ]
-
bambano
titán
válasz Khelben #2739 üzenetére
azt nem tudod megoldani, hogy az adatokat lejáratuk szerint külön táblába rakod, és egy union select-tel kérdezed le, majd amikor lejárt a megőrzési határidő, elhajítod a táblát? (a fizikai helyét meg törlöd).
vagy akár ilyen parasztos megoldás, hogy csinálsz annyi partíciót, amennyi ideig meg kell őrizni, pl. 12 hónap esetén 12 darab egyhavit, és azokat betolod tablespace-nek a db program alá? linuxon biztos ezt csinálnám, de azt sejtem, te nem linuxozol ha lejárt, legyalulod.
Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
-
Khelben
nagyúr
válasz Peter Kiss #2741 üzenetére
Nekem is ez jutott eszembe, de egy napig meg kell őrizni és ha valami van, lefagy a gép vagy a program, akkor elveszik az is, aminek nem kellene.
(#2740) bambano : ez sem rossz, de mivel olyan helyen fog futni, ahova nem mehetek minden nap karbantartani, ezért valami programozott megoldás lenne ideális.
[ Szerkesztve ]
-
fordfairlane
veterán
válasz Khelben #2739 üzenetére
A tranzakciólog tartalma függ a beállított recovery mode-tól, a simple esetén a logból a lezárult tranzakciók eltűnnek. A fizikai törlés a log esetén a shrink művelet. A recovcery mode az egész adatbázisra vonatkozik, és kihatással van az egész backup folyamatra, ezért ha csak egy bizonyos táblánál vannak ilyen kritériumok, akkor azt érdemes egy külön adatbázisba tenni. Pluszban még meg lehet fejelni az egészet egy titkosítással.
x gon' give it to ya
-
fordfairlane
veterán
válasz fordfairlane #2743 üzenetére
a simple esetén a logból a lezárult tranzakciók eltűnnek.
Ez egyébként sajnos nem ilyen egyszerű, de egy manuális checkpoint indítással úgy tűnik, megoldható. Sajnos ez már az a mélysége az MS SQL adminisztrációjának, amit sajnos nem ismerek eléggé.
x gon' give it to ya
-
dellfanboy
őstag
van 3 oszlopom
dátum id faktor faktor felvehet 3 értéket 1,0,-1, 1 hónap alatt 1 id-nak a faktorja többször változhat
azon id-kra vagyok kiváncsi ahol a faktor értéke -1 1 adott periódusbanidáig úgy próbáltam megoldani, hogy az id-t group by-oltam a factort pedig sum-áztam de nem lett jó eredményem... van valami ötletetek?
eladó dolgok:mondd az árát és vidd http://hardverapro.hu/tag/dellfanboy#aprohirdetesei
-
martonx
veterán
-
Khelben
nagyúr
válasz dellfanboy #2745 üzenetére
select distinct id
from tábla
where faktor=-1
and dátum between perióduskezdete and periódusvége -
bambano
titán
egy táblában (postgresql) lakcímek vannak. a normalizálás során az utcanév kikerült egy másik táblába, egy azonosító mező maradt meg. A lakcím táblát sorba kellene rendezni házszám szerint.
A nehezítés, hogy a házszám string, mivel van szám, szám per betű, számtólszámig és több más forma is.
minden ötletet megköszönök. releváns részlet:
id | street_id | number
------+-----------+------------
1 | 23 | 4/a
2 | 23 | 5/a
3 | 23 | 14
4 | 23 | 16
5 | 23 | 11
6 | 23 | 11/a
7 | 23 | 20
8 | 23 | 13
9 | 23 | 13/b
10 | 23 | 20/a
18 | 23 | 38
19 | 23 | 21
20 | 36 | 119
21 | 36 | 117/b
22 | 36 | 117/a
23 | 36 | 115
24 | 46 | 16
25 | 23 | 18
26 | 42 | 11[ Szerkesztve ]
Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
Sk8erPeter
nagyúr
válasz bambano #2748 üzenetére
Biztos sok hibalehetőséget rejt magában, amit most nem volt alkalmam normálisan tesztelni, és most gyorsan csak MySQL-lel teszteltem, de ilyen castolás nem jó?
tesztként query (itt implicit castolással):
mysql> SELECT * FROM `mytable` ORDER BY (`number` * 1) ASC, `number` ASC;
+----+-----------+--------+
| id | street_id | number |
+----+-----------+--------+
| 1 | 23 | 4/a |
| 2 | 23 | 5/a |
| 26 | 42 | 11 |
| 5 | 23 | 11 |
| 6 | 23 | 11/a |
| 8 | 23 | 13 |
| 9 | 23 | 13/b |
| 3 | 23 | 14 |
| 4 | 23 | 16 |
| 24 | 46 | 16 |
| 25 | 23 | 18 |
| 7 | 23 | 20 |
| 10 | 23 | 20/a |
| 19 | 23 | 21 |
| 18 | 23 | 38 |
| 23 | 36 | 115 |
| 22 | 36 | 117/a |
| 21 | 36 | 117/b |
| 20 | 36 | 119 |
+----+-----------+--------+
19 rows in set (0.00 sec)Sk8erPeter
-
bambano
titán
válasz Sk8erPeter #2749 üzenetére
úgy látom, pgsqlnek nem jó:
ERROR: invalid input syntax for integer: " 51/g"Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
Új hozzászólás Aktív témák
- Nők, nőügyek (18+)
- Debrecen és környéke adok-veszek-beszélgetek
- Kerékpárosok, bringások ide!
- Xbox Series X|S
- Mobil flották
- Samsung Galaxy S23 Ultra - non plus ultra
- Viber: ingyen telefonálás a mobilodon
- Napokon belül indul a testkamerás Bodycam című FPS korai kiadása PC-n
- Xbox tulajok OFF topicja
- Steam topic
- További aktív témák...
- Apple watch Series 9 45mm Apple garancia + 2028-ig biztosítás!!!
- Dell Precision 5570 ( XPS 9520 ) 15.6" FHD+/i7-12700H 14mag/16-32G/512G/Quadro A1000/IR/FPR
- Dell Precision 3571 15.6" FHD IPS i7-12800H T600 32GB DDR5 1TB NVMe SSD gar
- Latitude 5540 15.6" FHD IPS i7-1370P MX550 32GB DDR5 512GB NVMe SSD gar
- Eladó iPhone 13 Mini 128 GB Blue 100% aksi szép állapotú - 12 HÓ GARANCIA - S1324
Állásajánlatok
Cég: Alpha Laptopszerviz Kft.
Város: Pécs
Cég: Ozeki Kft.
Város: Debrecen