Új hozzászólás Aktív témák
-
#3098
bambano
titán
Peter Kiss
#3097
bambano
titán
válasz
Peter Kiss
#3097
üzenetére
megnyugtató, hogy másik is rossz
mysql, db2 valaki? -
-
bambano
titán
postgresql 9.1
van egy táblám, így kezdődik a definíciója:
Column | Type | Modifiers
---------------------------+-----------------------------+------------------------------------------------------
id | integer | not null default nextval('service_id_seq'::regclass)
customer_id | integer |
service_type_id | integer |
date | timestamp without time zone | default now()ebbe szeretnék olyan id-vel beszúrni, ami nem az alapértelmezett, ami a serialból jön:
insert into service (id,customer_id,service_type_id) values (1,19973,11);
ERROR: currval of sequence "service_id_seq" is not yet defined in this sessionezt hogy tudom megkerülni? (értelemszerűen nincs id ütközés, nincs 1-es id-jű rekord a táblában).
kösz
-
bambano
titán
mindjárt a számra ütök, hogy ilyeneket mondok, de egy google docs is elég lehet, vagy ha ez nem jó, akkor ms felhőben bérelni egy share point portált. amennyiből egy egyetemista összekalapálna egy webes felületet ehhez, plusz a tárhelybérlet hozzá, annyiból megvan a felhő is.
-
#3001
bambano
titán
PumpkinSeed
#3000
bambano
titán
válasz
PumpkinSeed
#3000
üzenetére
milyen sql?
postgresql-nél a memóriák méretének növelése segít, illetve ha nem szabvány sql-t dumpolsz, hanem a saját dump formátumát, és akkor az gyorsabb. -
bambano
titán
válasz
bambano
#2987
üzenetére
közben az én agyam is járt, és eszembe jutott a régi jó gépikód. és kiderült, hogy van bitenkénti or aggregátor függvény.
select customer_id,bit_or(sid) from (
select customer_id, case
when service_type_id=11 then 1
when service_type_id=13 then 2
end sid from service) cc group by 1;ezt beágyazva még egy subselectbe, lehet grouppal darabszámot számolni.
kösz az ötletet, azon indultam el.
-
bambano
titán
válasz
rum-cajsz
#2984
üzenetére
nem igazán látom, hogy ez hogy is működne.
a sum(decode(jóérték))) helyett elég lenne a select count(*) where mezo=joertek, de nem ez a kérdés.
az a kérdés, hogy egy ügyfélnek egy rekordja van, ha csak egy szolgáltatásra fizet elő és kettő, ha mindkét félére.
erre kellene valami szép megoldás, mert barkács módon én is meg tudom oldani. -
bambano
titán
érdekelne a véleményetek a következő kérdésben:
postgresql
mint internet szolgáltató, statisztikáznom kell, hogy hány előfizetőm van, akinél csak tv, hány, akinél csak net és hány, akinél mindkettő van.
van egy táblám, amiben a szerződések vannak, ebben van ügyfélazonosító (customer_id) és szolgáltatás fajta azonosító (service_type_id).lehet ezt egy sql utasítással összegezni, esetleg néhány utasítással, vagy olvassam végig az egészet és programmal csináljam meg?
első körben gondoljuk végig, ha csak az számít, hogy internet, második körben azt is gondoljuk végig, ha azon belül számít, hogy melyik internet csomag.
tia -
bambano
titán
-
bambano
titán
postgres:
ezen el tudsz indulni:
select * from a, (
select id,max(timestamp) as timestamp from a group by id) as c
where a.id=c.id and a.timestamp=c.timestamp;id | value | timestamp | id | timestamp
----+-------+-----------+----+-----------
1 | 100 | 5 | 1 | 5
3 | 300 | 5 | 3 | 5
2 | 250 | 4 | 2 | 4
(3 rows) -
bambano
titán
válasz
Petya25
#2943
üzenetére
nem kötözködni akarok, de a pontos feladatmegfogalmazás sokat dobna a végeredményen
a fenti példában miért nem 4 a helyes végeredmény? van egy a->b átmenet, egy b->a átmenet, majd ugyanez mégegyszer.az eltolt soros joinolás, amit martonx kollégánk kiválóan bedobott, is 4-et adna eredményül.
-
-
bambano
titán
9-es postgresben kellene feltételes értéket visszaadni, a kérdés, hogy hogy illik ezt szépen?
ha a rekordban a status mező (char(1)):
- T,K,N, akkor akkor a rekordban tárolt másik mező tartalma legyen a végeredmény.
- S,D,V, akkor egy előre megadott string konstans
- ha B, akkor egy másik string konstans
- ha pedig a rekord egy másik mezője (boolean) hamis, akkor egy harmadik string konstans. -
bambano
titán
válasz
Iginotus
#2880
üzenetére
a másik ötlet, hogy két lépésben keresel, egyszer simán az adatokon, másodszor minden adatmező elejéről és végéről levágsz egy-egy stringet, ami olyan hosszú, mint a keresési string, ezeket megfelelően összekonkatenálod és ezen kerestetsz.
lehet, hogy erre akár egy nézettáblát is fel lehetne húzni.
-
bambano
titán
válasz
Iginotus
#2880
üzenetére
kérdés: ha olyan nagy mennyiségű adatot kell tárolnod, hogy úgyis eltöri az sql, akkor miért nem töröd a maximális mezőméret felére, és akkor tudnád konkatenálni a mezőket és simán ellenőrizni?
tehát pl. ha az ms sql 65536 bájtot tud tárolni egy mezőben (csak hasraütéssel, a példa kedvéért), és neked így kell 4 sor az adathoz, akkor miért nem veszed le a mezőméretet 32768-ra, akkor kellene 8 sor, viszont két egymás utáni sorban levő adatot egymás mellé tudnál rakni és akkor könnyen tudnál keresni.
-
-
bambano
titán
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.
-
bambano
titán
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
bambano
titán
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.
-
#2750
bambano
titán
Sk8erPeter
#2749
bambano
titán
válasz
Sk8erPeter
#2749
üzenetére
úgy látom, pgsqlnek nem jó:
ERROR: invalid input syntax for integer: " 51/g" -
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 -
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. -
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.
-
bambano
titán
válasz
Memphis
#2683
üzenetére
neked nem adatbáziskezelő programra van szükséged, mert azok csak csupasz sql kérdésekkel foglalkoznak, és azokat össze is kell álltani valakinek/valaminek.
Neked komplett ügyviteli rendszerre lenne szükséged, így érthető, hogy pár topiclakó kollegának kicsit elkerekedett a szeme a kérdésed láttán.
-
#2639
bambano
titán
dellfanboy
#2633
bambano
titán
válasz
dellfanboy
#2633
üzenetére
én a két dátum különbségét venném napban és az alapján válogatnék.
-
bambano
titán
persze, hogy nincs különbség, ha a limites átírásoddal pontosan azt a részt teszed tönkre, ami a lényegi különbség a két lekérdezés között.
próbáld ki ezt a két lekérdezést:
SELECT /*+ GATHER_PLAN_STATISTICS */ * FROM (SELECT
aru_nev,aru_egysegar FROM aruk ORDER BY aru_egysegar DESC) aruk_kivonat
where rownum < 4 ORDER BY aruk_kivonat.aru_egysegar ASCés
SELECT /*+ GATHER_PLAN_STATISTICS */ * FROM (SELECT
aru_nev,aru_egysegar FROM aruk where rownum<4 ORDER BY aru_egysegar DESC) aruk_kivonat
ORDER BY aruk_kivonat.aru_egysegar ASCez csak abban az egy esetben lehet ugyanolyan eredményű, ha az oracle képes olyan mélyen értelmezni a lekérdezést, hogy a külsö selectben használt where rownum<4 klauzát képes bevinni a belső selectbe.
adjon valaki hitelt érdemlő bizonyítékot, hogy az a query, ahol a belső select 1 millió sort ad vissza, ugyanannyi idő alatt lefut és pontosan ugyanannyira optimális, mint az, ahol a belső select csak 3 sort ad vissza.
szerk: illetve futtasd le a subselecteket önmagában és nézd meg a találati halmaz nagyságát.
-
bambano
titán
általában a window funkcióknál nem fog, ez igaz, de én nem általában írtam, hanem a konkrét megoldásra.
"egy ilyen egyszerű példában nincs különbség.": ezt az állítást nem ártott volna bebizonyítani, ebben az esetben kiderül, hogy tévedés, és nem készül belőle hozzászólás.
1 millió rekordos teszt adatbázison jól láthatóan gyorsabb a sima subselectes.
test=> explain SELECT t.aru_nev, t.aru_egysegar FROM (SELECT aru_nev,aru_egysegar, rank() OVER (ORDER BY aru_egysegar DESC) AS sorrend FROM aruk) t WHERE t.sorrend < 4 ORDER BY t.aru_egysegar;
QUERY PLAN
-----------------------------------------------------------------------------------------------------------
Sort (cost=109649.00..110482.34 rows=333333 width=36)
Sort Key: t.aru_egysegar
-> Subquery Scan t (cost=0.00..60836.36 rows=333333 width=36)
Filter: (t.sorrend < 4)
-> WindowAgg (cost=0.00..48336.36 rows=1000000 width=22)
-> Index Scan Backward using i_aru_ar on aruk (cost=0.00..33336.36 rows=1000000 width=22)
(6 rows)test=> explain SELECT * FROM (SELECT aru_nev,aru_egysegar FROM aruk ORDER BY aru_egysegar DESC LIMIT 3) AS aruk_kivonat ORDER BY aruk_kivonat.aru_egysegar ASC;
QUERY PLAN
-----------------------------------------------------------------------------------------------------
Sort (cost=0.15..0.16 rows=3 width=36)
Sort Key: aruk.aru_egysegar
-> Limit (cost=0.00..0.10 rows=3 width=22)
-> Index Scan Backward using i_aru_ar on aruk (cost=0.00..33336.36 rows=1000000 width=22)
(4 rows)time psql -d test -c 'SELECT t.aru_nev, t.aru_egysegar FROM (SELECT aru_nev,aru_egysegar, rank() OVER (ORDER BY aru_egysegar DESC) AS sorrend FROM aruk) t WHERE t.sorrend < 4 ORDER BY t.aru_egysegar;'
real 0m0.639s
user 0m0.024s
sys 0m0.016stime psql -d test -c 'SELECT * FROM (SELECT aru_nev,aru_egysegar FROM aruk ORDER BY aru_egysegar DESC LIMIT 3) AS aruk_kivonat ORDER BY aruk_kivonat.aru_egysegar ASC'
real 0m0.032s
user 0m0.024s
sys 0m0.004sha kiveszem a subselecteket és azokat hajtom végre, akkor az első megoldás visszaadja az összes rekordot, a második meg csak hármat.
Fentiek alapján melyik lekérdezés a gyorsabb, optimalizáltabb???
"egy ilyen egyszerű példában nincs különbség.": 19.93750-szeres a különbség egymillió tesztrekordon. A teszt végére még volt üres ram a gépben, tehát nem az döntött, hogy az egyiket vinyóról futtatná, a másikat memóriából, minden teszt teljesen befért a ramba.
-
#2605
bambano
titán
Apollo17hu
#2601
bambano
titán
válasz
Apollo17hu
#2601
üzenetére
vitatnám ezt a "nincs túlbonyolítva" dolgot.
te fogod a teljes táblázatot, lekérdezed, raksz mellé egy rank függvényt, minden rekordjára, meg window funkciót, stb. és visszaadod az allekérdezésből a teljes táblázatot. majd a külső lekérdezésben kiválasztod a három legnagyobbat. ehhez felhasználtál egy csomó sql dolgot, amit nem is biztos, hogy minden sql verzió támogat.ehhez képest az enyémben az allekérdezés kiválaszt három rekordot, nincs semmi elektromos csellentyűcske, és három darab rekordot ad vissza a külső lekérdezésnek rendezésre. ráadásul a három legnagyobbat index-szekvenciális kereséssel is megtalálja az adatbáziskezelő, ha van index az adott mezőre, majd a végén összesen három rekordot kezd el sorbarendezni.
futtasd már le mindkét lekérdezést egy táblán, amiben van 20 millió rekord, indexelve...
-
#2600
bambano
titán
Apollo17hu
#2599
bambano
titán
válasz
Apollo17hu
#2599
üzenetére
ez egyrészt túlbonyolítás, másrészt nem is jó válasz a kérdésre.
szerintem valami ilyesmi:
select * from (select nev,ar from aru order by 2 desc limit 3) order by 2;
-
-
bambano
titán
sokat segítene a dolgon, ha elárulnád, hogy milyen adatbáziskezelő, mert pl. a postgresben van tömb típus, így lehetne a táblázatot tömbben tárolni.
egyébként meg csinálnék külön egy általános táblázat táblát és abba tenném. minden olyan terv, ami normalizálatlan adatot gányolva akar tárolni, az csak az elején tűnik jónak, a végén rendszerint megborul.
-
#2497
bambano
titán
Sk8erPeter
#2496
bambano
titán
válasz
Sk8erPeter
#2496
üzenetére
nem én hozakodtam elő. lásd: "Észre se vettem eddig de most, hogy átraktam double-ről varchar-ra nincsenek random kinullázások."
az iróniadetektorod elemcserére szorul.
-
#2495
bambano
titán
Sk8erPeter
#2493
bambano
titán
válasz
Sk8erPeter
#2493
üzenetére
hol is kértem tőled segítséget?
-
#2492
bambano
titán
Sk8erPeter
#2489
bambano
titán
válasz
Sk8erPeter
#2489
üzenetére
vonalkódot lebegőpontos adattípusban tárolni?
-
#2428
bambano
titán
Apollo17hu
#2427
bambano
titán
válasz
Apollo17hu
#2427
üzenetére
ehhez miért kell subselect és distinct?
-
#2390
bambano
titán
Apollo17hu
#2387
bambano
titán
válasz
Apollo17hu
#2387
üzenetére
zseniális
kösz mindenkinek. -
bambano
titán
van egy táblám, egy integer azonosító mezővel meg egy dátummal. az azonosító mező nem sorfolytonos. sql-lel ki lehetne számolni az egymás utáni rekordok dátum-mezőinek különbsége összegét?
vagy mindenképpen programot kell rá írni?példa:
id | date
------+----------------------------
8222 | 2014-05-09 01:20:46.055036
8226 | 2014-05-09 01:20:50.551429
8230 | 2014-05-09 01:21:12.83294
8231 | 2014-05-09 01:21:13.20112
8234 | 2014-05-09 01:22:05.962763tehát kellene a 8234-hez tartozó dátum - a 8231-hez tartozó dátum különbsége, majd a 8231 dátuma-8230 dátuma, majd a 8230-8226 stb. és ezen differenciák összege.
ugyanezt súlyosbítva azzal, hogy a különbségeket különböző súllyal kellene figyelembe venni?
kösz a tippeket -
#2376
bambano
titán
dellfanboy
#2370
bambano
titán
válasz
dellfanboy
#2370
üzenetére
szerintem subselect
select akarmi from tabla where vevo_id in (select id from vevo where foldrajzilagrendben);
-
#2362
bambano
titán
dellfanboy
#2361
bambano
titán
válasz
dellfanboy
#2361
üzenetére
oracle-t nem tudom, de postgresql ugyanígy nevezi, pivot-nak, és betölthető extensionként van benne.
lehet, hogyha rákeresel ugyanerre oracle esetén, ott is lesz.szerk: most látom, ez sima aggregált cucc:
select id, sum(..) from table group by 1 order by 1; -
#2278
bambano
titán
Sk8erPeter
#2276
bambano
titán
válasz
Sk8erPeter
#2276
üzenetére
"nem szükséges helyettem megfogalmazgatni bármit is": rendben, akkor maradjon a te megfogalmazásod, ami egyébként helytelen.
"miért merül fel egyáltalán a para, hogy ez SQL Injectiont okozhatna": nem értem. aposztróftól nem merül fel, hogy sql injection lehetne? de, felmerül. ettől egy teljesen független kérdés, hogy az adatbáziskapcsolatod kezelése védve van-e az sql injection ellen vagy sem. ha nem ellenőrzöd az inputot ilyen ellen, akkor lemondasz a védelem egy lehetséges szintjéről.
szerk: az elképzelés, hogy nem foglalkozom az inputtal, mert a prepared statement elvileg véd az sql injection ellen, hamis biztonságérzetet ad. pláne egy olyan korszakban, amikor crontabból küldik a heti snowden dokumentet.
-
#2275
bambano
titán
Sk8erPeter
#2273
bambano
titán
válasz
Sk8erPeter
#2273
üzenetére
no, akkor megfogalmazom helyetted: azt gondolod, hogy azért félek az sql injectionra alkalmas karakterektől, mert a program többi része nincs ellene felkészítve.
"AZÉRT tiltod az aposztróf bevitelét, mert alkalmas lehetne SQL Injectionre...": igen, azért tiltom, de ez, szerintem, természetes.
-
#2274
bambano
titán
Sk8erPeter
#2273
bambano
titán
válasz
Sk8erPeter
#2273
üzenetére
attól, hogy a zseton páncélban van, még bezárom az ajtót
mondjuk az is igaz, hogy a program, amit írtam, nem széles körnek szól, de legalább kényes adatok vannak benne...
-
#2272
bambano
titán
Sk8erPeter
#2271
bambano
titán
válasz
Sk8erPeter
#2271
üzenetére
ezt a mondatodat nem teljesen értem. nem parázok az sql injectiontól, egyszerűen kitiltottam a lehetőségét is.
-
#2270
bambano
titán
Sk8erPeter
#2269
bambano
titán
válasz
Sk8erPeter
#2269
üzenetére
puhány vagy
-
#2266
bambano
titán
csabyka666
#2263
bambano
titán
válasz
csabyka666
#2263
üzenetére
Én egyáltalán nem hagyom, hogy sql injectionra alkalmas karaktert bevigyen az user. Ellenőrizni szoktam, hogy a bevitt adatban van-e ilyen karakter, és ha igen, hibát dobok. Legyen meg pontosvessző meg aposztróf nélkül.
-
#2184
bambano
titán
csabyka666
#2182
bambano
titán
válasz
csabyka666
#2182
üzenetére
de a keresendő szavakban a szóközt ne |-re cseréld, mert az nem szóköz, hanem keresd meg, hogy a te regexpedben mi a szóköz rövidítése. pl. lehet ilyen: [:whitespace:]
és akkor a találj meg keresést így kell írni:
találj[:whitespace:]meg|másik[:whitespace:]keresés|harmadikszóval vagy egyszer fűzöd össze a mezőket, és csinálsz rendes keresőkifejezést a keresendő szavakból, akkor regexp-et kell használnod.
vagy like-ot akarsz használni, akkor or-ral össze kell fűzni a kereséseket. -
#2181
bambano
titán
csabyka666
#2180
bambano
titán
válasz
csabyka666
#2180
üzenetére
miért kellene az összes előforduló sorrend?
a szavakat azért kell határoló jellel elválasztani, nehogy megtaláljon olyan rekordokat, ahol az egyik mező vége és a másik mező eleje együtt kiad egy keresendő szót.
de azon belül a sorrend mindegy, mert úgyis csak szón belüli egyezést talál.lesz egy hosszú sql kifejezésed, na és? szöszöljön vele a szerver, azért van. egyébként is a hosszú kifejezés 4-5 mélységig beágyazott subselectnél kezdődik, triggerekkel hülyítve
szerk: közben megértettem. ha így concat-tal csinálod, akkor csak egy keresendő szóra tudsz egyszerre keresni és azt utána php-ben össze kell merge-lni.
viszont ha like-ból visszatérsz az eredeti ötleted szerinti regexp-be, és ott a | az a logikai vagy, akkor jó lesz, nem kell sorrenddel foglalkozni.szerk2: tehát a végső megoldás:
concat(...) like '%keresendoszo1%' or
concat(...) like '%keresendoszo2%' or
.
.
.
concat(...) like '%keresendoszox%'; -
#2179
bambano
titán
csabyka666
#2177
bambano
titán
válasz
csabyka666
#2177
üzenetére
a te megoldáshodhoz:
lehet azt csinálni, hogy or-ral összerakod a keresőkifejezést egy keresésre, ami lehet az, hogy egy keresendő szó minden mezőre kifejtve vagy lehet egy mező minden keresőszóra kifejtve.
amit visszaad, azt beolvasod egy ciklussal tömbbe.
utána ismétled az egészet tovább, megint beolvasod tömbbe, képezed a metszetet, és ezt csinálod ciklikusan. de ez nekem nem tűnik elegánsnak. -
#2178
bambano
titán
csabyka666
#2177
bambano
titán
válasz
csabyka666
#2177
üzenetére
a dolog lényege, hogy php-ben összefaragod stringműveletekkel a keresési feltételt, és utána egy keresést futtatsz, mert ha több utasításban keresel, akkor a distinctből falra hányt borsó lesz.
azt nem értettem eddig a kérdésedben, hogy neked a keresőszót több mezőn is egyszerre kellene értelmezni, eddig azt hittem, csak egyen.
erre meg az a megoldás, hogy az adatbáziskezelővel összerakatod egy stringbe az összes mezőt, amiben keresni akarsz, és arra adod meg a kereső kifejezést.tehát ha van mondjuk egy név, egy leírás, egy gyártó meződ, akkor valahogy így:
név||'|'||leírás||'|'||gyártó like '%elsőkeresőszó%' (postgresql szintaktikával, a || a postgresben string konkatenáció)
és ebből csinálsz logikai vagy-gyal függvényt. vagy csinálni kell rá egy nézettáblát, amin keresel, az lehet, gyorsabb.
magyarul keresel egy olyan karaktert, ami biztosan nem fordul elő az adatokban, hogy elválaszd a szavakat (nekem erre a csővezetékjel a kedvenc), és az összes mező tartalmát összerakod egy stringbe ezzel a jellel elválasztva, majd ezen a stringen csinálod a like-ot. ez egy logikai kifejezés, ebből csinálsz vagy-gyal egy végső logikai kifejezést.
másik, nem annyira elegáns megoldás, ha csinálsz egy külön táblát, amibe ideiglenesen tárolod a keresések részhalmazait, csak akkor ott figyelni kell rá, hogy párhuzamos használat esetén mi lesz.
szóval egy táblába beleszórod azokat az azonosítókat, amely rekordokban az aktuális keresőszó megvan, majd csinálsz egy selectet belőle, distinct-tel, valahogy így:for i in (keresendő szavak listája sorban); do
for j in (keresett mezők listája sorban); do
sql="insert into temptabla (id) select id from tabla where $j like '%$i%';
done
done
select distinct id from temptabla;ez nyilván nem helyes program, csak egy utalás arra, hogy hogyan kellene. szerintem ez a második megoldás kicsit parasztos, de mindegy...
-
#2175
bambano
titán
csabyka666
#2174
bambano
titán
válasz
csabyka666
#2174
üzenetére
nem jól érted.
-
#2173
bambano
titán
csabyka666
#2172
bambano
titán
válasz
csabyka666
#2172
üzenetére
szerintem nem jó ötlet a php-t dolgoztatni olyan dolgokkal, amit az adatbáziskezelő helyből hatékonyan megold. tehát a keresési találatok metszetét nem php-ben kell megoldani, hanem sql szinten.
egy kósza javaslat:
select distinct id from table where mezo1 like '%akarmi1%' or mezox like '%akarmin%' ... ; -
#2170
bambano
titán
csabyka666
#2169
bambano
titán
válasz
csabyka666
#2169
üzenetére
ha emlékeim nem csalnak, akkor regexpben (igazából kérdezni kellene, hogy pontosan melyikben, mert többféle van), a | az a logikai vagy.
tehát a most|ezt|szeretném|megkeresni regexp az ennyi:
string='most' or string='ezt' or string='szeretném' or string='megkeresni'a like az csak csonkolni tud, vagyis részstringet keres, a regexp meg ennél bonyolultabbat is tud, cserébe legalább lassú.
"Ha LIKE-ot használok, az a szóközzel nem tud mit kezdeni.": miért ne tudna?
"Viszont a REGEXP-nél meg tudom azt oldani, hogy a beírt stringben lecserélem a szóközöket | jelekre, és odaadom az SQL lekérdezésnek.": igen, és a fentiek alapján ezzel teljesen más keresőkifejezést alkottál, mint ami az eredeti volt.
-
#2151
bambano
titán
kenesei1982
#2147
bambano
titán
válasz
kenesei1982
#2147
üzenetére
van magyar oracle, az nem jó?
supportot szerintem azoktól a cégektől vehetsz még, akik kompletten is supportálják az oprendszert, vagyis novell hungary, vagy ulx.hu. én ezen legutóbbival kezdeném.
szerk: esetleg keresd meg azt, aki ezt az állásajánlatot meghirdette.
-
bambano
titán
mikor legutoljára az ora.hu-tól kértem árajánlatot egy projektre, olyan számokat mondtak, hogy leestem a székről. megcsináltuk postgressel, erre elkezdtek kötözködni, hogy miért nem ora. hát azért, mert a teljes költségvetés hatszorosát kellett volna csak a db-re kiadni.
arra a feladatra, amire nekem kellett, a gyalog mysql gyorsabb volt, mint a gyalog pg, de elkezdtem behangolni mind a kettőt és a végén a pg porba alázta a mysql-t, pedig a mysql 8-as raid0-n volt, a pg meg sima diszken. akkoriban a mysql még tudott raidet, azóta ezt nem néztem.
már most tudom, mi lesz a következő néhány hsz tartalma
-
bambano
titán
válasz
martonx
#2109
üzenetére
amennyire követtem a dolgokat, normális clusterezési lehetőség csak a 9-es sorozatú pg-kben van, talán 9.3-tól. Azt nem tudom, rendes multimaster clustert lehet-e már építeni, egy master-sok slave cluster most már van.
A 8-as postgresekhez is volt külsős cluster szoftver, anno teszteltünk párat, nevetséges eredményt hozott. például ha session-id-t úgy akartál generálni, hogy volt benne random függvény is, akkor a cluster két darabján nem egyezett a két adat. now() függvény dettó. meg a tárolt procedúrákkal is baj volt.
"szerinted is"? én nem mondtam, hogy az oracle meg az mssql komolyan vehető adatbáziskezelő. az oracle tudását elismerem, de az árazása meg a ora.hu sales tevékenysége nálam több, mint kiütötte a biztosítékot.
a mysql-t nagyon régen teszteltem, lassú is volt, cserébe alap dolgokat sem tudott (ismétlem, a régi verzió), így nem foglalkoztam vele többet. meg amióta az ora felvásárolta, azóta a jövőjét elég ködösen látom.
nekem egy adatbáziskezelő van, ami komoly, a pg. minden hibája ellenére ezzel tudom legjobban megoldani a dolgaimat. (igen, van szubjektív rész is ebben a döntésben)
-
bambano
titán
válasz
sztanozs
#2106
üzenetére
A bármi az nem az ms sql express.
Te azt mondtad, hogy az ilyen express kiadásoknak lehet komoly alternatívája a pg. szerintem meg nem, fullos oracle-nek, ms sql szervernek, stb. bárminek lehet. ha meg az ora és a pg árazását hasonlítom össze... nem is kell folytatnom a mondatot. -
bambano
titán
olvasgatom ezt a remek mysql doksit, ilyenek vannak benne:
- az enumos oszlop típusa lehet string vagy int. remek.
- ha beszúrsz egy nemlétező értékkel rendelkező rekordot, akkor simán lecseréli üres stringre.
- számokat csak stringként lehet belerakni, így ha egy gyengén típusos nyelvvel kérdezed le, mint az nagy divat, akkor nem tudod eldönteni, hogy mit adott vissza az sql szerver.hát szóval lehet, hogy nem sért adatbázistervezési szabályt (egyelőre még nem találtam meg a bizonyítékot
), de hogy az implementációjától sírva kirohannék a világból, az biztos. -
bambano
titán
"Ez úgy hangzott, mintha az SQL használatával nagyságrendekkel rosszabb teljesítményt érnénk el": ez valószínűleg azért hangzott úgy, mert igaz, feltéve, hogy nem az eredeti szövegkörnyezetéből kiszakítva értelmezed a mondatot. az eredeti szövegkörnyezetben nem az volt az állítás, hogy egyik sql lekérdezés a másik sqlhez képest milyen, hanem az, hogy egy adott sql lekérdezés egy nem sql rendszerű, itt konkrétan hálós volt emlegetve, adatbáziskezelőhöz képest milyen. hát lassú.
Az eredeti mondat ez volt: "merthogy az sql masszívan nem hatékony akár a hálós adatbáziskezelőket nézed, " és igen, az sql rohadtul nem hatékony egy hálós adatbáziskezelőhöz képest, pláne, ha a lekérdezés olyan, amire a hálóst tervezték.
a személy meg a város kérdéskör meg akkor lesz érdekes, ha egy városból több személy van, pláne, ha nem egyszerre töltik be az adatokat, és akkor elkezdik a t. userek mindenféle néven illetni a településeket. ez még városoknál nem annyira nyilvánvaló, de én még nem láttam olyan adatbázist, ahol az utcaneveket képesek lettek volna egységesen írni. az meg, hogy ilyenkor nyakonvágjam a t. usert, kívánatos, de nem lehetséges megoldás
no mindegy, járod a magad útját, oszt jónapot.
Új hozzászólás Aktív témák
Hirdetés
- Kodi és kiegészítői magyar nyelvű online tartalmakhoz (Linux, Windows)
- Milyen program, ami...?
- AMD K6-III, és minden ami RETRO - Oldschool tuning
- Milyen billentyűzetet vegyek?
- Autós topik
- Sorozatok
- One otthoni szolgáltatások (TV, internet, telefon)
- Folyószámla, bankszámla, bankváltás, külföldi kártyahasználat
- Milyen belső merevlemezt vegyek?
- Béta iOS-t használók topikja
- További aktív témák...
- Easun iSolar SMW 11kW Twin Hibrid inverter // Dupla MPPT // BMS // WiFi
- GAMER PC : RYZEN 7 5700G/// 32 GB DDR4 /// RX 6700 XT 12 GB /// 512 GB NVME
- GAMER MSI LAPTOP : 15,6" 144 HZ /// i5 12450H /// 16GB DDR4/// RTX 4050 6GB/// 1TB NVME
- Manfrotto 055 magnézium fotó-videófej Q5 gyorskioldóval
- Sony ECM-W2BT
- Konica Bizhub C220 - A3 fénymásoló
- ÁRGARANCIA!Épített KomPhone i5 13400F 16/32/64GB RAM RTX 5060 Ti 16GB GAMER PC termékbeszámítással
- Olcsó laptop! Lenovo Ideapad R3 3250U / 8GB RAM / 128Gb SSD!
- ÁRGARANCIA!Épített KomPhone Ryzen 7 7800X3D 32/64GB RAM RX 9070 XT GAMER PC termékbeszámítással
- Apple iPhone 15 128GB, Kártyafüggetlen, 1 Év Garanciával
Állásajánlatok
Cég: Promenade Publishing House Kft.
Város: Budapest
Cég: PC Trade Systems Kft.
Város: Szeged