- Milyen házat vegyek?
- Viszonylag pénztárcabarát lett az AOC 280 Hz-es VA monitorja
- AMD K6-III, és minden ami RETRO - Oldschool tuning
- TCL LCD és LED TV-k
- Internet Rádió építése (hardver), és programozása
- Vezetékes FEJhallgatók
- Ventilátorok - Ház, CPU (borda, radiátor), VGA
- Telekom TV SmartBox: szolgáltatói set-top box alacsony korlátokkal
- Steam Deck
- Intel Core i5 / i7 / i9 "Alder Lake-Raptor Lake/Refresh" (LGA1700)
Hirdetés
-
Kihagyták az NVIDIA-t egy új AI-hálózati szabványból
it Számos big tech cég összefogásával készült el egy új AI-hálózati szabvány, mindebből viszont kihagyták az NVIDIA-t.
-
[SoP] Mozgásban a Concord, a Firewalk új játéka
gp A program a tervek szerint egy 5v5 felállású aréna shooternek készül továbbra is.
-
AMD Radeon undervolt/overclock
lo Minden egy hideg, téli estén kezdődött, mikor rájöttem, hogy már kicsit kevés az RTX2060...
Új hozzászólás Aktív témák
-
emitter
őstag
köszi!
mező attribútumoknál be kell állítani valamit (unsigned; unsigned zerofill; on update current timestamp), vagy hagyjam üresen?
továbbá, ha van több táblám, amelyeknél az id mező azonos lesz, csak a legelső(nek nevezett) táblában legyen primary key, a többiben foreign-key; vagy mindegyikben prim.key? És az auto_increment mire jó, hogyan működik? Végülis php-ból is inkrementálhatom a egy új bejegyzéskor az id értékét, nem?
-
Louloudaki
aktív tag
unsigned szám típusú mezőknél kell, ha biztos nem lesz negatív szám
a current timestamp dátum típusú mezőknél az aktuális dátumot veszi alapból
auto increment magától növeli a mező, pl id értékét minden új felvitelnél. de növelheted phpval is, kérdés mire jó, hogy lekérdezed az aktuális legnagyobb id-t, majd hozzáadsz egyet és úgy rögzíted az új adatokat, mikor ezt a db megcsinálja magától rövidebb idő alatt 1 lekérdezést spórolva.most ezt hogy érted, hogy több táblánál azonos az id mező? minden táblába kell egy primary key ami általában az id szokott lenni.
cucka, hasznos volt a link, köszi én is ;)
[ Szerkesztve ]
-
cucka
addikt
mező attribútumoknál be kell állítani valamit (unsigned; unsigned zerofill; on update current timestamp), vagy hagyjam üresen?
Attól függ, mire akarod használni azt a mezőt. Az unsigned azt jelenti, hogy a mezőben található számnak nincs előjele (tehát midnig pozitív), az unsigned zerofill ugyanez, csak ott a mezőben található szám elé berak annyi 0-t, ami befér. Az on update current timestamp azt csinálja, hogy amikor kiadsz egy update-et a sorra, az adott mezőbe berakja az aktuális unix timestamp-et. Tehát pl. ha valamilyen hozzászólásnál/cikknél/stb. el akarod tárolni az utolsó módosítás időpontját, akkor arra jó.továbbá, ha van több táblám, amelyeknél az id mező azonos lesz, csak a legelső(nek nevezett) táblában legyen primary key, a többiben foreign-key; vagy mindegyikben prim.key?
Az id mezőt a sorok egyszerű és gyors azonosítására használd. Ebből következik, hogy javaslom, mindegyik tábládnak legyen egy id mezője, amely primary key.
Foreign key akkor jó, amikor két tábla közötti relációról van szó. Tehát pl. van egy személy táblád, benne egy id mező. Van egy hozzászólás táblád, amiben van egy személy_id meződ. Értelemszerűen a két tábla között kapcsolat van, amit az említett mezők valósítanak meg. Ilyenkor a személy_id mezőre kell a foreign key.És az auto_increment mire jó, hogyan működik?
Az auto_increment az tulajdonképpen egy szekvenciát jelent. Kb. úgy képzeld el, mint egy változót az adatbázisodban, ami minden lekérdezésnél megnöveli 1-el az értékét.Főleg a táblák id mezőjénél használod. Beállítod az id mezőre, hogy primary key és auto_increment, ekkor minden egyes új sor beszúrásánál az id mező automatikusan egy értéket, ami szigorúan egyedi az adott mezőben és mindig nagyobb, mint az előzőleg beszúrásnál kapott érték. (Tehát az azonosítók szigorúan monoton növekvő sorozatot alkotnak)
(#503) Louloudaki
Az auto_increment php-ból történő szimulálása elsőre nagyon rossz ötletnek tűnik. A mysql által megvalósított auto_increment az atomi műveletnek számít, míg php-ból lekérdezni a legnagyobbat majd 1-et hozzáadni az nem atomi művelet.
Ha egy időben jön két ilyen kérés a szerverre, akkor a mysql megoldása működik, a php-ból megvalósítottnál pedig előfordulhat, hogy két sor ugyanazt az azonosítót kapja. (Ami primary key-nél rögtön hibát is fog jelenteni)[ Szerkesztve ]
-
emitter
őstag
válasz Louloudaki #503 üzenetére
értem, köszi.
akkor pk-nek állítom mindenhol az id-t. Az idegen kulcs mire jó? Kb. 1 éve tanultam ezt a témát, és emlékszem, h volt ilyen kulcs is, csak már nem emlékszem, mikor kellett.
szerk: most már ez is világos, thx cucka :-)
[ Szerkesztve ]
-
emitter
őstag
Ez egy szálláshely-adatbázis lesz. Ha egy adott megyére akarom majd szűkíteni a találatokat, akkor érdemes a megyéknek egy külön táblát készíteni, ahol idegen kulcs az id - vagy elég, ha a címeket tartalmazó táblában futom végig a megye-oszlopot, és keresem a megfelelő sorokat..?
-
cucka
addikt
A megyék táblája valahogy így nézzen ki
id (primary key)
nevA szálláshely tábla pedig
id (primary key)
megye_id (foreign key)
nev, leiras, stb.Megye szerinti keresésnél a szálláshely táblát fogod megye_id szerint szűrni.
(#506) Louloudaki
Azt írtad, hogy az auto_increment php-ből történő szimulálása lassabb és bonyolutabb, mint a mysql-es. Valójában a probléma nem a sebességgel vagy a bonyolultsággal van, hanem azzal, hogy a php-s megoldás alapvetően nem jó, mert két azonos időben érkező kérés esetén előfordulhat, hogy hibásan működik. Ráadásul egy bonyolult rendszerben elég csúnya dolog ilyen jellegű hibákat keresni, mert ugye hiába próbálgatod, az esetek 99.99%-ában azt fogod látni, hogy minden hibátlanul működik.
Megkereshetsz privátban, de valószínüleg csalódást fogok okozni, a látszattal ellentétben egyátlalán nem érzem magam nagy db gurunak.[ Szerkesztve ]
-
Louloudaki
aktív tag
akkor ez azt jelenti, hogy ha van egy nagy látogatottságú weboldalam, pl fórum, és 2 ember ugyanabban a tizedmásodpercben postol hsz-t ugyanabba a táblába, és ugyanabban a pillanatban egyszerre 2 sort kéne insertelni, és autoincrementes az id, akkor simán megoldja a dolgot a db, egyik id lesz 22 a másik meg 23?
-
cucka
addikt
válasz Louloudaki #509 üzenetére
Igen, ez pontosan így van.
-
emitter
őstag
még egy utolsó kérdés a szerkezethez:
ha egy szállásnak sok jellemzője van, pl. fürdő, konyha, étkezési lehetőség, sportolás, stb. akkor ezeket tegyem bele nyugodtan a 'cim' táblába, vagy csináljak nekik egy külön táblát mondjuk 'adat' névvel?csináltam külön egy 'foto' nevű táblát, amiben szállásonként 5db képet lehet tárolni, ezért van egy 'id' mezője, és 5 mező 'foto1'..'foto5' (ezek majd a képek elérési útját fogják tartalmazni). Akkor ebben a táblában az id mező csak simán pr. key, vagy foreign key a 'cim' tábla 'id' mezőjére?
-
cucka
addikt
ha egy szállásnak sok jellemzője van, pl. fürdő, konyha, étkezési lehetőség, sportolás, stb. akkor ezeket tegyem bele nyugodtan a 'cim' táblába, vagy csináljak nekik egy külön táblát mondjuk 'adat' névvel?
Tedd bele nyugodtan, minden szempontból jobban jársz így, mint ha szétdarabolnád a táblát.Akkor ebben a táblában az id mező csak simán pr. key, vagy foreign key a 'cim' tábla 'id' mezőjére?
Ahogy javasoltam, az alap, hogy minden táblában van egy id mező, ami minden esetben auto_increment és primary key tulajdonságokkal rendelkezik. Ez egyébként nem kötelező, van aki máshogy csinálja, de szerintem sokkal előnyösebb mindenhova automatikusan berakni azt az id mezőt..Először is: minden képet külön sorban tárolj. Így nem szúrsz ki magaddal, és gyakorlatilag bármely szálláshelyhez tetszőleges számú képet hozzá tudsz majd rendelni.
A fotó tábla ezek szerint:
Minden képnek van azonosítója, ugyanakkor azt is akarjuk tudni, hogy az adott kép melyik szálláshoz tartozik, ezért be kell venni a táblába a szállás_id nevű mezőt. Ez a mező foreign key, méghozzá azért, mert egy másik táblában található indexelt mezőhöz köthető. Itt konkrétan a szállás_id a szállás tábla id mezőjével van összekötve. Például az 5-ös azonosítójú szálláshelyhez a fotó táblában azok a sorok tartoznak majd, amelyeknél a szállás_id mező értéke 5.tehát a fotó tábláa szerkezete:
id (primary key, auto increment)
szallas_id (foreign key)
további mezők, amire szükséged van (elérési út, kép címe, stb.)Remélem érthető volt, ha nem, kitalálok valami példát.
-
emitter
őstag
köszi cucka, kész a struktúra
most a karakterkódolással gyűlt meg a bajom. Ahogy írtad, mindenhol utf8_general_ci-re állítottam a kódolást:
MySQL charset: UTF-8 Unicode (utf8)
MySQL connection collation: utf8_general_ci
az adatbázis, a táblák és a mezők is ugyanilyen kódolásúak.Php-ból próbaként csináltam egy insertet, a php-fájl és a weblapom utf8-as, a böngésző is felismeri - mégis pl. Bács-Kiskun helyett Bács-Kiskun az eredmény
Próbáltam a phpmyadminban mindent átállítani utf8_hungarian_ci-re, majd utf8_unicode_ci-re, semmi változás..
-
cucka
addikt
A mysql szervernek ezzel mondod meg, hogy az adatbázis kapcsolaton milyen kódolással fogja megkapni a szöveget. (Nem csak a stringeket, hanem tulajdonképpen minden input-ot)
Pl. amikor elküldöd a szervernek a "Bács-kiskun" szövegrészletet, akkor azt nem tudja automatikusan kideríteni, hogy milyen karakterkódolásban küldted, ugyanis ahogy láttad, utf8 mellett más kódolásokkal is értelmezhető az adott bináris adathalmaz.[ Szerkesztve ]
-
emitter
őstag
Amikor auto timestamp-et akarok beállítani phpmyadminnal, ezt kapom, de miért?
SQL query:
ALTER TABLE `tmp_szallas` CHANGE `frissitve` `frissitve` DATE ON UPDATE CURRENT_TIMESTAMP NOT NULL
MySQL said: Documentation
#1294 - Invalid ON UPDATE clause for 'frissitve' column -
emitter
őstag
Az indexnek (idegen kulcsnak) mi pontosan az értelme?
Dolgozom a szallas tábla adataival, ahol a szallas tábla mezői között van egy idegen kulcs a megye tábla id-jára. A megye táblában van egy 'nev' nevű mező, ez kell nekem szallas tábla feldolgozása során. Jól csinálom?
Ez akkor is működne, ha a megye_id nem lenne idegen kulcs, csak egy sima mező, nem?if ( !($tmp_result = mysql_query("SELECT nev FROM megye WHERE id=$row[megye_id]")) ) {
die("Error: " .mysql_error());
}
$megye = mysql_fetch_array($tmp_result, MYSQL_ASSOC);
$megye = $megye[nev];A másik, hogy miért nem működik az a szintaktika, hogy:
$megye = mysql_fetch_array($tmp_result, MYSQL_ASSOC)[nev];
Köszi!
[ Szerkesztve ]
-
cucka
addikt
Az indexnek (idegen kulcsnak) mi pontosan az értelme?
Bizonyos esetekben gyorsít. Olvass lejjebb.Ez akkor is működne, ha a megye_id nem lenne idegen kulcs, csak egy sima mező, nem?
Igen.
Viszont ha jól látom, azt csinálod, hogy a szállás tábla összes sorára lekéred a megye táblából az adott megye_id-hez tartozó nevet. Na ezt leginkább join-okkal szokás megoldani, mert a lényeg, hogy kevés és gyors query-t adjunk ki az adatbázisnak. Plusz itt már jól jönnek az idegen kulcsok is..Például
select szallas.id id,szallas.nev nev,szallas.cim cim,megye.nev megye_nev from szallas left join megye on (szallas.megye_id=megye.id)
Természetesen azt nem tudom, milyen oszlopaid vannak a szállás táblában, de a lényeg remélem érthető így is. Próbáld ki, nézd meg, mit kapsz eredményül.
A másik, hogy miért nem működik az a szintaktika, hogy:
Azt nem tudom, miért nem működik, de valóban nem. Igazából abban az egy sorban 4, azaz négy hiba van
1. A tömb indexei vagy számok, vagy string-ek. Nálad egyik sem, mert lemaradtak az idézőjelek ahhoz, hogy string index legyen.
2. Ha függvény visszatérési értéke tömb, akkor annak nem tudod ilyen formában elérni valamelyik mezőjét.
3. A mysql_fetch_assoc nem mindig tömbbel tér vissza, semmi nem garantálja, hogy létezik az a ['nev'] mező, amire hivatkozol. Ez esetben a minimum, hogy kapsz egy warning-ot, de valószínüleg további problémát is okozhat (mert a $megye változód így null marad)
4. A mysql_fetch_assoc függvénynek csak egy paramétere van. A második paramétert a mysql_fetch_array-nél használjuk és arra jó, hogy megmondja neki, hogy legyen indexelve az eredményül kapott tömb - számokkal, mezőnevekkel vagy mindkettővel. A mysql_fetch_assoc() ugyanezt csinálja, de kizárólag mezőnevekkel indexel.[ Szerkesztve ]
-
emitter
őstag
join:
ahogy megértettem, ez összepárosítja a szallas táblában levő megye_id-kat a megye táblában levő megyenevekkel. Akkor úgy érdemes csinálnom, hogy egyetlen egyszer join-olok, az eredményként kapott megyeneveket berakom egy php-tömbbe, amiből aztán kedvemre válogatok (aszerint, hogy az adott id-jű szálláshoz milyen megye_id tartozik?)szintaktika:
1. igen, lemaradtak az idézőjelek, bár így is működik (de javítottam). Viszont az echo"..."-ban lévő tömbindexelésnél meg csak úgy működik, ha elhagyom az egyszeres idézőjeleket, így:echo "<span style='float: left;'>$row[nev]</span>"
2. értem, azt hittem, ennek így mennie kellene...
3. javítottam az ellenőrzést
[ Szerkesztve ]
-
cucka
addikt
Join:
A join-oknak érdemes lenne utánaolvasnod, totál téves, amit írtál.
A korábbi hozzászólásomban ott volt egy sql lekérdezés. Az annyit csinált, hogy a szállás táblához hozzácsapta a megye tábla név mezőjét is. Tehát nem kell külön lekérdezned az összes megye nevét, vagy minden egyes szálláshelyre lekérni a nevet, mert annak az egy lekérdezésnek az eredményében ott lesz.
Próbáld megérteni azt a lekérdezést, cseréld ki a mezőneveket a megfelelőre és nézd meg, mi lesz az eredménye.Viszont az echo"..."-ban lévő tömbindexelésnél meg csak úgy működik, ha elhagyom az egyszeres idézőjeleket, így:
Megint csak nem jó, méghozzá azért nem, mert egybefolyik nálad a tömb indexelés szintaktikája és a stringek megadásának a szintaktikája.1. PHP-ban string-eket kétféleképpen lehet megadni: sima és dupla idézőjelekkel. A dupla idézőjeles megadás annyiban tér el a simától, hogy az abban található egyszerű változókat kiértékeli.
2. Dupla idézőjellel megadott string-ben a "komplex" változókat (pl. tömb egyik eleme, ahogy a példádban van) úgy tudod kiértékeltetni, hogy { } közé rakod.
3. Ha a tömb indexe string, akkor indexbe mindig stringként kell írni.
4. Ha egy string-be egy függvény visszatérési értékét akarod berakni, vagy egyszerűen csak sima idézőjelesen akarod megadni, akkor használj összefűzést (ez a . operátor)
5. HTML-ben az egyes elemek tulajdonságai mindig dupla idézőjelekben vannak. Tehát a példádban a <span style="float:left"> lenne a helyes.Példák a string-ed helyes megadására:
Sima behelyettesítéssel. Figyeld meg, hogy a dupla idézőjeles string-ben a dupla idézőjeleket le kell zárni a \ karakterrel. Ez sima idézőjeleknél is így van.
echo "<span style=\"float: left;\">{$row['nev']}</span>";
String összefűzéssel:
echo "<span style=\"float: left;\">".$row["nev"]."</span>";
Sima idézőjelekkel:
echo '<span style="float: left;">'.$row['nev'].'</span>';Ja, és a fentiek ellenére a te kódod is működik, csak egyrészt rossz, mert kihasználja a php gyenge ellenőrzését, másrészt ilyen stílusú kódok legtöbbször elég sok notice-t vagy warning-ot eredményeznek. Ezek ellenére a php kód le fog futni, de a jó kód az, ami nem generál ilyeneket.
[ Szerkesztve ]
-
emitter
őstag
ja, a join eléggé homály volt, most már látom
közben ráakadtam egy kis vizuális szemléltetőre, az is segített megérteni.
És köszi a tömbindexes magyarázatot is, ezt sem tudtam eddig. -
emitter
őstag
Kisméretű képeket adatbázisban érdemes tárolni? Ennek az az előnye meglenne, hogy az adatbázis lementésével a képek is mentődnének, nem kéne még külön a könyvtárukat lementeni a szerverről..
-
emitter
őstag
bocs, de elbizonytalanodtam a sztringindexekes tömböknél.. ez így helyes? A fordító elfogadja, de
$query = "INSERT INTO tmp_foto (szallas_id, fajlnev, comment) VALUES ( '$id', '{$formData['image'.$id]}', '{$formData['comment'.$id]}' )";
Vagy pedig így helyes?
$query = "INSERT INTO tmp_foto (szallas_id, fajlnev, comment) VALUES ( '$id', '{$formData['image'."$id"]}', '{$formData['comment'."$id"]}' )";
-
cucka
addikt
Mindkettő helyes, de az első talán szebb.
A lényegi különbség, hogy a tömb indexében hogyan fűzöd össze a stringeket. Igazából tökmindegy, a lényeg, hogy a végeredmény is string legyen.(#526) emitter
A képek adatbázisban való tárolásánál nem csak az az előny, hogy könnyebb lementeni. A lényeg, hogy sokkal elegánsabb, ha nem választod szét a képeket a többi adattól, mert ugye mindkettő ugyanahhoz az adatstruktúrához tartozik. További előny, hogy nehezebb hibásan megírni. File-os tárolásnál a könyvtár és filenevek generálását azért eléggé át kell gondolni, hogy ne legyen benne potenciális hibaforrás.
A hátrány, hogy bizonyos adatmennyiség fölött lassíthatja az adatbázis működését a sok blob adat, szóval ügyesen kell megtervezni.[ Szerkesztve ]
-
emitter
őstag
képek adatbázisban: tf, hogy átlagosan egy felhasználó 3 képet tölt fel (bár 10 a max megengedett, de nem fognak ennyit). Egy kép nem lehet több 200kB-nál. És kb 100-200 felhasználóm lesz maximum. Így 200*3*200k=120MB lesz a képek összmérete. Ez mennyire terheli meg az adatbázist? Most kell eldöntenem, hogy hol akarom táolni a képeket..
-
Drizzt
nagyúr
Volna két kérdésem, ami egy, de kettő.
Szóval van egy táblám, amiben volt egy szöveges érték, legyen mondjuk cím. Mostantól viszont külön címtáblában tárolnám a címet, mert lenne hozzá még vagy 5 mező. És ID alapján akarom azonosítani a címeket a korábbi címük helyett. Megcsináltam a cím táblát, be is másoltam a distinct címeket. Most viszont szeretném az eredeti táblába bevinni az id-ketz, s nem sikerül a dolog. Php mysql-queryvel próbálkozok. Kb. ilyen lekérdezéssel: először is select cim, id from cím. Aztán ennek minden során végigmegyek, s szeretném az eredeti táblát updatelni, valahogy így: update eredeti set cimid=cimid(az aktuális mysql_assoc tömb id eleme...) where cim.cim=eredeti.cim(pl.: xy utca, mert mysql fetch assocon végigmegyek...)). Namost mivel varchar van, utf8 encodinggal, ezért tök 0-kat kapok. Mi lehetne a megoldás? Próbáltam az egyenlőség helyett a like-ot is, de semmi eredmény. Vagy esetleg mysql-ből is el tudom érni a kívánt eredményt valahogy.
I am having fun staying poor.
-
cellpeti
veterán
Sziasztok!
Szeretném megtanulni a MySQL-t. Milyen könyvet ajánlotok hozzá és milyen programot?
Tigris, tigris, csóvafény...
-
Atti1112
aktív tag
Szeva mindenki ! Egy olyan kérdésem lenne : hogyan lehet megoldani ,hogyha elindítok egy programot ,akkor az a kiterjesztett (2) monitoron induljon el ? Mindig. Ötlet ? (példa : Egy wordöt elindítva az asztalról parancsikonból (1) ,mindig a másik (2) monitoron induljon el.) ? (XP sp3)
Segítsetek, ha tudtok ! Köszi !
-
Louloudaki
aktív tag
válasz cellpeti #535 üzenetére
cellpeti: google -> mysql tutorial
o'reilly sorozatból bármi ami mysql témával foglalkozik.
de ha mysqlt akarsz tanulni, kell hozzá valami szerver oldalon futó script nyelv, ami kommunikál az adatbázissal és adatokat kér le/ír be, pl phpAtti1112: ezt lehet nem itt kellett volna megkérdezni, semmi köze mysql-hez.
[ Szerkesztve ]
-
Atti1112
aktív tag
válasz Louloudaki #537 üzenetére
sorry. elnéztem a topicot Egyébként ha már ide került : tudod a választ esetleg ?
[ Szerkesztve ]
Segítsetek, ha tudtok ! Köszi !
-
Louloudaki
aktív tag
válasz Atti1112 #538 üzenetére
programot elindítod, ablakot áthúzod kettes moncsira, és ott bezárod. onnantól kezdve minden programindításkor oda fog megnyílni. nálam legalább is ezt csinálja. persze amíg át nem rakod az egyesre egyszer az ablakot és ott is zárod be, mert akkor onnantól kezdve megint oda nyílik mindig. asszem restart után is megmarad így, bár fene tudja, nem nagyon kapcsolom ki a gépemet.
-
tkazmer
addikt
lehet mysql-ben a felhasználóknak táblák helyett nézetekre adni select(vagy akármilyen) jogot?
[ Szerkesztve ]
úgy tervezték, hogy kibirjon egy atomtámadást is. De nekünk komolyabb fegyvereink vannak, mint pl Béla bá, a földmunkagépkezelő
-
Kommy
veterán
Valiki tudna nekem abban segíteni, hogy mit kéne beállítani, hogy elérjem távolról is a mysql szervert és localból is. A felállás van egy linuxos gép amin fut a mysql szerver innen be is tudok jelentkezni, van egy másik linuxos gép innen viszont nem (innen is kéne tudni írni az adatbázisba) a két gép között egy switch van látják egymást a gépek.
-
jss
aktív tag
Az volna a kérdésem, hogy ha mysql tábla létrehozásakor az adott táblában idegen kulcs van, akkor kell -e azt jeleznem, elég ha csak felveszem mezőnek és nem írom oda hogy foreign key, vagy ha ezt nem teszem meg, akkor nem lesz kapcsolat a táblák közt?
Zuhanó repülővel süllyedő hajóra esni...
-
jss
aktív tag
Az volna még a kérdésem, hogy ha azt írom, hogy increment by 25, akkor 25-ről indul a számolás, vagy 1 ről indul és 25-el nő?
Zuhanó repülővel süllyedő hajóra esni...
-
PazsitZ
addikt
ha létezik egy sor a relációban, ahol az idegen kulcsban levő attribútumok valami adott értékeket vesznek fel, akkor léteznie kell a hivatkozott relációban is egy olyan sornak, ahol a hivatkozott attribútumok értékei ugyanezek.
lekérdezésben kapcsolatot idegen kulcs nélkül is létrehozhatsz.
[link]AUTO_INCREMENT
[I]To let the AUTO_INCREMENT sequence start with another value, use the following SQL statement:ALTER TABLE Persons AUTO_INCREMENT=100
[/I]
Az egynél többel növelést nem tudom még sosem próbáltam. A SQL Server esetén ír róla, alapból nem.
[ Szerkesztve ]
- http://pazsitz.hu -
-
jss
aktív tag
illetve rosszul írtam:
AUTO_INCREMENT=20
ebben az esetben 20-tól kezdődik a számolás, vagy 20-asával számol?Zuhanó repülővel süllyedő hajóra esni...
-
jss
aktív tag
Az volna még a kérdésem, hogy ha van két tábla, az egyikben mondjuk a személyek, a másikban mondjuk az autók, az auto_id-t is és a személy_id-t is auto_increment-el állítom elő, akkor előfordulhat, hogy a két id értéke megegyezik. Ez baj, vagy ez simán lehet?
Zuhanó repülővel süllyedő hajóra esni...
-
PazsitZ
addikt
-
Kommy
veterán
Sajnos még mindig nem érem el távolról a mysql- adatbázist, kiadtam ezt a parancsot mysql -u root -p ként belépve a mysql-be :
grant all on enomalism2.* to enomal@'192.168.1.%' identified by passwd;
ezután újraindítottam a mysql daemont, és ezután kiadva a :
mysql -u enomal -h 192.168.1.121 -p enomalism2
parancsot azt kapom, hogy ERROR 1044 (42000): Access denied for user 'enomal'@'192.168.1.%' to database 'enomalism2'. Viszont ha ai ip cím helyére localhost-ot írok akkor beenged.
A my.cnf-ben beállítottam a bind_address-t 192.168.1.121-re.[ Szerkesztve ]
Új hozzászólás Aktív témák
- EVGA X570 Dark RITKASÁG!!!! 2 hetet használt.
- Beszámítás! ASUS B450M R5 3600X 16GB DDR4 240GB SSD 1TB HDD RTX 2060 6GB Rampage Shiva ZALMAN 600W
- Beszámítás! ASRock H510M i7 10700 16GB DDR4 480GB SSD RTX 3070 8GB AeroCool Aero One Seasonic 650W
- SAPPHIRE RX 6800 XT 16GB GDDR6 NITRO+ SE Eladó! 145.000.-
- Beszámítás! ASRock H510M i5 10500 16GB DDR4 240GB SSD 2TB HDD RTX 3070 8GB Rampage BE QUIET! 650W
Állásajánlatok
Cég: Ozeki Kft.
Város: Debrecen
Cég: Promenade Publishing House Kft.
Város: Budapest