Új hozzászólás Aktív témák
-
bambano
titán
válasz
RoyalFlush
#4664
üzenetére
valahogy így:
select t1.*,t2.* from datumok t1, datumok t2 where t1.id>t2.id and t1.datum<t2.datumfejből írtam, nem biztos, hogy szintaktikailag helyes.
-
bambano
titán
valaki tudja véletlenül, hogy xml adattípusból hogyan kell a root elemet kiszedni xpath-szal? esetleg ugyanezt konkrétan postgresql-ben?
kösz.
-
bambano
titán
válasz
martonx
#4606
üzenetére
egyetértek, nincs mit magyarázni, a postgresql legalább annyit vagy többet tud, mint ez a pandas. mondjuk ez így csak a statisztikai funkciókra igaz, mert ha melléteszed például a geometriai funkcióit is, akkor a python a fasorban sincs a postgresql-hez képest.
az utóbbi időben az a vélemény alakult ki bennem a postgresql-ről, hogy a legjobb, ha hagyod az adatbáziskezelőt dolgozni.
-
bambano
titán
válasz
Petya25
#4509
üzenetére
a probléma pár órás tojtorozása után nekem úgy tűnik, hogy a legegyszerűbb megoldás a következő:
csinálsz egy táblát, olyan szerkezettel, ami neked tetszik, plusz hozzáadsz egy oszlopot, pl. sor néve, text típussal:tmp=> \d merestmpTable "public.merestmp"Column | Type | Collation | Nullable | Default--------+------------------+-----------+----------+--------------------------------------id | bigint | | not null | nextval('merestmp_id_seq'::regclass)subid | bigint | | |azon | text | | |meres1 | double precision | | |meres2 | double precision | | |meres3 | double precision | | |meres4 | double precision | | |sor | text | | |utána belemásolod az input fájljaidat úgy, hogy a szövegből minden sort egyben tegyen bele a sor mezőbe:
\copy merestmp(sor) from '/tmp/mteszt.txt';Majd adatbáziskezelős függvényekkel szétszeded a sorokat.
update merestmp set subid=id,azon=trim(both from sor) where array_length(regexp_split_to_array(sor,' +'),1)=1;ezek után a subid-t beállítod az előtte levő sorra:
update merestmp m1 set subid=(select max(subid) from merestmp m2 where m2.id<m1.id) where array_length(regexp_split_to_array(sor,' +'),1)=5;
ennél a megoldásnál nyilván van szebb is, windowing funkciókkal...
utána már csak regexp-ekkel ki kell szedni a mezőket a sorból és betenni a helyükre. -
bambano
titán
válasz
Petya25
#4509
üzenetére
nem ismerem az mssql-t, postgresql-ben így csinálnám:
csinálnék egy táblát, amiben van egy id mező, aminek serial (más adatbáziskezelőkben autoincrement), meg van benne egy másik id2 mező, aminek a defaultja egy serial aktuális értéke, van egy text mező, meg négy real.
tennék rá egy szabályt, hogyha mind a négy real mezője null, akkor a második mezőt növelje egyel és úgy húzza be a többi sort.szerk: persze a triviális megoldás az, ha awk-val insert-té alakítod a fájlokat.
szerk2: esetleg dobj fel valahova 3-4 ilyen kis fájlt, amivel kísérletezni lehet.
-
bambano
titán
"NOT IN vs LEFT JOIN?": értem, amit írsz, de.
a calendar tábla évi nagyságrendileg 20 rekorddal bővül, és mivel a subselectben van dátumra való korlátozás, így amikor ez végrehajtódik, akkor néhány rekord kerül a not in (...) -be. ennyivel boldoguljon már.annak utána fogok járni, hogy az áthelyezett szombat az én problémám szempontjából minek számít. kösz a felvetést.
-
bambano
titán
válasz
Apollo17hu
#4473
üzenetére
logikáját tekintve valóban az, amit nyunyu írt, de ezt én is leírtam már (#4469) (eltekintve attól, amennyivel butább az oracle...
) . amit te írtál, az teljesen más. te keresnél egy számolótáblát az adatbázisban, amit nem tudok értelmezni, és azzal számolnál. ezzel szemben a postgresql (ami kikötés volt), on the fly képes sorozatokat generálni és record-setként kezelni. a hétvégéket nem modulo 7 alapján számolja, ami egyébként is lehetetlen, mert a kiinduló napnál hiába akarnál modulo7-et számolni, hanem a beépített naptár funkcióval, ahogy nyunyu is.lelassulhat? miért is?
-
bambano
titán
válasz
bambano
#4461
üzenetére
én erre jutottam:
1. generálom a következő napok dátumait
2. ebből kidobom, ami szerepel a calendar táblában
3. kilistázom a maradékból a munkanapokat, sorbarendezve
4. a listából az n. elemet lekérdezemamiben nagyon más: van generátor függvény, ami többek között dátum típusra is működik, és az ünnepeket egy not in subselect halmazzal szedem ki.
kb. így néz ki postgresql-ben:
select l.nap,date_part('dow',l.nap),to_char(l.nap,'YYYYMMDD') as kompaktdatum from(select date_trunc('day',generate_series(now()+'1 day'::interval,now()+'30 days'::interval,'1 day'::interval)) as nap ) lwhere l.nap not in (select distinct date from calendar where date>now()and date<now()+'30 days'::interval)and date_part('dow',l.nap) in (1,2,3,4,5) order by l.nap limit 1 offset 5; -
bambano
titán
válasz
Apollo17hu
#4464
üzenetére
ennél sokkal egyszerűbbet szeretnék.
-
bambano
titán
válasz
Apollo17hu
#4462
üzenetére
a calendarban csak a rendkívüli munkarend napjai vannak benne.
-
bambano
titán
Érdekelne a ti megoldásotok postgresql-ben:
Előre adott n-re annak a napnak a dátuma EEEEHHNN formátumban, amelyik a lekérdezéstől számítva az n. munkanap úgy, hogy a lekérdezés napja a nulladik, a másnapja az első. Segítségként van egy calendar nevű tábla, amiben rekordonként benne vannak az ünnepnapok és a munkanap áthelyezések, egy date nevű mezőben.tehát ha ma lefuttatom 6 napra, akkor 20200415-öt ad eredményül.
kösz
-
bambano
titán
szerintem csinálni kell egy temporális táblát, abba belerámolni a szűrt adatokat, azt kidumpolni, betölteni a másikon ugyanolyan temporális táblába majd onnan berakni a helyére.
egyszerűbbet én sem tudok, mert a pg_dump nem tud válogatva dumpolni.
de lehet, hogy mégis tudok egyszerűbbet: újabb postgreseken lehet olyat, hogy az adatbázisszerver beloginel egy másik postgresbe, és úgy éred el a táblákat, mint a helyi táblákat. ezt megteszed, és akkor csinálhatsz olyat, hogy insertálod a helyi szerveren a távoli táblából szelektált sorokat.
-
bambano
titán
válasz
kw3v865
#4390
üzenetére
a postgresql is tud olyat, hogy ip címre vagy tartományra korlátozni a klienseket, illetve ugyanezt tűzfallal is meg lehet oldani. ez akkor jó, ha a klienseknek ismert az ip címtartománya.
elvileg használ ssl-t, tehát akár azt is meg lehet csinálni, hogy csak ismert kulcsú klienseket beengedni.
hogy ez mennyire biztonságos, az attól is függ, hogy milyen adatokat teszel bele.
a másik lehetőség, én valószínűleg ezt választanám, hogy az insert utasításokat kiírom egy text fájlba, azt rsync+ssh-val szinkronizálnám a szerverre, és ott betölteném adatbázisba.
A db-ben hosztolt adatbázisról meg annyit, hogy a benne tárolt adatok fajtájától és a hozzá tartozó szabályzatoktól, eljárásrendtől függően (úgy értem: ezek nem elegendően precíz meghatározása esetén) akár 2 év börtönnel fenyegetett bűncselekmény is lehet felhőbe adatbázist rakni.
Az api api hátán api-val megbolondítva típusú túltervezettségről továbbra is az a véleményem, hogy semmi értelme, mert egy saját fejlesztésű apiban nagyobb valószínűséggel lesz bug, mint egy postgresql net protokollban, vagyis olyan plusz energiabefektetés, ami sose térül meg, csak ront a helyzeten.
-
bambano
titán
válasz
tototos
#4263
üzenetére
ha nincs szerveretek, akkor a kliens gépeket se mentitek?
mert egyébként ha legalább egy mentést tároló szerver lenne, oda felrakhatnád az adatbáziskezelőt is.szóval én vennék egy hp microservert, nem olyan eszement pénz, felraknám rá az sql szervert, oszt jónapot. sok diszket, arra mehet a backup a kliensekről.
-
bambano
titán
válasz
kezdosql
#4202
üzenetére
egyrészt a clipper nagyon jól fut dosemuban.
másrészt létezik, flagship néven.szerk: persze lehet, hogy félreértettelek. ha az az elvárás, hogy egy exe legyen, ami clipper kompatibilis adatbázisokat kezel, akkor flagship. ha az az elvárás, hogy egy exe, akkor beépíthető, külön telepítést nem igénylő adatbáziskezelő van kilószám, akár firebird, akár más.
-
bambano
titán
ezeket a feladatokat nem mindig értem. pl. életemben nem használtam having-ot, most per pillanat azt se tudom, mire jó. de a gugli ennyire azért a barátom, meg tudom találni, hogy mi az. akkor én most megbuknék nálatok?
vagy volt olyan, hogy az egyik rossz pontot úgy szereztem interjú előtti teszten, hogy nem tudtam kapásból, hogy a postgresql vacuum-ja mikor mit hogy lockol. mer úgy kb. ki a bánatos francot érdekli. ha gondom lesz vele, elolvasom, felfogom és alkalmazom. de erre nincs szükségem, mert oda nem kerültem be, mert nem tudtam fejből a vacuumot.
úgy látom, nem csak sql terén van baj, hanem toborzás terén is...
-
bambano
titán
ilyen mindenhol van.
logolni a mysql naplójába lehet (gondolom, mert azt se ismerem), a próbálkozások helyéről meg a forrás ip cím felvilágosít, azt kernel szinten érdemes logoltatni a beépített tűzfallal.egyébként meg én nem olvasgatnék ilyen logokat, totál időpazarlás, rakás kiskínai erőlködik. ha linuxon futnak a mysql-ek, akkor van rá egy fail2ban alkalmazás, azzal meg lehet csinálni, hogy beállított számú elrontott bejelentkezés után kitiltsa az ip címet a tűzfalban, oszt jónapot.
-
bambano
titán
válasz
Apollo17hu
#4180
üzenetére
"Szerencsére nem mind a 20 allekérdezés 800 soros, összesen "csak" 4.300 sorból áll a kód": teljesen megnyugodtam

-
bambano
titán
válasz
Apollo17hu
#4178
üzenetére
nem merült fel, hogyha 20 darab 800 soros allekérdezés van összerakva, akkor az egész totálisan rosszul van megtervezve?
-
bambano
titán
szerintem nem jó irányból közelítesz.
ha egy mezőben szöveg is lehet, akkor az nem lehet int. tehát vagy "n/a"::stringet kell visszaadnod, vagy stringgé konvertált számot. tudomásom szerint olyat egyetlen sql adatbáziskezelő se tud, hogy egy oszlop az egyik sorban string, a másikban meg szám. -
bambano
titán
válasz
Apollo17hu
#4170
üzenetére
erőforrásokat nem nézted? lehet, hogy valamelyik elfogy. memória, lockok, stb. postgresql-hez értek, abban van ilyen.
másik ötlet: temporális táblába nem érdemes leválogatni a lekérdezéseket?
-
bambano
titán
válasz
sztanozs
#4146
üzenetére
megnéztem rendesebben a kérdést, és nem látom értelmét bemásolni az eredményt.
az explain és az explain analyze egymáshoz képest fordított eredményt hoz. az explain szerint a not in 4x gyorsabb, az explain analyze szerint meg az exists gyorsabb.ez elég fura, mert elvileg az exists-hez le kellene futtatni a subselectet minden sorhoz, ami a fő selectben van. egyébként pedig a postgresql-nél ez a probléma régebben felmerült, úgy látom, hogy a query plannere fel van rá készítve és jó eredményt hoz.
-
bambano
titán
válasz
sztanozs
#4141
üzenetére
explain select * from customer where id not in (select customer_id from <anonimizálva>);
QUERY PLAN
---------------------------------------------------------------------------------
Seq Scan on customer (cost=1174.57..1372.72 rows=3366 width=243)
Filter: (NOT (hashed SubPlan 1))
SubPlan 1
-> Hash Join (cost=395.85..1134.83 rows=15895 width=4) -
bambano
titán
válasz
david199801
#4070
üzenetére
k_nev-nek nem adtál meg méretet.
-
bambano
titán
"Ennyi erővel az árat és a darabszámot is ki lehetne tenni külön táblába, mert lehetséges, hogy különböző termékeknek ugyanannyi az egységára és ugyanannyi darabot vásároltak belőle ugyanakkor.": ez így nyilván csak a példa kedvéért került elő.
a termék árát akkor kell kivenni a vásárlásból, ha az minden vásárlásnál ugyanaz. tehát ha a bukóhullámú homálytizedelő mindig 3 gombba kerül, akkor a termék törzsben az ár helye, ha vásárlásonként változik az ára, akkor meg a vásárlás táblában. ilyenkor úgyis az lesz a vége a történetnek, hogy lesz ilyen-olyan vevő, más és más árengedménnyel, stb, és az ár marad a vásárlás táblában.
-
bambano
titán
válasz
mr.nagy
#3935
üzenetére
bocs, mssql-hez nem értek. postgresben úgy csinálnám, hogy van generate_series függvény, ami halmazt ad vissza. az egyik lehetőség: ezt
select now()+generate_series(0,7)*'1 day'::interval;
berakod egy subselectbe, és kiválasztod azt, ahol a hét napja az, amit szeretnél.Ha az mssql is tudja, amit a postgres, hogy sorozat timestamp is lehet, akkor egyszerűbb a dolog:
select generate_series(now(),now()+'7 days'::interval,'1 day'); -
bambano
titán
válasz
kw3v865
#3900
üzenetére
ha postgresql-hez kötött megoldás is megfelel, akkor:
where id = (select last_value from table_id_seq);ezzel a lekérdezéssel bármikor le tudod kérdezni a legutolsó id-t. de ez nem szép.
ha az adott sessionben raktad bele a sort, akkor egy fokkal rendesebben néz ki:
where id = (select currval('table_id_seq'));vagy, szerintem a legjobb megoldás, kérdezd le, hogy milyen értéket szúrt be az insert, ha ez megoldható:
insert blablab returning id;ezt akkor tudod használni, ha az insertet akkor csinálod, amikor az id-je is kell.
-
bambano
titán
válasz
kw3v865
#3860
üzenetére
ha az a kérdés, hogy hogyan hozod össze a rekordot meg az utána következő rekordot, akkor ebből inspirálódhatsz:
lehet táblának saját magával vett descartes szorzatát venni:
select t1.*,t2.* from tabla t1, tabla t2;
ezt a te esetedben nagyjából így kellene alkalmazni:
select t1.*,fuggveny(t1.masvalami,t2.masvalami) from tabla t1, tabla t2 where t1.id+1=t2.id;
ebből meg tudod faragni az udapte utasítást.
ha egy 8 millió soros táblára ráborítod, jusson eszedbe, hogy adatbáziskezelésnél a sok ramot csak a mégtöbb ram pótolhatja

-
bambano
titán
válasz
Johnny_vT
#3818
üzenetére
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.
-
bambano
titán
válasz
Johnny_vT
#3815
üzenetére
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.
-
bambano
titán
válasz
Johnny_vT
#3812
üzenetére
"ü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.
-
bambano
titán
válasz
Apollo17hu
#3686
üzenetére
nem

szerintem az lenne a legegyszerűbb megoldás, hogyha a lebegőpontos értéket megszorozza 5-tel és veszi az egészrészét, akkor megkapja, hogy hanyadik hisztogram oszlopba kerül az az eredmény, vagyis count és group by már használható. -
bambano
titán
válasz
kw3v865
#3665
üzenetére
annak a true-nak meg false-nek nem sok értelmét látom, mert ha védett régióban van, akkor a védett régió neve oszlop nem null lesz, ha meg nem ott van, akkor igen.
viszont ez nem kellene, hogy sokat lassítson, mert a postgresql elméletileg becacheli az adatokat meg az eredményeket.
ha a kifejezés elé írsz egy explain-t, akkor megmondja az optimalizáló, hogy mit fog csinálni. azt érdemes bogarászgatni.
szerk: azt az egész case-t ki lehetne váltani szerintem úgy, hogy a lekérdezett mezők közé felveszed a védett régió nevét, és egy coalesce-vel beleírsz valamit, ha üres: coalesce(pr.name,'FALSE') as name.
-
bambano
titán
kösz mindkettőtöknek, de nekem ez egy kicsit bonyolult

én a következőkre jutottam: neten talált ötlet, hogy rakjak a számsorra egy rank()-et. lényeg, hogy subselectben kell legyen a számsor, mert a distinct meg a rank postgresben nem fér össze.a szám-rank() az gyakorlatilag megmondja, hogy hány szám maradt ki eddig a sorból. ami azt is jelenti, hogy egy részsorozaton belül a szám-rank() konstans. vagyis kezelhető group by-jal.
select min(number),max(number),count(*) from (
select number,number-rank() over (order by number) as ranked from (
select distinct number as number from item order by 1) as w
) as q group by ranked order by 1;a legbelső selectből kitöröltem a nem publikus részt.
-
bambano
titán
postgresben érdekelne az év elejei agyzsibbasztás

van egy halmazom egész számokból. ezeket kellene intervallumok sorozataként felsorolni. tehát ha van 1,2,3,4,6,7,10,11, akkor kapnom kellene egy 1-4,6-7,10-11 sorozatot. -
bambano
titán
-
bambano
titán
válasz
Jimi Tudeski
#3628
üzenetére
én valami ilyesmit írnék:
select a1.* from autok a1, autok a2 where a1.rendszam<a2.rendszam and abs(a1.ar-a2.ar)<=10000;én meg sosem dolgoztam oracle-vel

-
bambano
titán
válasz
PumpkinSeed
#3478
üzenetére
én mindenre postgrest használok, abból lehet master-slave verziót. a lekérdezős frontendeket rátenném a slave-ekre, a hozzászólások posztolását meg a masterre. ha ez nem elég teljesítményben, akkor a blogokat szétültetném ilyen rendszerekből több párhuzamosra.
egy ilyesmi verziót csinálnék, neked tetsző sql adatbáziskezelővel.
-
bambano
titán
válasz
PumpkinSeed
#3476
üzenetére
"Mit értesz az alatt, hogy soha nem szokott jól sikerülni?": az ígéretek meg a valóság között időnként eltérés mutatkozhat.
én nem mondtam, hogy nosql nem jöhet szóba, én azt mondtam, hogy én elkerülném a master-master replikációt. ha valaki szereti a nosql-t, használjon azt. fenti állítás még azt sem tartalmazza, hogy te ne használj master-master replikációt
én nem tenném, de mindenki a maga szerencséjének a pogácsa. -
bambano
titán
válasz
PumpkinSeed
#3474
üzenetére
a blogolás eléggé lekérdezés-intenzív feladat, sokkal több lekérdezés megy, mint insert. szerintem egy master-több slave adatbázist érdemes használni, nagy in-memory frontendekkel. ráadásul a nyelvi korlátok miatt az adatbázis lekérdezése nem egyenletes eloszlású a földön, így ha témánként vagy témacsoportonként csinálsz egy mastert, akkor azt oda lehet tenni, ahol a többség használja.
szerk: én nem próbálkoznék master-master replikációval, az sose szokott jól sikerülni.
-
bambano
titán
postgresql-ben hogy tudnék egy stringet szétvágni 8 betű hosszúságú darabokra?
ilyen a string (csak hexa karakterek vannak benne):
FFFFFFFE00060001FFFEFFFFFFFE0002FFFFFFFEFFFF00050000FFF207FF000000020002FFFFFFFD00010002FFFCFFFBFFFFezt szeretném szétvágni táblázattá. így próbáltam:
select regexp_split_to_table(mezonev,'[0-9a-fA-F]{8}') from tablanev;üres sorokat kapok vissza. mit rontottam el?
-
bambano
titán
válasz
fordfairlane
#3178
üzenetére
jaja, ezt a szót kerestem sokáig

-
bambano
titán
válasz
fordfairlane
#3175
üzenetére
de neki a tól-ig-ja nem év, hanem gimnáziumi osztály "évadjelző" vagy hogy mondjam.
tehát 1-12 közötti szám. azt akarta megtudni, hogy milyen könyveket adhat a tizenegyedik évfolyamra járó diákoknak matekból. -
bambano
titán
válasz
MineFox54
#3173
üzenetére
mert ha az évtől és az évig varchar, akkor az évtől<='11' aposztrófosan szintaktikailag helyes.
de ha stringként hasonlítod össze a 9-et meg a 11-et, akkor mivel a 11 1-essel kezdődik, ezért az kisebb, mint a 9. ezért nem talált neked semmit. numerikusan meg a 9 a kisebb, mint ahogy te hitted.
-
bambano
titán
válasz
MineFox54
#3169
üzenetére
Postgresql:
CREATE TABLE tankonyv (evtol integer,evig integer,tantargy text);
CREATE TABLE
INSERT INTO tankonyv SELECT 9,12,'Matematika' ;
tmp=> SELECT * FROM tankonyv WHERE evtol<='11' AND evig>='11' AND tantargy='Matematika';
evtol | evig | tantargy
-------+------+------------
9 | 12 | Matematika
(1 row)
tmp=> SELECT * FROM tankonyv WHERE evtol<=11 AND evig>=11 AND tantargy='Matematika';
evtol | evig | tantargy
-------+------+------------
9 | 12 | Matematika
(1 row)
Új hozzászólás Aktív témák
- HP 255 G8 - 15.6" FullHD IPS - Ryzen 5-5500U - 8GB - 512GB SSD - Win11 - MAGYAR - ÚJ AKKU
- Erős GAMER PC + 120 Hz monitor GTX 1080 Ryzen 3300X Azonnal használható Kipróbálható
- Xiaomi Redmi Note 15 Pro 8/256GB Szinte új,Kártyafüggetlen,Dobozos,Tartozékaival. 1 Év Garanciával!
- ASUS CERBERUS GTX 1050 Ti OC 4GB
- 269 - Lenovo Yoga Pro 9 (16IAH10) - Intel Core U9 285H, RTX 5060
- Telefon felvásárlás!! Samsung Galaxy A14/Samsung Galaxy A34/Samsung Galaxy A54
- HIBÁTLAN iPhone 15 Pro 128GB Natural Titanium -1 ÉV GARANCIA - Kártyafüggetlen, MS4538
- HP ElitBook 840 G10 netbook / 12 hónap jótállás
- ÁRGARANCIA!Épített KomPhone i5 12400F 16/32/64GB RAM RTX 5070 12GB GAMER PC termékbeszámítással
- Eladó Dell Latitude 5340 i5-1345U 16 GB DDR5 Törésgarancia
Állásajánlatok
Cég: Laptopműhely Bt.
Város: Budapest

) . amit te írtál, az teljesen más. te keresnél egy számolótáblát az adatbázisban, amit nem tudok értelmezni, és azzal számolnál. ezzel szemben a postgresql (ami kikötés volt), on the fly képes sorozatokat generálni és record-setként kezelni. a hétvégéket nem modulo 7 alapján számolja, ami egyébként is lehetetlen, mert a kiinduló napnál hiába akarnál modulo7-et számolni, hanem a beépített naptár funkcióval, ahogy nyunyu is.
