Új hozzászólás Aktív témák
-
Apollo17hu
őstag
válasz csabyka666 #1440 üzenetére
főiskolai beadandó? hajrá!
-
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
-
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) -
bpx
őstag
válasz csabyka666 #1523 üzenetére
igen, de a kapcsolótáblában
-
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
[ Szerkesztve ]
-
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.)
[ Szerkesztve ]
-
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.
-
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.[ Szerkesztve ]
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...
-
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.
Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
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ő.
[ Szerkesztve ]
x gon' give it to ya
-
Apollo17hu
őstag
válasz csabyka666 #2124 üzenetére
SELECT * FROM tabla
WHERE UPPER(mezo) LIKE '%ALMA%' -
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]
-
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?
-
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.
Én kérek elnézést!
-
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.
[ Szerkesztve ]
Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
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.
Én kérek elnézést!
-
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%' ... ;Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
válasz csabyka666 #2174 üzenetére
nem jól érted.
Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
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...
Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
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.Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
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%';[ Szerkesztve ]
Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
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.Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
cacattila
csendes tag
válasz csabyka666 #2233 üzenetére
talán ilyesmire gondolsz?
[link] -
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.
but without you, my life is incomplete, my days are absolutely gray
-
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.
-
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.
but without you, my life is incomplete, my days are absolutely gray
-
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.
-
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.but without you, my life is incomplete, my days are absolutely gray
-
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.
but without you, my life is incomplete, my days are absolutely gray
-
PumpkinSeed
addikt
válasz csabyka666 #2263 üzenetére
Ez php függvény nem SQL: mysql_real_escape_string()
"Akinek elég bátorsága és türelme van ahhoz, hogy egész életében a sötétségbe nézzen, elsőként fogja meglátni benne a fény felvillanását." - Ká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.
Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
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.Sk8erPeter