Félre ne érts, nem vagyok Oracle fan (akkor már inkább MS SQL Server...), de ez az azt mondták dolog azért nagyon nem így megy. Egyáltalán mit kellett tárolni, mit kellett lekérdezni, milyen szerver architektúrában gondolkoztak és így tovább. Hiszem, hogy akik ilyet, csak így egyszerűen kijelentenek, egyszerűen nem értenek hozzá.
Én is láttam olyan projektet, ahol azért cserélték le a MySql-t (na jó a MySql valóban nem az SQL technológia csúcsa) MongoDB-re, mert olvastak blogokat, meg teszteket, hogy az mennyivel gyorsabb, aztán kiderült, hogy amikor adatot kellett lekérdezni, akkor pont ugyanolyan szarban voltak vele
Végül az én csapatom oldotta meg a gondot MS SQL Serverrel újra írva az egészet. Esetemben se az MS SQL volt önmagában a megoldás, hanem a normálisan megírt backend.

Nyilván van amiben egy NoSql jobb (mint mondtam mi is használjuk, ha a szükség úgy hozza, pl. log adatok beleömlesztésére, tracking pixelek adatainak beleömlesztésére, redist distributed cache-nek stb...), csak az ilyen nagy kijelentéseken akadok fenn, hogy ez szar, az meg a jövő, miközben érződik, hogy akik ezeket a kijelentéseket teszik, rohadtul nem értenek hozzá.

Én kérek elnézést!

Sziasztok!

MS SQL-el kapcsolatban lenne néhány apróbb kérdésem. Főként a dátumok kezelésével és néhány szintaktikai dologgal. A neten tök más dolgokat találtam, gondolom ez az sql fajták különbözősége miatt van. Mindegy a lényeg:

1 Hogyan tudok egy pl "2018-04-25 és 2018-04-26 között" feltételt megadni. Az érettségik megoldásaiban igy néz ki:
(...) datum BETWEEN #24/12/2012# AND #01/01/2013#

Pontosan mire szolgálnak a # jelek, kötelezően a d/m/y formátumot kell használni?

2 Ha csak egy szótöredékre keresek akkor azt hogyan tudom helyesen a LIKE-val megtenni, esetleg mást kell használni? mi a pontos szintaktika? LIKE "*valami*" vagy nem kell kacsacsőr, esetleg kivülre kell a csillag?

[ Szerkesztve ]

(raw_item.get("pk").unwrap().as_s().unwrap().to_string()).split("#").collect::<Vec<&str>>()[1].to_string()

Biztos MS SQL???

1. MSSQL-ben #-ot nem használunk between '2012-12-24' and '2013-01-01' a helyes szintaktika
2. Like-ban szótöredékre %-ot használunk biztosan nem *-ot.

Szóval nekem nagyon gyanús, hogy valamit nagyon-nagyon félrenézel.

Én kérek elnézést!

MS SQL az a microsoft access-ban használt sql nem? Nekünk abban kell dolgozni, és a megoldásból szedtem azt a sort. én is kötőjelekkel találtam a neten mindenhol kb a helyes dátum jelölést

(raw_item.get("pk").unwrap().as_s().unwrap().to_string()).split("#").collect::<Vec<&str>>()[1].to_string()

Nem ugyan az, az ms sql az egy szoftver és Transact SQL (T-SQL) dialektussal tudsz beszélgetni vele.

[ Szerkesztve ]

szuper akkor ezt kevertem, akkor az első kérdésem átfogalmaznám úgy, hogy "accessben mik a helyes szintaktikák"

(raw_item.get("pk").unwrap().as_s().unwrap().to_string()).split("#").collect::<Vec<&str>>()[1].to_string()

[link]

Ha így szeretnéd látni, illetve beírni a dátumot:
tervezőben where mező = Format("2018.03.29";"yyyy.mm.dd")
sql-ben where mező = Format("2018.03.29","yyyy/mm/dd")
betweenre is működik csak ott 2x kell

és

where mező Like ("%keres%")

Antonio Coimbra de la Coronilla y Azevedo, bizony!

Sziasztok!

Épp ismerkedni kezdek az SQL-lel, de mielőtt végleg elhatároznám magam, gondoltam rákérdezek itt is, hogy tényleg lenne-e értelme.

Szóval, a célom az, hogy készítsek egy nagyon-nagyon basic adatbázis lekérdező rendszert, amely különböző online weboldalakról gyűjti ki a kért információkat. Legyen az mobile.de-s autóhirdetés, Vatera, vagy hasonló hirdetési felületek. Hogy konkrétabban megfogalmazzam: elsőként mindenképp mobile.de-vel kezdeném, mert más okból ez érdekel most leginkább.

A kérdésem inkább jogi, mint technikai jellegű: ha saját erőből vagy segítséggel sikerülne összeraknom egy ilyen adatbányász kódot, azzal az adott weboldal (esetünkben mobile.de) üzemeltetőjét én jogi értelemben megkárosítom? A német adatvédelmi törvények elég szigorúak, viszont technikailag itt nem adatlopásról van szó (hiszen az információ szabadon, ingyen hozzáférhető). Ami egyedül aggályos, hogy ezzel az oldal üzemeltetését lehetővé tévő hirdetéseket kerülném meg, ugyanis a nyers adattáblákban ez nyilván nem jelenik meg.

Totalcar.hu-n volt régebben egy cikk, ahol arról írtak, hogy egy magyar srác pont ezt tette és így optimalizálta az autókeresést. A kódot természetesen a fenti okokból nem tette közzé és én sem szándékozok szándékosan szivárogtatni

- És te hogy neveznél egy baromi gyors, apró, kék izét...?

"üzemeltetőjét én jogi értelemben megkárosítom?": igen, egyértelműen megkárosítod.
"technikailag itt nem adatlopásról van szó (hiszen az információ szabadon, ingyen hozzáférhető": de, adatlopás.

itt az a lényeg, hogy a mobile.de milyen feltételekkel vette át a hirdető adatait. egyrészt nyilván nem olyannal, hogy azt bárki viheti és akkor a mobile.de rendszerét megkerülve szabadon garázdálkodhat közöttük.
másrészt aki oda felrakott egy hirdetésben személyes adatot, az azt engedélyezte, hogy azt az adatot a mobile.de az autó eladásával kapcsolatos folyamatokban kezelheti. senki semmilyen más célra nem kezelheti.

az igaz, hogy a németeknél szigorú a törvény, szóval ha nem akarsz beleszakadni a bírságukba, ne csináld.

Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis

Köszi az intést. Délután szakítok időt a jogi nyilatkozatra / EULA-ra, aztán megpróbálom felkutatni az illetőt, aki a Totalcar cikkben szerepel. Valószínűleg kiismeri magát a témában

- És te hogy neveznél egy baromi gyors, apró, kék izét...?

Elolvasod a felhasználási feltételeket, és rögtön ki fog derülni, hogy csinálhatod-e vagy sem (vsz nem).

JOGI NYILATKOZAT: A bejegyzéseim és hozzászólásaim a személyes véleményemet tükrözik; ezek nem tekinthetők a munkáltatóm hivatalos állásfoglalásának...

szerintem felesleges elolvasni az eula-t, aki feltette az adatait a mobile.de-re, biztosan nem adott rá engedélyt, hogy te onnan leszedd, hiszen nem is tudhatott róla, hogy le akarod szedni.

az én álláspontom szerint ez az ötlet sérti az adatvédelmi szabályokat, én hozzá se fognék.

Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis

Nem vitatkozni akarok, hiszen az ügyben nincs tapasztalatom. Viszont logikailag nem látom miért lenne a hirdetett járművek adatainak begyűjtése jogsértő, hiszen azok teljesen nyilvánosan publikált adatok, amiket én is, te is bármikor elérhetünk a weboldalon. A különbség, hogy nem a mobile lassú kezelőfelületét kell nyomkodni hozzá, hanem egy Excel táblát / adatbázist pörgetni.

Analógia (szerintem): mintha egy koncerten egyesével kéne mindenkitől megkérdezned, hogy milyen színű pólót hord, de ehelyett te a lelátóról összeszámolod magadnak.

A személyes adatok (mint név, telefonszám) ehhez szükségtelenek is lennének. Bár az tény, hogy valószínűleg csak egy extra lekérdezésen múlna azok kigyűjtése is, azaz a lehetőség adott rá (de ezek is nyilvánosan az oldal minden user-ének).

- És te hogy neveznél egy baromi gyors, apró, kék izét...?

Attól még, hogy nyilvánosan publikált adathalmaz, valakinek a szellemi tulajdonát képezik.

Hello IT! Have you tried turning it off and on again?

két dolog:
1. az adatbázishoz kapcsolódik szerzői jog. az adatbázist valószínűleg abban a gazdasági konstrukcióban építik, hogy bejön az adat, reklámokkal megpakolva kiteszik, azért kapnak díjat, ebből tartják fent a szájtot. ha te excelben pörgeted, akkor megsérted az adatbázis tulajdonos szerzői jogait.
2. a rajta levő személyes adatokhoz fűződő adatvédelmi jog: az adatot csak arra lehet használni, amire felhasználási engedélyt kaptál az adat tulajdonosától. tehát pl. hiába van kint a nevem, mobilszámom, email címem nyilvános adatbázisban, ha én ezeket az adatokat egy bizonyos célhoz kötötten tettem ki oda, te nem használhatod semmilyen más célra. a felhasználási jogosultságot nem a publicitás alapozza meg, hanem az adatkezelési cél és a hozzá adott engedély.

tehát ha én azért rakom ki publikusan a telefonszámomat, hogy az autómat megvegyék, akkor azt csak az a webhely kezelheti, amelyikre kiraktam a hirdetésemet, csak azért, hogy az autóm eladásában közreműködjön, plusz a vevő kezelheti abból a célból, hogy vételi szándéka esetén felhívjon. minden más felhasználás illegális. te semmilyen engedélyt nem kaptál az adat kezelésére, tehát nem kezelheted. teljesen mindegy, hol találtad az adatomat, ha nem kaptál tőlem engedélyt a kezelésére, akkor nem kezelheted.

Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis

Köszi, így már egyre világosabb a szituáció

- És te hogy neveznél egy baromi gyors, apró, kék izét...?

Sziasztok!

PostgreSQL-ben van egy táblám, ami egyik mezőjében számokat tartalmaz ehhez hasonlóan:
4,5,6,10,11,12,55,56,57,888,889,890

Tehát számsorozatok, de van köztük kihagyás is. Azt szeretném csinálni, hogy ezeket csoportosítsa össze. Tehát egy új oszlopban kapjon egy azonosítót minden egyes csoport. Példámnál maradva 4 csoport lenne: az elsőben a 4,5,6. Másodikban a 10,11,12 stb.

Szerintetek hogyan lehetne ezt megvalósítani SQL-ben?

Szerintem itt pont ezt veséztük ki: [link]

akkor az adatvédelmi törvényt nem sérted, csak a szerzői jogról szólót.

Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis

MS SQL-ben küzdöttem egy számból idő formára konvertálással.
Ennél egyszerűbb megoldást tud valaki?

-- percek száma int-ben jön
declare @szam int = '2510'

-- ami kéne: óra:perc pl. 41:50
select rtrim(convert(char, convert(int,@szam/60)))+':'+right('0'+rtrim(convert(char, @szam - convert(int,@szam/60)*60)),2)

Antonio Coimbra de la Coronilla y Azevedo, bizony!

declare @szam int = '2510';
select dateadd(mi, @szam,'2018/05/22');
2017-08-26 17:50:00.000

[ Szerkesztve ]

Tudod, mit jelent az, hogy nemezis? Az érintett, erősebb fél kinyilatkoztatása a méltó büntetés mértékét illetően. Az érintett fél jelen esetben egy szadista állat... én.

Egész szám:

[szám]/60

Maradék:

[szám]%60

Pl:

declare @int integer = 2510

select @int/60, @int%60, , CAST(@int/60 AS varchar(10)) + ':' + RIGHT('00'+ CAST(@int%60 AS varchar(10)), 2)

[ Szerkesztve ]

"Debugging is like being the detective in a crime movie where you're also the murderer."

Köszi az ötleteket.

cain69 - nem tudom a dátummal mit akartál, a szám csak a percek száma, nincs benne dátum

Ispy - a CAST és a %-os megoldás ügyes lett, köszi

Antonio Coimbra de la Coronilla y Azevedo, bizony!

elvileg a dateadd simán időt is képes kezelni, viszont akkor a kezdő offsetet nem stringként, hanem time típusúként kell megadnod, így:

declare @starttime time(0) = '0:01';
declare @szam int = '2510';
select dateadd(mi, @szam,@starttime);
17:51:00
az előnye, hogy egyszerű, mint a bevert szög, mert nem kell castolgatni, trimmelegni.
a hátránya, hogy a nap feletti részt kapod meg, tehát ha 1 napnál több percre jön ki, akkor az óra:perc maradékot kapod, ahogy fent is látod (2510 perc több, mint egy óra). ha kell a nap is, akkor az már datetime.

Tudod, mit jelent az, hogy nemezis? Az érintett, erősebb fél kinyilatkoztatása a méltó büntetés mértékét illetően. Az érintett fél jelen esetben egy szadista állat... én.

Aha, így ez se rossz.
Csak sajna simán van több kijövő óra mint 24.
Azért köszönöm.

Antonio Coimbra de la Coronilla y Azevedo, bizony!

Sziasztok!

PostgreSQL-t használok és exportálok CSV-be adatokat for ciklussal így:

for rec in
select format('copy(select valami from table where nev=''%s'' order by gid)
to ''%s'' with csv delimiter '';'' HEADER',nev,'C:/eredmeny/'||nev||'.csv' ) scr from(
Select distinct nev from tabla)t
loop
execute rec.scr;
end loop;

Ez most külön CSV-t hoz létre minden egyes névnek. Eddig rendben van, jól működik. Azonban, én azt szeretném, hogy a fájlnévben egy másik mező értéke is szerepeljen. Tehát ne csak a név, hanem egy másik oszlophoz tartozó érték is benne legyen a filenévben. Valahogy így: telepules_nev.CSV
Minden egyes településhez több név is tartozik.

Szerintetek hogyan lehet ezt megvalósítani?

[ Szerkesztve ]

Na, elvileg megoldottam, így:

for rec in
select format('copy(select valami from table where nev=''%s'' order by gid)
to ''%s'' with csv delimiter '';'' HEADER',nev,telepules,'C:/eredmeny/'||telepules||'_'||nev||'.csv' ) scr from(
Select distinct nev, telepules from tabla)t
loop
execute rec.scr;
end loop;

Azért még leellenőrzöm alaposan, hogy tényleg jó-e.

Sziasztok!
Ti hogyan csinálnátok hasonló privát üzenet rendszert, mint ami itt a PH-n van?
Az alap tábla ötlet:

messages:
-from_id
-to_id
-text
-time

Ha a felhasználó megnyitja az üzeneteket, csoportosítja felhasználónként, kiírja az üzenetek számát és ezt az üzenet ideje szerint rendezi csökkenőbe. Ha rányom a felhasználóra, kiírja a felhasználó által küldött és a felhasználónak küldött üzeneteket.

Hogyan oldanátok meg a queryket? Előre is köszi!

Az itteni funkcionalitáshoz azért lehet, hogy többre lenne szükség.
- messageid
- topicid
- status is kell, mert lehet szerkeszteni, moderátor törölheti, stb
- egy üzenet több csatolt képet is tartalmazhat, ezeket is tárolnod kell, bár értelemszerűen nem ebben a táblában

Fontos, ha valaki szerkeszt egy hozzászólást megőrzöd-e az eredetit.

Először írd össze, hogy mit kell ténylegesen tudnia. Ha ez megvan, akkor érdemes mellé valamit tervezni.

Azóta úgy oldottam meg, hogy csináltam egy másik táblát az üzenetet váltott felhasználóknak, a következő oszlopokkal:
messages_conversations:
-id
-user
-user2
-last_msg_time
-seen

Ha a felhasználó olyan felhasználónak küld üzenetet, akivel még nem beszélt, mindkettőjüknek be lesz jegyezve a másik(user2), a küldőnek seen igaz, a fogadónak seen hamis. Ha már beszéltek, a last_msg_time és a fogadónak a seen lesz updatelve.

Nemtudom, hogy jó helyre írok-e. Próba cseresznye. MSSQL Server téma.
Sajnos nem lehet upgradelni SQL 2005-öt 2008-ra, mert az Standard verzió, a cél pedig Express.
Van erre valami nagyon jó okosság?

Köszönöm előre!

Olyat rádverek...hogy megkulázol! :)

Backup-restore.

Egyébként 2018-ban miért egy 10 éves expressre akartok upgradelni?

[ Szerkesztve ]

"Debugging is like being the detective in a crime movie where you're also the murderer."

Lépcsőzetes frissítést kért az egyik számlázóprogram.
2005->2008->2014

És a standard funkcióját nem is használja ki, elég neki az express.

Jelenleg azt agyaltam ki, hogy rátolok egy trialos standard 2008-ast, ott már tudok az editionokon változtatni. Kiválasztom az expresst és akkor már elvileg gond nélkül mehetne rá a 2014 express.

Bár a MSSQL backup restore funkciót nem nagyon ismerem.

[ Szerkesztve ]

Olyat rádverek...hogy megkulázol! :)

Régi adatbázison csinálsz egy backup database-t, felrakod a tetszőleges express editiont és ott meg restore database-zel visszarakod, én biztos nem pöcsölnék ilyen upgradelésekkel, az egész meg van pillanatok alatt.

Már ha nem egy 20 terrás adatbázisról beszélünk.

Azt azért tudják, hogy így 1 GB ramra le lesznek korlátozva? Illetve proci limit is van, ha jól rémlik és azt hiszem 10 GB az adatbázis korlát.

[ Szerkesztve ]

"Debugging is like being the detective in a crime movie where you're also the murderer."

Most aza gond, hogy a kedves elődöm nem adta ki a passt. Így nem tudok belépni a database részre.

Össz-vissz az SQL 65 MB Ha ilyen pofonegyszerű lenne, akkor minek bonyolítják? :\
Tehát azt mondod, hogy a 2005-ös backupot szépen befogadja a 2008-as?

1GB RAM, 10 GB DATA és 1 CPU/4 MAG a korlát.
Kíváncsiságból kipróbálom a Te megoldásodat.

Olyat rádverek...hogy megkulázol! :)

Simán be kell neki újabbra rakhatsz fel régi adatbázist, csak fordítva nem.

"Debugging is like being the detective in a crime movie where you're also the murderer."

Amúgy az elképzelt metódus csak félig jó. Sikeresen upgradelt, de utána a mainternace résznél nem tudok editiont váltani. Szóval marad a backup-restore mód.

Olyat rádverek...hogy megkulázol! :)

Ha 65Mbyte-ról van szó, akkor én a helyedben simán kigeneráltnám a komplett DB-t sémástól, adatostól sql scriptbe, felraknék egy SQL 2017 (2014-et felrakni így 2018 közepén???) Express Editiont, és ráereszteném a scriptet. Érdekes mód, simán be fog minden menni

Én kérek elnézést!

Sajnos a számlázóprogram az SQL 2014-et kér. Azaz nem javasolja az ennél frissebb feltelepítését.
És még kiderült, hogy maga a számlázóprogram is képes menteni és visszaállítani.
Tehát legyalulható minden régi SQL és az újat felrakni. Majd hétfőn kiderül.

Olyat rádverek...hogy megkulázol! :)

Sziasztok!

TimesTen DB-ben kuzdok egy queryvel ami valamiert egy fele parameternel forditva fut le, igy a left outer join nem excludal adatokat, hanem pont az ellenkezo oldalt mutatja meg(amit ki kene vonni)

Rakukkantana valaki?

select count(s.id)
from subscription s
join SUBSCRIPTION_RESOLVE_KEY srk on s."UID" = srk.SUBSCRIPTION_UID
join account a on s.OWNING_ACCOUNT_UID = a."UID"
left outer join waitRoomEnabled ml on s."UID" = ml.SUBSCRIPTION_UID
where
ml.SUBSCRIPTION_UID is null
and
srk.DOMAIN_RESOLVE_KEY_UID = (
select drk."UID" from DOMAIN_RESOLVE_KEY drk
where drk.ID like 'guestPIN');

Köszi!

Sziasztok!

PostgreSQL-ben szeretnék kiválasztani SELECT-tel egy adott sort a sor száma alapján. Tehát van egy al-lekérdezésem, mely x db sort tartalmaz, és annak szeretném kiválasztani pl. a 3. sorát.
Van valami ötletetek miként lehet ezt megtenni?

Koszi a valaszt. Nekem az SQL meg elegge uj ezt is segitseggel raktam ossze kollegaval aki mar elment nyugdijba. Az adatbazis eleg komplikalt (legalabb is nekem ) A feladat pedig az, hogy a waitRoomEnabled view-kent letrejovo tablaban talalhato subscription-oket kell megkulmboztetni azoktol az osszes subscription-tol ahol ez a waitRoomEnabled parameter nincsen definialva, igy annak erteket nem lehet megvaltoztatni. Ezert valasztjuk ki az is null erteket, tehat balra azt tartjuk meg ahol az nincsen definialva. Ez eddig mukodott mindegyik rendszeren de most azt latom, hogy nehol forditva mukodik mint ahogy eddig es 0 erteket ad. Az uj modszer pedig megmutatja, hogy majdnem 400.000 ilyen Subscription wan ebben az adathalmazban. Ez egyebkent egy 1 evvel ez elotti feladat amiben ezek az SQL-ek nem megfeleloen futottak le es probalom kideriteni miert. altalaban 3 illetve 6-bol egyszer nem futott le rendesen. Mindenhol ugyan ez a waitRoomEnabled parameter.

Köszi!