Hirdetés
- gban: Ingyen kellene, de tegnapra
- juhi11: Karácsony esély, hogy észrevegyük: mások is valakik - még Isten is
- sziku69: Szólánc.
- sziku69: Fűzzük össze a szavakat :)
- Luck Dragon: Asszociációs játék. :)
- Magga: PLEX: multimédia az egész lakásban
- btz: Internet fejlesztés országosan!
- Toomy: FOXPOST: régen jó volt, de már jobban jársz, ha elfelejted
- MasterDeeJay: Nvidia Geforce PCX5300 bemutató
- GoodSpeed: Munkaügyi helyzet Hajdú-Biharban: észak és dél
Új hozzászólás Aktív témák
-
#2799
rum-cajsz
őstag
sityupityka
#2798
rum-cajsz
őstag
válasz
sityupityka
#2798
üzenetére
negyvenkettő
-
#2798
sityupityka
újonc
sityupityka
újonc
Az első 8 feladat megoldása érdekelne....Bárki aki segít annak nagyon hálás lennék
-
pityaa23
senior tag
Köszönöm a válaszokat!
Közben azon gondolkoztam, hogy lehet nem is kell étkezés tábla. Ha beleteszem a kiválasztott táblába az étkezés oszlopot, akkor ott a bevitelnél majd megjelölöm melyik étkezéshez tartozik a kiválasztott alapanyag.
Azt nem tudom, hogy ha még az étrend_ID -t is tárolnám ebbe a táblába akkor igaz hogy csúnyábban nézne ki, de nem kéne az étrend és a kiválasztott kapcsolattábla, ha jól gondolom. Így mondjuk: [link] -
Ispy
nagyúr
-
pityaa23
senior tag
Sziasztok!
Lehet amatőr kérdés, ne egyetek meg miatta.
Most volt időm megint elővenni az étrendtervezős táblát, amit már múltkor tárgyaltunk, de nem értem pontosan, hogy kéne felépíteni. Megpróbálom elmagyarázni a problémám. :
Itt van két kép, hogy könnyebben megértessem magam:(Mielőtt megint leharapjátok a fejem, ez csak vázlat, nem magyar lesz a végeredmény.
)A tervezendő étrenden belül 8 étkezés lesz, de nem kötelező mind a 8-at kihasználni. Minden étkezés 5 alapanyagból állhat, aminek a mennyiségét is meg kell adni. Majd a végén kiszámolja nekünk a kalória, fehérje, stb... tartalmát étkezésenként és az egész étrendét is. Ezt el is lehet menteni majd.
Hogy lenne érdemes megoldani az étkezések táblát, táblákat, hogy alkalmas legyen mentésre és tudjam, hogy melyik user, melyik étrendjéhez, melyik étkezéséhez, melyik kiválasztott alapanyag tartozik?
(Van külön tábla az alapanyagoknak, és a kategóriáknak.)
Köszönöm előre is!
-
Ispy
nagyúr
válasz
Diopapa
#2788
üzenetére
select station_list.station_id , MAX(bfmarketdata.timestamp) from distances
inner join station_list on second_system_id = station_list.system_id
inner join bfmarketdata on bfmarketdata.station_id = station_list.station_id
where first_system_id = '1916' and commodity_id = '85' and distance <= 30
group by station_list.station_id
order by distance -
Diopapa
addikt
Üdv!
Kis segítséget szeretnék kérni. Van néhány táblám. A struktúra azon része ami most kell:
station_list tábla, station_id, system_id mezők
bfmarketdata tábla, timestamp, commodity_id, station_id mezők
distances tábla, first_system_id, second_system_id, distance mezőkA lekérdezésem:
select station_list.station_id , bfmarketdata.timestamp from distances
inner join station_list on second_system_id = station_list.system_id
inner join bfmarketdata on bfmarketdata.station_id = station_list.station_id
where first_system_id = '1916' and commodity_id = '85' and distance <= 30
order by distanceezt az eredményt kapom:
"station_id" "timestamp"
"236" "20150311170757"
"202" "20141223163432"
"209" "20150115195106"
"208" "20141225112250"
"202" "20141225114051"
"202" "20141222111219"
"209" "20141225121332"
"225" "20150115190005"
"205" "20141223194642"
"201" "20141226164121"
"201" "20150114165111"
"201" "20141221175132"
"194" "20141220224501"
"194" "20141223161651"Azt szeretném elérni, hogy egy station_id egyszer szerepeljen. Az, amelyikhez a legújabb timestamp tartozik. Plz help!
-
pityaa23
senior tag
válasz
martonx
#2783
üzenetére
Köszi a tanácsokat,
1. valóban, ez nem végleges, csak gyorsan összedobtam valamit.
2. nem gondolom, hogy kell, itt gyúrós étkezések lesznek, kb csirkemell, rizs, salátából áll egy étkezés, nincs előétel, főétel, desszert. Nem kész ételek, hanem alapanyagok.
3. 100g ban lévő tápanyagokat mutatná a táblázat, pl 100g csirkemell: 109 kalória, 25g fehérje, 1g zsír, 0g szénhidrát.
bambano: az időpont sem lényeges, a user eldönti egy nap hány étkezést akar, annyit állít össze. Majd elosztja magának a nap folyamán.
-
martonx
veterán
válasz
pityaa23
#2782
üzenetére
Első ránézésre már nem vészes.
Pár észrevétel:
1. a táblád nevei nagyon bénák. Alapanyag, meg alapanyagok? Eleve mindent angolul nevezünk el, a kapcsolat táblákat pedig valahogy úgy illik elnevezni, hogy a nevéből is látszódjon, hogy mit kapcsol össze mivel.
2. Az étkezést tovább bontanám ételekre, mert egy ebéd pl. jó eséllyel áll levesből és főételből.
3. hiányolom a mennyiségi egységet az alapanyagokból. Nem mindegy, hogy 1 liter, vagy 1 kg. -
DNReNTi
őstag
válasz
lakisoft
#2778
üzenetére
"Tudnátok segíteni a logikai felépítésben?"
Szerintem ehhez nem kell kód. Gondolom inkább arra kíváncsi ki hogyan építené fel a táblákat, kapcsolatokat, hogy az jó legyen.
És ha már itt tartunk leírom én is:
Mindenképpen kell felhasználók és alapanyagok tábla ugye. Kell egy étrendek kapcsolattábla, ez fogja tárolni melyik felhasználónak mely étrendjei vannak. Ezt követi az étkezések kapcsolattábla ami azt mondja meg mely étrendek milyen étkezéseket tartalmaznak. Végül jön az alapanyag kapcsolattábla, ami összeköti az alapanyagokat az étrendekkel. Hát így nagyon leegyszerűsítve valahogy így. -
pityaa23
senior tag
Sziasztok!
Van egy kis adatbázis tervezési gondom. Étrend tervezőt szeretnék készíteni. Ami kb így kéne felépüljön:
1 user bármennyi étrendet készíthet, 1 étrend maximum 8 étkezésből állhat, egy étkezést 5 alapanyagból lehet összeállítani és az alapanyagok mennyiségét is meg kell adni.
valahogy így kell elképzelnipróbáltam már valahogy összeállítani, nem nagy sikerrel:
[link]El is kéne tudni majd menteni az étrendet. Tudnátok segíteni a logikai felépítésben?
Köszönöm előre is!
-
bpx
őstag
Egy megoldás már le lett írva, így csak a hibára reagálnék. Azért nem ad eredményt, mert pl. annak, hogy WHERE ROWNUM = 2, nincs értelme, soha nem fog eredményt adni. A ROWNUM eredményhalmazra vonatkozik, és nem táblára. A ROWNUM értéke folyamatosan növekszik az eredményhalmaz sorainak számával együtt. A ROWNUM = 1 azért működik, mert az első sorra teljesül, hogy az az első sor. A ROWNUM = 2 azért nem ad eredményt, mert az első sorra nem teljesül, hogy az a második sor, így nem kerül be az eredményhalmazba, és a ROWNUM értéke sem fog növekedni, így nem lesz eredmény sem.
Na, lassú voltam.
-
Ablakos
addikt
Igen a rownum ilyen sajátosan működik. Egytől indul, egyesével növekszik. A where-ben kiértékeli a pszeudo értéket, ami először 1. Mivel a feltétel teljesült (=1) lefut, jön a következő ciklus. Következő for ciklusban megint kiértékeli és megint csak 1-el indul a rownum, de a feltétel nem teljesül (i = 2). Ekkor null value akaródzik a változóba menni, és ennek a jutalma no data found kivétel.
-
rum-cajsz
őstag
Azt most nm pont értem, hogy miért nem ad vissza sort a te példád, viszont ha visszaadna, akkor sem biztos, hogy azt kapnád, amit szeretnél, mivel a lekérdezés eredménye order by nélkül nem feltétlenül ugyanazt a sorrendet adja vissza egymás után kétszer.
Az első 3 sort így tudod szűrni:
begin
for i in (
select * INTO emp_adatok from emp where ROWNUM<4
) loop
dbms_output.put_line(i.ename);
end loop;
end; -
44kos
csendes tag
Sziasztok!
Pár hete kezdtem el PL/SQL-es foglalkozni, és akadt egy kérdésem:
Hogy lehet azt megvalósítani, hogy egy tábla első három sorát dolgozzam csak fel?
Például van egy 14 soros tábla, aminek van többek közt egy név és egy fizetésmezője, és én az első 3 sorban lévő adatokat szeretném egy általam definiált rekordba eltárolni és kiírni.Ezt a kódot írtam rá:
declare
emp_adatok emp%ROWTYPE;
begin
for i in 1..3
loop
select * INTO emp_adatok from emp
where ROWNUM=i;dbms_output.put_line(emp_adatok.ename);
end loop;
end;no data found hibaüzenetet ad, pedig a táblának van pontosan 14 sora.
Mit javítsak rajta?
-
pakriksz
őstag
Hello
Van egy táblám: ip(varchar), userid(varchar), downloads(int)Ebbe ugye ip címek, user azonosítóknak kéne kerülni, és ahányszor ez az ip userid páros hívja meg a scriptet annyiszor emelkednie a downloadsnak. Na most az a gond, hogy egy ip-hez több userid is tartozhat, de egy userid-hez több ip.
Szóval ha a páros különbözik, akkor nem a downloadsot kéne emelni, hanem új rekord.Ez a lekérdezés hozzá: INSERT INTO stats (ip, userid, downloads) VALUES ('$userip','$user',1)
ON DUPLICATE KEY UPDATE downloads = downloads + 1"
Csakhogy ez így nem jó. Van valami módszer arra hogy csak akkor vegye duplicatenek, ha a userid és az ip egyezik? -
amargo
addikt
Ha a program úgy lett meg írva, hogy csak egy db-hez csatlakozzon, hogy tudna kettőhöz?
Fel tudod csatolni a két db-t az MSSQL management-el is. Ott elkezdheted összenézni az adatokat.
Inkább ezt javasolnám: [link]
Gyakorlatba még nem használtam, így véleményem nincs, de a jelzett problémákat biztos egyenként kell majd végig nézni.. -
rum-cajsz
őstag
Erre a kérdésre ne nagyon várj komoly választ. Ha van konkrétum, abban tudunk segíteni, de két adatbázis migrációjának elvégzését csak úgy lehet megmondani, ha ismertek az adatbázisok.
Elméletileg bármit lehet, ami már bent van az adatbázisban, gyakorlatilag fel kell mérni a két adatbázis közös és eltérő pontjait, és egy áttérési tervet kell kidolgozni. Az áttérés előtt érdemes a két adatbázist helyben normalizálni, és csak ez után elvégezni az összefésülést.
Esetleg arra is van lehetőség, hogy ugyanazon a gépen több adatbázis is fut, akik nem tudnak egymásról.
-
Elvi válasz: igen, lehet.
Gyakorlati válasz1: nem lehet
Gyakorlati válasz2: lehet, de sok meló és sokba kerül.gyakorlati tapasztalatom az, hogy a duplikált adatok normális állapotba hozása automatizált programokkal lehetetlen, így marad a kézi babrálás egyesével, tételesen átnézve és ellenőrizve. ez pedig sok munka és általában sokba kerül. Sok ilyen melóm volt, a legutóbbit 3 hete fejeztük be, és mindig káosz volt.
Egy példa: tegyük fel (tényleg csak a példa kedvéért, mert ennek bemutatására kiválóan alkalmas a neve), hogy Giró-Szász András az ügyfeled. Komoly pénzeket vagyok hajlandó feltenni arra, hogy az egyik gépen Giró Szász András néven lesz rögzítve, a másikon Giró-Szász András néven, és ha lenne egy harmadik géped is, akkor ott Giró-szász András lenne.
Abban is komolyan hiszek, hogy az utcák helyesírása sem ment, tehát még egy Kossuth utca is többféleképpen lesz az adatbázisokban, pláne egy bonyolultabb. További probléma, ha átneveznek egy utcát, vagy Moszkvateret, akkor az is olyan szintű inkonzisztenciát fog okozni, amit lehetetlen leprogramozni.
valaki leül a gépek elé, és kézzel bepötyögi, más út nincs.
-
seger
addikt
Sziasztok!
Kérdéssel fordulok hozzátok!
Van-e arra lehetőség, ha igen hogyan.
van 2 számítógép, mind a kettő használ egy programot. (ugyan azt a progit) Adatbázis (LDF,MDF)
Mind a két gépen vannak adatok bőven. van olyan hogy mind a két gépen ugyanazon név alatt de más adat.
A kérdés az lenne, van-e lehetőség 1 gépre összehozni mindent 1 adatbázisban. Ugyanis ahol egy név alatt más az adat de a név ugyan az, az egybe kellene lennie.
Mivel az egyik gépet meg kell szüntetni.
Remélem érthetően irtam le.
Köszi -
#2761
Apollo17hu
őstag
dellfanboy
#2759
Apollo17hu
őstag
válasz
dellfanboy
#2759
üzenetére
Nem biztos, hogy hibás. Attól függ, mi a kérdés, amire a scriptet írod.
-
#2760
sztanozs
veterán
dellfanboy
#2759
válasz
dellfanboy
#2759
üzenetére
Építsd fel újra (lépésenként) a lekérdezést és a végén meg fogod találni azt a logikai hibát, ami a nulla elemű eredményhalmazt okozza...
-
#2759
dellfanboy
őstag
dellfanboy
őstag
van egy scriptem ami lefut, nem ír ki hibát viszont az eredményhalmaz 0. hol/hogy tudok rájönni, hogy mi lehet a hiba? túl sok feltételt rakok bele? vagy az egyik join nem jó?
-
válasz
rum-cajsz
#2752
üzenetére
ez azért nem jó, mert nem rendezi sorba az 5/a, 5/b, 5/c jellegű számokat.
az tűnik az elérhető legjobb megoldásnak, ha leválasztom az első számot, ebből lesz az első rendezési feltétel, kiveszem (ha van) a mínuszt és a pert, és ami utána van, abból csinálok egy másik rendezési feltételt. Ha ezt utcánként nézem, akkor annyira már nem elvadult a számozás, hogy túl nagy hibát vétsek. nyilván az összes lehetséges esetet ez nem fedi le, de úgy látom, hogy nem fordul elő minden kombináció minden utcában, tehát utcán belüli sorbarendezésre ez elég.
-
#2754
bambano
titán
Sk8erPeter
#2751
válasz
Sk8erPeter
#2751
üzenetére
Az alapján, amit írtál, ezt faragtam, ez közelíti meg legjobban a korrekt rendezést szerintem:
select street_id,number, substring(trim(leading ' ' from number), '^[0-9]+')::integer,
trim(leading '/-' from trim(leading '0123456789' from trim(leading ' ' from lower(number))))
from locations order by 1,3,4;kösz az ötleteket.
-
#2753
Sk8erPeter
nagyúr
rum-cajsz
#2752
Sk8erPeter
nagyúr
válasz
rum-cajsz
#2752
üzenetére
Azt írta, hogy "van szám, szám per betű, számtólszámig és több más forma is." Szóval nem túl szabályos. A regexp, amit előbb írtam, a legegyszerűbb megközelítés, ha lenne több példaadat is, akkor persze könnyebb lenne több esetet is lefedő regexpet írni, de a megadott példaadatokkal ez is működik (ld. SQL Fiddle-példát).
-
#2750
bambano
titán
Sk8erPeter
#2749
válasz
Sk8erPeter
#2749
üzenetére
úgy látom, pgsqlnek nem jó:
ERROR: invalid input syntax for integer: " 51/g" -
#2749
Sk8erPeter
nagyúr
bambano
#2748
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) -
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 -
#2747
Khelben
nagyúr
dellfanboy
#2745
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 -
#2746
martonx
veterán
dellfanboy
#2745
martonx
veterán
válasz
dellfanboy
#2745
üzenetére
where faktor = -1 ?
-
#2745
dellfanboy
őstag
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?
-
#2744
fordfairlane
veterán
fordfairlane
#2743
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é.
-
#2743
fordfairlane
veterán
Khelben
#2739
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.
-
#2742
Khelben
nagyúr
Peter Kiss
#2741
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.
-
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. -
#2739
Khelben
nagyúr
fordfairlane
#2738
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.
-
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.
-
#2735
Khelben
nagyúr
Sk8erPeter
#2734
Khelben
nagyúr
válasz
Sk8erPeter
#2734
üzenetére
Kérdés, hogy a törölt kulcsot vissza lehet-e valahogy állítani
-
#2734
Sk8erPeter
nagyúr
Khelben
#2733
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. -
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.
-
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.
-
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.
-
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
-
Ispy
nagyúr
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.
-
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 () ?
-
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!
-
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]
-
#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.
-
-
-
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ó.
-
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.
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Új hozzászólás Aktív témák
- Android játékok topikja
- Tesla topik
- Utánajártunk, hogy melyik memória mennyire drágulhat
- Mikrotik routerek
- Telekom otthoni szolgáltatások (TV, internet, telefon)
- Epic Store Ünnepi Ajándékozás - 7. nap: The Callisto Protocol
- Bittorrent topik
- Témázgatunk, témázgatunk!? ... avagy mutasd az Android homescreened!
- gban: Ingyen kellene, de tegnapra
- Tőzsde és gazdaság
- További aktív témák...
- ÁRGARANCIA!Épített KomPhone Ryzen 5 7600X 32/64GB RAM RTX 5070 12GB GAMER PC termékbeszámítással
- Újszerű Acer Aspire A515 - 15.6"FHD IPS - i5-1335U - 16GB - 512GB SSD - Win11
- BESZÁMÍTÁS! MSI B450M R5 5600X 32GB DDR4 500GB SSD RX 6800 16GB Zalman Z1 PLUS Cooler Master 750W
- Xiaomi Redmi 14C / 4/128GB / Kártyafüggetlen / 12Hó Garancia
- Új, Aktiválatlan iPhone 17 Pro (256 GB) (rendelhető)
Állásajánlatok
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest
Cég: BroadBit Hungary Kft.
Város: Budakeszi