- iPhone topik
- Samsung Galaxy Watch (Tizen és Wear OS) ingyenes számlapok, kupon kódok
- Milyen okostelefont vegyek?
- Mobil flották
- MIUI / HyperOS topik
- Vivo X200 Pro - a kétszázát!
- Xiaomi 15 Ultra akku probléma?
- Samsung Galaxy A54 - türelemjáték
- Samsung Galaxy Watch6 Classic - tekerd!
- Eltűnhet a Dinamikus Sziget
Új hozzászólás Aktív témák
-
#2269
Sk8erPeter
nagyúr
csabyka666
#2268
Sk8erPeter
nagyúr
válasz
csabyka666
#2268
üzenetére
Eleve rossz a megközelítésed, ilyet SOHA nem csinálunk, nem konkatenálunk query-t változókkal, prepared statementeket használunk, ahogy a PHP topicban neked már vagy hússzor leírtuk, és a probléma meg van oldva.
(#2266) bambano :
Őő, hát azért az aposztróf vagy épp idézőjel karakter talán nem egy olyan extra karakter, ami miatt hibát kéne dobni a felhasználónak... lásd épp az említett példát. -
#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.
-
#2264
PumpkinSeed
addikt
csabyka666
#2263
PumpkinSeed
addikt
válasz
csabyka666
#2263
üzenetére
Ez php függvény nem SQL: mysql_real_escape_string()
-
#2261
DNReNTi
őstag
csabyka666
#2260
DNReNTi
őstag
válasz
csabyka666
#2260
üzenetére
Akkor jó hírem van: jól csináltad. Az adatbázis pedig azért nem engedi a már emlegetett parancsokat mert a kulcskapcsolat az üres táblákra is érvényes. Például kitörölnéd a felhasznalok táblát, akkor mit vinnél fel a kapcsolati táblába. Egyébként ebben az egyszerű példában, ha először a kapcsolati táblát törlöd, akkor megszűnnek a kulcskapcsolatok, így törölhető / kiüríthető lesz a többi is.
-
#2259
DNReNTi
őstag
csabyka666
#2257
DNReNTi
őstag
válasz
csabyka666
#2257
üzenetére
azt gondoltam, hogy én állítottam be valamit rosszul
Megint azt tudom írni, attól függ mi a cél.
Külső kulcsot akkor használsz amikor egy másik tábla elsődleges kulcsára akarsz mutatni, ez egy szigorú megszorítás, az adatbázis csak meglévő értéket enged ide felvinni. Jó példa mondjuk egy bármilyen (1:1, 1:n, n:m) kapcsolati tábla. A legegyszerűbb példa hogy érthető legyen:
3 táblád van: felhasznalok, hozzaferes_szintek, felhasznalok_hozzaferese.
Itt a kapcsolati tábla a felhasznalok_hozzaferese összesen két mezővel: felhasznalo_id és hozzaferes_szint_id, mindkettő külső kulcs. Ez tipikus, egyszerű esete a külső kulcs használatának, hogy visszatérjek az eredeti gondolathoz, ha ilyesmire használod, akkor jól használod.
-
#2256
jocomen
aktív tag
csabyka666
#2254
jocomen
aktív tag
válasz
csabyka666
#2254
üzenetére
Lehet, h többgyerekes?
Közvetett hivatkozás?Ha a kapcsolat kiiktatásával törölsz, és nem minden táblát, azaz valamelyikben marad hivatkozás, akkor ha visszarakod a kapcsolatot, szerintem azért is hibát dob. Nem vagyok biztos, h ilyenkor nullázódik a kulcs.
-
#2255
DNReNTi
őstag
csabyka666
#2252
DNReNTi
őstag
válasz
csabyka666
#2252
üzenetére
Nem is egészen értem pontosan mi is a cél. Jobban mondva a célt értem, csak azt nem miért van rá szükség. Egyébként egy tipp: én minden táblában használok egy "active" nevű mezőt. Ez mindig az utolsó, boolean, default: 1. Minden lekérdezésben szerepel a WHERE active = 1; tehát ha "törölni" akarok egyszerűen csak inaktiválom azt a rekordot, és az "megszűnik" létezni az oldal számára. Lehet csak az én hülyeségem, de szerintem adatbázisból törlést kerülni kell amennyire lehet. Hozzáteszem: éles oldalaknál, amíg tesztelsz és telehányod sallanggal az adatbázist akkor persze érdemes legyalulni. Erre pedig a tökéletes módszer ha exportálod csak a struktúrát, eldobod az összes táblát, majd importálod a struktúrát. Lehet van erre szebb megoldás, ha van, engem is érdekel.
-
#2253
jocomen
aktív tag
csabyka666
#2250
jocomen
aktív tag
válasz
csabyka666
#2250
üzenetére
Lehet félreértem a problémát, de ez nem az, h nem törölhetsz a szülőtáblából, amíg a gyerektáblában van rá hivatkozás? Azaz fordított sorrendben tudod törölni.
Ha fontos, h nullázódjon az id, akkor én kiíratnám scriptbe, és azzal hoznám létre újra az adatbázist.
-
#2251
DNReNTi
őstag
csabyka666
#2250
DNReNTi
őstag
válasz
csabyka666
#2250
üzenetére
A DROP sem működik ha kulcskapcsolatok vannak a táblák között. A FOREIGN_KEY_CHECKS ki (és be) kapcsolása működő módszer, ha favágó ha nem, de én csak teszteléskor használom, pl ha ki kell nullázzak egy adatbázist, vagy csak néhány táblát. Nem véletlen nem működik se a DROP, se a DELETE se a TRUNCATE, így ezt egy éles oldalon felejtsd el.
Kulcskapcsolatok okkal vannak egy adatbázisban. -
#2234
cacattila
csendes tag
csabyka666
#2233
cacattila
csendes tag
válasz
csabyka666
#2233
üzenetére
talán ilyesmire gondolsz?
[link] -
#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%' ... ; -
#2171
martonx
veterán
csabyka666
#2169
martonx
veterán
válasz
csabyka666
#2169
üzenetére
én csak a példa kedvéért írtam a like-ot, nem azon volt a hangsúly, hanem az egymásba ágyazott vagy-okon és-eken.
-
#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.
-
#2167
martonx
veterán
csabyka666
#2165
martonx
veterán
válasz
csabyka666
#2165
üzenetére
Valami ilyemi kellene, hogy legyen a keresési feltételed:
WHERE
(feltétel1 nem üres OR mező1 like feltétel1)
AND (feltétel2 nem üres OR mező2 like feltétel2)
AND (feltétel3 nem üres OR mező3 like feltétel3)
...Már ha jól értettelek.
-
#2166
Apollo17hu
őstag
csabyka666
#2165
Apollo17hu
őstag
válasz
csabyka666
#2165
üzenetére
A 4 mezőben keresel azt jelenti, hogy a felhasználó max. 4 szót adhat meg szűkítésnek? Szerintem a keresők nem ezen az elven működnek, de ha te így szeretnéd, akkor talán az AND mégis használható lenne, ha REGEXP helyett LIKE '%keresés%' jellegű kifejezéseket vizsgálnál. Amúgy a REGEXP honnan jött? Miben jobb a LIKE-nál a lekérdezésedben?
-
#2126
bpx
őstag
csabyka666
#2124
bpx
őstag
válasz
csabyka666
#2124
üzenetére
Van ugye a "where lower(oszlop) like '%alma%'" modszer, de ha valami okosabb kell, akkor vannak erre RDBMS-specifikus eszkozok, pl. [link]
-
#2125
Apollo17hu
őstag
csabyka666
#2124
Apollo17hu
őstag
válasz
csabyka666
#2124
üzenetére
SELECT * FROM tabla
WHERE UPPER(mezo) LIKE '%ALMA%' -
#2052
fordfairlane
veterán
csabyka666
#2049
fordfairlane
veterán
válasz
csabyka666
#2049
üzenetére
Ha az áruház nevéből indulsz, és a termék(ek) nevéhez akarsz elérkezni, akkor szükséged lesz mind a három táblára. Három táblát meg két JOIN-nal tudsz összekapcsolni. (Nem mostanában volt pont ugyanerről téma errefelé?)
SELECT termek.nev
FROM termek
(INNER) JOIN kapcstabla
ON termek.id = kapcstabla.termekid
(INNER) JOIN aruhaz
ON aruhaz.id = kapcstabla.aruhazid
WHERE aruhaz.nev = "nagyesszep";Vagy valami ilyesmi. Ez csak két equi-join, semmi nagy varázslat.
Szerk: Az INNER-t azért tettem zárójelbe, mert opcionális. Vagy SQL kiszolgálófüggő.
-
#2050
bambano
titán
csabyka666
#2047
bambano
titán
válasz
csabyka666
#2047
üzenetére
ahhoz, hogy lásd ennek a célját, érdemes először alaposan elolvasni a Chomsky-féle normálformákat.
-
#2048
sztanozs
veterán
csabyka666
#2047
sztanozs
veterán
válasz
csabyka666
#2047
üzenetére
Ebből azt tudom majd megmondani, hogy egy adott termék mely áruházakban van, illetve fordítva, vagyis hogy egy adott áruházban milyen termékek vannak? Tehát ennyi lenne a kapcsolótábla szerepe?
Igen, mivel egy rekord egy mezője csak egy elemet tartalmazhat (logikailag), így a
[tábla 1] n:m [tábla 2]
kapcsolatot fel kell bontanod:
[tábla 1] 1:m [kapcsoló tábla] n:1 [tábla 2]
formára. -
#2035
Apollo17hu
őstag
csabyka666
#2034
Apollo17hu
őstag
válasz
csabyka666
#2034
üzenetére
Nagyvonalakban ezek az infóid vannak:
felhasználó | felhasználói infók (több mező) | termék | termékinfók (több mező)
Azt írod, hogy nincs két ugyanolyan termék (-> különböző vonalkódok). Ha így van, akkor szerintem felesleges a kapcsolótábla. Az egész mehetne egy táblába. Annyit lehetne normalizálni rajta, hogy a felhasználóknak külön táblát hozol létre, amibe minden felhasználói infót letárolsz, a másik táblában pedig elég csak felhasználóazonosítót használnod.
-
#2033
Apollo17hu
őstag
csabyka666
#2032
Apollo17hu
őstag
válasz
csabyka666
#2032
üzenetére
Én úgy csinálnám, hogy a meglévő adatok alapján felvinném az összes felhasználót a felhasználó táblába, az összes terméket pedig a termék táblába (mindenkit és mindegyiket csak egyszer).
Nem tudom, hogy hívják magát a "feltöltést", de hasonló esetben én a tranzakció kifejezéssel találkoztam. Tehát van egy halom tranzakciód, ami tartalmazza, hogy ki, mit és mikor töltött fel. Ezeket kell a kapcsolótáblába felvinni. (felhasználó egyedi azonosítója + termék egyedi azonosítója + feltöltés dátuma)
Innentől kezdve csak a kapcsolótáblát töltöd. Akkor kell a másik kettőhöz hozzányúlnod, ha új felhasználó vagy új termék jelenik meg egy tranzakcióban. (Ez esetben a felhasználó- és/vagy a terméktáblát kell előbb kiegészíteni.)
-
#1526
bpx
őstag
csabyka666
#1525
bpx
őstag
válasz
csabyka666
#1525
üzenetére
itt egy példa táblákkal, egy olyan alkatrésszel, ami 3 autóba is beépíthető
alkatrész
---------
cikkszám | alk_név | ...
---------------------------------
1 | féktárcsa | ...
2 | ablaktörlő | ...
autó
----
típusnév | gyártott_db | ...
---------------------------------
Audi | 10000 | ...
Suzuki | 50000000 | ...
Trabant | 10000000 | ...
kapcsolótábla
-------------
cikkszám | típusnév |
-----------------------------
1 | Audi |
1 | Suzuki |
1 | Trabant |
2 | Audi |szerk: javítottam mert a PH! máshogy értelmezi a tabokat
-
#1524
bpx
őstag
csabyka666
#1523
bpx
őstag
válasz
csabyka666
#1523
üzenetére
igen, de a kapcsolótáblában
-
#1522
bpx
őstag
csabyka666
#1521
bpx
őstag
válasz
csabyka666
#1521
üzenetére
1. konkrétan Access-ben fogalmam sincs, nem használok Access-t
nyilván lesz az autó és alkatrész tábla az ábrán látható oszlopokkal és elsődleges kulcsokkal
lesz a kapcsolótábla, amiben idegen kulcs a másik 2 tábla elsődleges kulcsa2. kelleni semmit se kell
autót és alkatrészt is lehet felvenni a kapcsolótábla piszkálása nélkül
az autó és alkatrész tábla között nincs közvetlen kapcsolat
és a diagram szerint nem kötelező, hogy minden alkatrészhez tartozzon autó és fordítva sem (hiszen a * az lehet 0 is) -
#1520
bpx
őstag
csabyka666
#1519
bpx
őstag
válasz
csabyka666
#1519
üzenetére
"ha fel akarok venni egy alkatrészt, akkor meg kell adnom a kapcsolótábla "típus_név" mezőjét is, és így jelölöm, hogy milyen autóba passzol"
erre van a kapcsolótáblád, amit az alkatrész felvétele után tudsz beállítani
-
#1441
Apollo17hu
őstag
csabyka666
#1440
Apollo17hu
őstag
válasz
csabyka666
#1440
üzenetére
főiskolai beadandó? hajrá!
![;]](//cdn.rios.hu/dl/s/v1.gif)
Külső kulcsot akkor használsz amikor egy másik tábla elsődleges kulcsára akarsz mutatni, ez egy szigorú megszorítás, az adatbázis csak meglévő értéket enged ide felvinni. Jó példa mondjuk egy bármilyen (1:1, 1:n, n:m) kapcsolati tábla. A legegyszerűbb példa hogy érthető legyen:
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Új hozzászólás Aktív témák
Hirdetés
- Így nézz tévét 2025-ben: új ajánlások, régi szabályok
- AliExpress tapasztalatok
- Autós topik látogatók beszélgetős, offolós topikja
- Nagyrobogósok baráti topikja
- Mielőbb díjat rakatnának a görögök az olcsó csomagokra az EU-ban
- AMD K6-III, és minden ami RETRO - Oldschool tuning
- Milyen autót vegyek?
- Kezdő fotósok digitális fényképei
- iPhone topik
- GTA V
- További aktív témák...
- Xbox Series S + 2 kontroller
- Dell laptop eladó i5 11. gen, 8GB RAM, 512GB SSD, újszerű állapotban!
- Bomba ár! HP EliteBook Folio 1040 G1 - i5-G4 I 8GB I 256GB SSD I 14" HD+ I Cam I W10 I Garancia!
- Bomba ár! HP Elitebook Folio 9470M - i5-3GEN I 8GB I 256GB SSD I 14" I DP I Cam I W10 I Garancia!
- Bomba ár! Dell Latitude 5430 - i7-1255U I 16GB I 512SSD I HDMI I 14" FHD I Cam I W11 I NBD Garancia!
- Felújított számítógépek/merevlemezek Számlával, garanciával! Ingyen Foxpost!
- BESZÁMÍTÁS! Asus B760M i7 12700KF 32GB DDR4 512GB SSD RX 6800 16GB Rampage SHIVA FSP 700W
- Nvidia Quadro P400/ P600/ P620/ P1000/ T400/ T600/ T1000 - Low profile (LP) + RTX A2000 6/12Gb
- Canon imagePrograf PRO-6100S plotter - szinte új, 500m2 nyomat
- AKCIÓ! Lenovo Legion Slim 5 16AHP9 notebook - R7 8845HS 16GB RAM 512GB SSD RTX 4060 8GB Win11
Állásajánlatok
Cég: CAMERA-PRO Hungary Kft
Város: Budapest
Cég: Promenade Publishing House Kft.
Város: Budapest