Új hozzászólás Aktív témák

• #2269 Sk8erPeter nagyúr csabyka666 #2268

  Új Válasz 2014-04-06 15:08:47 #2269

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  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

  Új Válasz 2014-04-06 14:23:19 #2266

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  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

  Új Válasz 2014-04-06 10:05:57 #2264

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  PumpkinSeed

  addikt

  válasz csabyka666 #2263 üzenetére

  Ez php függvény nem SQL: mysql_real_escape_string()

• #2261 DNReNTi őstag csabyka666 #2260

  Új Válasz 2014-04-01 23:05:16 #2261

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  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

  Új Válasz 2014-04-01 22:57:34 #2259

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  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

  Új Válasz 2014-04-01 22:38:28 #2256

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  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

  Új Válasz 2014-04-01 22:36:15 #2255

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  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

  Új Válasz 2014-04-01 22:22:43 #2253

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  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

  Új Válasz 2014-04-01 21:32:04 #2251

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  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

  Új Válasz 2014-03-30 23:43:29 #2234

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  cacattila

  csendes tag

  válasz csabyka666 #2233 üzenetére

  talán ilyesmire gondolsz?
  [link]

• #2184 bambano titán csabyka666 #2182

  Új Válasz 2014-03-12 16:54:04 #2184

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  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|harmadik

  szó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

  Új Válasz 2014-03-12 16:04:20 #2181

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  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

  Új Válasz 2014-03-12 14:53:10 #2179

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  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

  Új Válasz 2014-03-12 14:48:59 #2178

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  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

  Új Válasz 2014-03-12 11:54:56 #2175

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  bambano

  titán

  válasz csabyka666 #2174 üzenetére

  nem jól érted.

• #2173 bambano titán csabyka666 #2172

  Új Válasz 2014-03-12 11:47:12 #2173

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  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

  Új Válasz 2014-03-12 07:28:11 #2171

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  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

  Új Válasz 2014-03-11 23:29:26 #2170

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  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

  Új Válasz 2014-03-11 22:34:33 #2167

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  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

  Új Válasz 2014-03-11 21:41:09 #2166

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  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

  Új Válasz 2014-02-20 21:23:27 #2126

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  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

  Új Válasz 2014-02-20 21:16:28 #2125

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Apollo17hu

  őstag

  válasz csabyka666 #2124 üzenetére

  SELECT * FROM tabla
  WHERE UPPER(mezo) LIKE '%ALMA%'

• #2052 fordfairlane veterán csabyka666 #2049

  Új Válasz 2014-01-17 18:05:13 #2052

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  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

  Új Válasz 2014-01-17 17:55:35 #2050

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  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

  Új Válasz 2014-01-17 17:44:28 #2048

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  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.

  [link]

• #2035 Apollo17hu őstag csabyka666 #2034

  Új Válasz 2014-01-10 22:44:10 #2035

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  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

  Új Válasz 2014-01-10 21:08:47 #2033

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  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

  Új Válasz 2012-12-31 13:27:02 #1526

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  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

  Új Válasz 2012-12-31 13:20:00 #1524

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  bpx

  őstag

  válasz csabyka666 #1523 üzenetére

  igen, de a kapcsolótáblában

• #1522 bpx őstag csabyka666 #1521

  Új Válasz 2012-12-31 13:14:42 #1522

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  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 kulcsa

  2. 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

  Új Válasz 2012-12-31 12:07:47 #1520

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  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

  Új Válasz 2012-11-28 22:59:45 #1441

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Apollo17hu

  őstag

  válasz csabyka666 #1440 üzenetére

  főiskolai beadandó? hajrá!

Új hozzászólás Aktív témák