Ú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
-
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
-
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 ]
-
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
senior tag
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 -
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
-
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
- Vivaldi (böngésző)
- Elektromos rásegítésű kerékpárok
- Projektor topic
- Kerékpárosok, bringások ide!
- ZIDOO médialejátszók
- Elektromos autók - motorok
- Eredeti játékok OFF topik
- E-roller topik
- Miniképernyős, VIA-s Epomaker billentyűzet jött a kábelmentes szegmensbe
- Autós topik látogatók beszélgetős, offolós topikja
- További aktív témák...
- Amazfit I T-REX 2 I GTS 3 I GTR 3 I GTR 3 Pro
- Új Latitude 7440 2-in-1, FHD+ IPS kihajtható érintő, i7-1365U, 32GB DDR5, 512GB NVMe, IR kamera, gar
- Beszámítás! GB H610M i5 13400F 32GB DDR4 1TB SSD RTX 3070Ti 8GB MONTECH AIR 1000 Lite Corsair 650W
- Xiaomi Instant Photo Printer 1S Set Bontatlan!
- Beszámítás! GB H610M i5 13400F 16GB DDR4 250GB SSD RTX 3070Ti 8GB MONTECH AIR 100 Lite Chieftec 700W