Máshonnan közelíteném meg a problémát:

Miért is kell ezt tárolni? Gyakorlatilag duplikálod az adatot, emellett az idő nem áll meg, így folyamatosan frissíteni kellene az adatbázist.

MCTS: .NET Framework 4, Web applications | <?php die('hard'); ?>

OK.Elfogadom.Csak azt mondjátok meg nekem,hogy érem el,hogy mondjuk óránként frissíti a mysql ezt:
UPDATE e107_user_extended SET user_kora=floor(DATEDIFF(now(),user_birthday)/365.2425);

vagy hogy kapcsolhatom egy meglévő php fájlhoz(ami sokszor kapcsolódik az adatbázishoz)

1: eleg naponta frissiteni
2: csinalsz egy script-et (lehet php is), ami kapcsolodik a db-hez es futtatja a query-t, majed ezt a script-et meghivod cron-nal (linux-on), vagy feladatutemezovel (windoze-on)
3: nem lenne jobb megoldas select-nel szamitani az eletkort (amikor nagyon muszaj)?

[ Szerkesztve ]

Politikailag korrekt, valamint munkahely- és gyermekbarát aláírás, amiben egyáltalán nincsen p*na.

Talán kaphatnék egy egyszerű kódot,amit a feladatütemezővel naponta lefuttathatok.
Az adatbázis neve e107
a tábla neve: e107_user_extended
A mező neve:user_kora
Felhasználó név: e107
Jelszó:e107
Host:localhost

Sziasztok az alábbi hibára mi a megoldás?

Database error: Invalid SQL: select * from general_setting
MySQL Error: 1146 (Table 'talan999.general_setting' doesn't exist)

Host : 127.0.0.1
Database : talan999
User : talan999
Session halted.
Warning: Unknown: open(/tmp/sess_a5c72e1b6147b5d183925d391bcae7b0, O_RDWR) failed: No such file or directory (2) in Unknown on line 0

Warning: Unknown: Failed to write session data (files). Please verify that the current setting of session.save_path is correct (/tmp) in Unknown on line 0

Egyrészt a "general_setting" tábla nem létezik, másrészt valószínű a session kezelés is rosszul van beállítva.

Gyógyíthatatlan betegség: a "duál kór" -- Sas húsz, foksz kettő!

Tudnál nekem segíteni részletesen, mert nem nagyon foglalkoztam még ilyennel!?

Sziasztok,

PHP-MySQL környezetben:
Egy túlóramodell kialakítására törekszem, amiben kérnék egy kis segítséget:

Eddig erre jutottam:

1.
Munkarend( dolgozó_id, hónap, százalék) tábla
tehát ennek pl. egy olyan sora, hogy (10, 2011-01, 100) azt adná meg, hogy Józsi bácsi 2011 januárjában teljes munkaidőban, azzaz napi 8 órában dolgozott.

2.
El kellene tárolni az egyes naptári évek napjait és azt a tulajdonságukat, hogy munkanapok-e.
Ezt még nem tudom hogyan tároljam el.
Az egyik lehetőség ami az eszembe jutott, hogy minden naptári évhez létrehoznék egy táblát, aminek 365 vagy 366 sora lenne, a napoknak megfelelően.

A túlóraszámítás útgy történne, hogy egyenleg= havi jelenetett munkaidő(már kész van) -
a kötelező munkanapok száma*hány százalékos munkaidőben dolgozik az adott dolgozó.

Az adott naptári évek tárolásában szeretnék segítséget kérni, hogy hogyan lehetne ezt a legszebben és redundanciamentesen megvalósítani?

Köszönettel,
W.

Látom ide is beírtad a kérdésedet... Felejtsd már el ezt az ütemezett életkor-update-elést, egyszerűen amikor kíváncsi vagy a felhasználó életkorára, számítsd ki a születési dátumából minden alkalommal, amikor megjeleníted, ez úgyis villámgyors, ne szenvedj már a totál megbízhatatlan ütemezéssel... (korrigálom magam: az ütemezés maga nem feltétlenül megbízhatatlan, de ha mégis kimarad valamilyen oknál fogva (pl. valaki kiszedi az ütemezett feladatok közül, épp volt egy áramkimaradás az ütemezés időpontjában, mittudomén stb.), akkor máris szar értéket jelenítesz meg, ahelyett, hogy a mindig naprakész automatikus kiszámítást végeznéd el)

Szerk.: még szerkesztési időn belül találtam erről szóló topicot: [link]
itt a kérdező nem tudom, mit szenved azzal a query-vel, mit gányolgat, de utána megmondja a megoldást, hogy valami usershortcodes.php fájlba kell tenni ezt a kódrészletet, gondolom neked megfelelően átalakítva, ha kell, nekem személy szerint fingom sincs, mi ez, soha nem használtam e107-et, és hacsak nem nagyon muszáj, nem is fogok.

Szerk. 2.: van itt valami Birthday Menu is, ahol állítólag csak be kell pipálni egy checkboxot ("Show age"), és máris ott lesz neked az életkor... Akkor minek szórakozol saját megoldásokkal, ami rossz?

[ Szerkesztve ]

Sk8erPeter

+1

flickr.com/blackdogone [+] XBL: bldone [+] "The parasite makes nothing for itself. Its only tools are taxes and tithes meant to trick you into offering what it has not earned. In Rapture we keep what is ours." [+] 

Nem hiszem, hogy így látatlanban, mindenféle körülmények leírása nélkül fogja neked tudni bárki is, hogy mit kellene tartalmaznia a general_setting tábládnak, de először is létre kéne hozni...
Másrészt a /tmp könyvtár nem elérhető vagy nem írható a webszerver számára, állítsd át php.ini-ben a session.save_path értékét, vagy adj rá írási jogokat, már amennyiben saját rendszeredről van szó, és/vagy hozzáférsz a beállításokhoz.
Na meg kicsit részletesebben számolj be a problémádról.

Szerk.:
(#2011) bLaCkDoGoNe : hogy a helyzetet súlyosbítsam, ezek után még priviben is próbálkozott ugyanezzel, 0 előrehaladással, de mentségére szóljon, hogy állítólag utána valahogy megoldotta. Mondjuk sanszos, hogy azt is külső segítséggel.

[ Szerkesztve ]

Sk8erPeter

1.) itt a százalék helyett miért nem valami jobban kalkulálható egységgel dolgozol? Például a meló mértéke lehetne inkább óra egységben megadva: adott hónapban X órát dolgozott. Persze ettől függetlenül lehetne pluszban egy mező, hogy ez most 100%-ot, vagy 432%-ot jelent, bár lehetne ezt is másképp megoldani, ez már egyéni döntés kérdése.

2.) hmm, itt most gyorsan átfutva nem jut eszembe hirtelen más, mint hogy minden naptári napot eltárolni - tulajdonképpen muszáj, hiszen minden napra más adat vonatkozik.
Mivel minden naptári naphoz tartozhat általános, mindenkire érvényes adat is, esélyes, hogy egy külön táblában kellene tárolni a naptári napokat,és ezek id-jaihoz kapcsolni az egyes dolgozók napokra lebontott adatait. Szerintem csak így tudsz minden adatot jól követhetően tárolni, hogy minden évre, napra, dolgozóra rá lehessen külön keresni, és viszonylag általános legyen a szerkezet. Még ha sok adat is lesz ezzel, több táblában, és dolgozónként hivatkozni kell a naptári napok id-jaira az év összes napján...
Nem kell minden évnek külön tábla, egy szerintem elég, ahol az összes naptári nap szerepel, aztán lehet, hogy van erre megfelelő ellenérv. De ilyen esetben mindenképp érdemes szerintem különbontani a dátum egyes adatait, tehát akár évet, hónapot, napot, bizonyos dátum szerinti kereséseknél tudtommal ez hatékonyabb is lehet, mert nem kell mindig dátumkonverziós függvényeken keresztülverni az egész dátumot.

Most nem gondoltam végig minden lehetőséget, tehát remélem még valaki hozzátesz a gondolatmenethez.

Egyébként ez igazából szimpla SQL-kérdés, semmi köze a PHP-hoz, nyugodtan mehetett volna az SQL-kérdés topicba, ott talán többen is látják, azok is, akiket a PHP nem érdekel, de vágják az SQL-t (és követik a topicot). Tulajdonképpen nem tudom, melyik a látogatottabb topic.

Sk8erPeter

Mi lenne akkor, ha nem tárolnád el egy adott év összes napját, hanem csak a munkaszüneti napokat tárolnád el minden hónapra? (Lehet, hogy félreértettem a metódusodat, és ez így nem elég neked.)

flickr.com/blackdogone [+] XBL: bldone [+] "The parasite makes nothing for itself. Its only tools are taxes and tithes meant to trick you into offering what it has not earned. In Rapture we keep what is ours." [+] 

Na igen. Ha így csinálná, akkor nem lenne kérdés, mi legyen a flag arra vonatkozóan, hogy munkanapról van-e szó, vagy sem. Szerintem is ez lenne a jó, erre el is felejtettem előbb válaszolni.

Sk8erPeter

adatbázis probléműma ütköztem ha valaki esetleg tud segítsen.

$forum_msgs= mysql_query("SELECT * FROM forum_msgs"); -> így működik a kód, ezzel a probléma hogy nem úgy rendezi ahogy én szeretném.

de ha már átírom erre:
$forum_msgs= mysql_query("SELECT * FROM forum_msgs ORDER BY forum_msgs.datum"); akkor egyből hibát dob az utána következő részre:

while($sor=mysql_fetch_array($forum_msgs)){
$hozzaszolt=$sor['forum_msgs.user'];
$datum=$sor['forum_msgs.datum'];
$uzenet=$sor['forum_msgs.msg'];
$nev=$sor['forum_msgs.topic'];

*a hibaüzenet alapján arra következtettek hgoy rossz a mysql lekérdezésem, valaki kitudná nekem javítani? sajnos már minden lehetőséget kimerítettem ami eszembe jutott

[ Szerkesztve ]

"Amikor már azt hittem kint vagyok, ezek mindig visszarántottak..." PSN ID: szecsi28 || GT5 && Bf BC2

Csak a hibaüzenet maradt el.

MCTS: .NET Framework 4, Web applications | <?php die('hard'); ?>

ha fetch_array-t hasznalsz, akkor a $sor tombod elemeit sorszamozva ered el
ha mezonev alapjan szeretned, akkor hasznald a fetch_assoc fgv-t (bar azt hiszem, a tablaalias-t akkor sem teszi oda)

szerk.: tevedtem, alapertelmezeskent a fetch_array is visszaadja a mezoneveket (is), mint tombindex

[ Szerkesztve ]

Politikailag korrekt, valamint munkahely- és gyermekbarát aláírás, amiben egyáltalán nincsen p*na.

A lekérdezésed jó. (már amennyiben létezik a "datum" mező a forum_msgs táblában, de feltételezem, létezik)
A PHP-kódnál viszont nem kell oda a forum_msgs, tehát ehelyett:

$hozzaszolt=$sor['forum_msgs.user'];
$datum=$sor['forum_msgs.datum'];
$uzenet=$sor['forum_msgs.msg'];
$nev=$sor['forum_msgs.topic'];

próbáld ezt:

$hozzaszolt=$sor['user'];
$datum=$sor['datum'];
$uzenet=$sor['msg'];
$nev=$sor['topic'];

Sk8erPeter

félre érted, ez pl. a rekordom neve "forum_msgs.datum", de köszi így sikerült rájönnöm a hibára

$forum_msgs= mysql_query("SELECT * FROM forum_msgs ORDER BY forum_msgs.forum_msgs.datum");

így kell kinéznie a lekérdezésemnek, kicsit csúnya, csak szeretem pontosan tudni hogy mi melyik tábla dátuma pl.

[ Szerkesztve ]

"Amikor már azt hittem kint vagyok, ezek mindig visszarántottak..." PSN ID: szecsi28 || GT5 && Bf BC2

bocsánat helyesbítek

*a mező neve "forum_msgs.datum"

de még1x köszönöm, sikerült is megcsinálni

"Amikor már azt hittem kint vagyok, ezek mindig visszarántottak..." PSN ID: szecsi28 || GT5 && Bf BC2

én is erre jutottam, köszönöm.

én is erre jutottam, köszönöm.

Tehát magyarul van egy forum_msgs táblád, és azonbelül a datum mező neve nem simán datum, hanem forum_msgs.datum?
Hát eléggé felesleges, hogy az adott nevű tábla mezőit kiegészíted a táblanév+mezőnévvel, és magunktól nehéz lett volna kitalálni, hogy ilyen rossz szokásokat alkalmazol, amíg le nem írod.
Én azt javasolnám, inkább erről szokj le, de persze egyéni döntés.
Nincs mit!

(#2023) wolandino :
szívesen, de mire jutottál?

[ Szerkesztve ]

Sk8erPeter

Hali!
Segítségeteket szeretném kérni.
Egy keresőt szeretnék csinálni, pl. meg lehet adni a követekező adatokat:
szállás Típusa checkbox-szal: apartman, vendeghaz, hotel
Ellátás típusa checkbox-szal: reggeli, félpanzió, teljes ellátás
+ van egy submit gomb

Tehát ha valaki bepipiálja az apartmant, kiadja az apartmanokat, ha valaki apartmant és reggelit, akkor kiadja az apartmanokat, ahol az ellátás reggeli.

A táblám (szallasok) erre vonatkozó részlete:
szállás név, típus, típus_keresés, ellatas, ellatas_keresés

(típus pl: vendégház, típus_keresés pedig vendeghaz, tehat ékezetek nélkül, mert a checkbox-ot is úgy csináltam, hogy a value-ja ekezet nelkul legyen, pl. vendeghaz)

Ezt a következőképp kezelem le:
először kimentem a formról kapott adatokat ezeket a változóba:
$apartman, $vendeghaz, $hotel, $reggeli, $felpanzio, $teljesellatas

Ezek értéke a változó nevével azonos pl. $teljesellatas = 'teljesellatas'

Ezután jön az utasításom:
$sql = "SELECT * FROM szallasok WHERE tipus_kereses IN ('" . $apartman . "','" . $vendeghaz . "','" . $hotel . "') AND ellatas_rovid_kereses IN ('" . $reggeli . "','" . $felpanzio . "','" . $teljesellatas . "')";

De ez valahogy nem akarja az igazságot.
Valszeg tök rosszol csinálom.

Ami nehezíti majd, hogy kb 5 ilyen textbox-csoport lesz + település nevét lehet megadni és az kell, hogy ez mind külön külön is működjön, tehát ha csak nevet ad be valaki akkor adja ki azokat a nevűeket, de ha bepipál mást akkor azokat adja ki.

Minden ilyen variációt lekezelni elég hosszadalmas és bonyolult lenne.

Ilyen keresésre van valami más, egyszerűbb módszer?

Napok óta ezen töröm a fejem, de nem sikerül rájönnöm.

Köszönöm szépen annak, aki tud segíteni!

üdv,
Csabi

most hoztam be ezt a dolgot, de lehet tényleg semmi értelme, és hanyagolni kellene...

"Amikor már azt hittem kint vagyok, ezek mindig visszarántottak..." PSN ID: szecsi28 || GT5 && Bf BC2

nekem is van ehez hasonló helyzet, kiolvasom az egész táblát és csak azt íratom ki ami megfelel egy bizonyos feltételnek, remélem jól értelmeztem a dolgot és tudok segíteni.

ahogy írtad kimented a változókba az értékeket:

$apartman, $vendeghaz, $hotel, $reggeli, $felpanzio, $teljesellatas

$szallasok= mysql_query("SELECT * FROM szallasok");

while($sor=mysql_fetch_array($szallasok)){
//kiolvasol minden adatatot az adatbázisból amire szükségedvan
pl ha van olyan rekord a szálások táblában hogy tipus, akkor:
$tipus=$sor['tipus'];

//ha vendégházakat akarod kiíratni, akkor itt egy példa:
if($tipus==$vendeghaz){

elvileg csak azokat a házakat fogja listázni aminek a tipusa megegyezik a $vendeghaz értékével.

}
}

remélem tudtam segíteni és érthető amit írtam, de ha nem írd le táblád rekordjait meg hogy is nézz ki igazából, úgy többet tudok segíteni

[ Szerkesztve ]

"Amikor már azt hittem kint vagyok, ezek mindig visszarántottak..." PSN ID: szecsi28 || GT5 && Bf BC2

Adatbázisszerkezet?

MCTS: .NET Framework 4, Web applications | <?php die('hard'); ?>

A kereséshez szükséges adatok a táblából:

CREATE TABLE IF NOT EXISTS `szallasok` (
`azonosito` int(11) NOT NULL AUTO_INCREMENT,
`szallas_nev` varchar(30) CHARACTER SET utf8 DEFAULT NULL,
`helyseg` varchar(20) CHARACTER SET utf8 DEFAULT NULL,
`tipus` varchar(15) CHARACTER SET utf8 DEFAULT NULL,
`tipus_kereses` varchar(15) CHARACTER SET utf8 NOT NULL,
`ellatas_rovid` varchar(15) CHARACTER SET utf8 DEFAULT NULL,
`ellatas_rovid_kereses` varchar(15) CHARACTER SET utf8 DEFAULT NULL);

@SektorFlop: Érdekes felvetés, hogy először kérjek le mindent és aztán szűrjek. Köszi a tippet, megnézem. Bár gyanús, hogyha így nem jó, akkor úgy sem lesz az.

Most amúgy az a baj, hogy ha bekattintom h apartman + reggeli, akkor kidobja az apartmant, de reggelivel, félpanzióval és teljesellátással is. De nem értem, hogy miért.

hát én a fórum hozzászólásokat kezelem így, tökéletesen működik... és így oldanám meg a keresést is.

"Amikor már azt hittem kint vagyok, ezek mindig visszarántottak..." PSN ID: szecsi28 || GT5 && Bf BC2

megpróbáltam, egyelőre még nem jó..
küzdök még vele holnap is, aztán ha nagyon nem megy, beteszem a forráskódot, hátha megtalálja benne valaki a hibát és segít

majd én is igyekszem ránézni... és ha tudok segítek

"Amikor már azt hittem kint vagyok, ezek mindig visszarántottak..." PSN ID: szecsi28 || GT5 && Bf BC2

Na ne már....
Most komolyan azt javaslod, hogy minden adatot kérjen le adatbázisból, és majd utána szűrjön? Akkor gondolj bele, mi van, ha feltételezzük, hogy többmillió adata van, amik közül keresgélni kellene... akkor először az ÖSSZESET tök feleslegesen lekéri, és ezek után szűr? NEM, ilyet soha ne csinálj.

A fórum-hozzászólásoknál meg különösen illene szűrni, ott ugyanis még dinamikusabban nőhet az adatbázis mérete. És erre nem lehet válasz az, hogy "ugyan már, az én oldalamon úgysincs olyan nagy forgalom", ez a hozzáállás nagyon rossz, mi van, ha valamilyen oknál fogva mégis az lesz? Vagy mi van, ha akarsz egy következő alkalmazást fejleszteni, majd azt is úgy készíted, mert jól működött az előzőnél?

Amit itt írtál, az ilyesmi jellegű változónak átadás:
$tipus = $sor['tipus'];
az idők során rá fogsz jönni, hogy egy nagyon rossz szokás.
Ilyen módon nem bejárhatóak a későbbiekben az érintett adataid ciklussal, nem tudod őket könnyedén, egyértelműen kezelni, nem tudsz köréjük egy wrapper osztályt írni, vagy nehézkesen, és egyéb problémák is felmerülhetnek ezzel kapcsolatban.
Érdemes inkább kigyűjteni tömbökbe vagy objektumokba ezeket az adatokat, amik egy helyre tartoznak.
pl.
$hotels = array();
while($row = ............){
$hotels[] = $row;
}

egy leegyszerűsített példával élve. Ezután egyszerűen bejárhatók a hotelek adatai pl. egy foreach-csel.

[ Szerkesztve ]

Sk8erPeter

Az a baj, hogy már maga az adatbázis struktúrája rossz ebben a formában. Úgy kellene, hogy itt azonosítókat kapcsolsz össze, ami kiadja egy szállodaentitás tulajdonságait.
Az összes tulajdonsághoz tartozna egy azonosító (pl. magához az ellátás típusához is tartozik egy számszerű azonosító (pl. 666)), és a tulajdonságok konkrét értékeihez is tartozna azonosító (pl. a reggeli típusa 1, a félpanzió 2, a teljes ellátás 3, stb.), stringekkel ilyen esetben nem nagyon érdemes dolgozni, vagy legfeljebb egyetlen táblában legyen, amit összekapcsolsz az összes többivel, hogy megtudd, melyik tulajdonságról van szó - pl. nyilván a tulajdonságnak (ellátás) van egy neve is, ezt egy külön táblában jelezni kell; de van a tulajdonságokhoz tartozó értékeknek (reggeli, stb.) is neve, de ezek legyenek elkülönítve. Aztán INNER JOIN-olod őket...
Bocs, de most kissé késő van, ha holnap lesz energiám, ennél egy kicsit bővebben is kifejtem... Ez nagyjából ahhoz hasonlóan működik, mint egy társkereső, ott is vannak paraméterek, amik szerint keresget az ember mondjuk partnereket, nekem kellett hasonlóval dolgoznom már adatbázisszinten, na ott a fenti elképzelés szerint csináltam, elég összetett lett, de nagyon jól szűrhető, és elég konzekvens, de ami leginkább előnye, hogy könnyen bővíthető újabb paraméterekkel a meglévő struktúra megborítása nélkül.
Gondolom ez most így csak bonyolult fostengernek tűnik így elsőre, de annyira nem is az, majd megpróbálom jobban kifejteni, ha érdekel.

Sk8erPeter

Szia!
Köszi a hozzászólást. Marha késő van, alig látok, holnap rendesen is megpróbálom elemzni, amit írtál, de nagyjából értem.

Sehogy nem akar összejönni a dolog, most ilyet csináltam:

if ( $apartman != ' ' || $vendeghaz != ' ' )
{
if ( $reggeli != ' ' || $felpanzio != ' ' )
{
$sql = "SELECT * FROM szallasok WHERE tipus_kereses IN ('" . $apartman . "','" . $vendeghaz . "') AND ellatas_rovid_kereses IN ('" . $reggeli . "','" . $felpanzio . "')";
}
elseif ( $reggeli = ' ' && $felpanzio = ' ' )
{
$sql = "SELECT * FROM szallasok WHERE tipus_kereses IN ('" . $apartman . "','" . $vendeghaz . "')";
}
}

így ha bekattintom az apartmant vagy vendégházat vagy mindkettőt + reggelit és/vagy félpanziót, akkor teljesen jól kiadja a dolgot. De ha csak apartmant és/vagy vendégházat jelölöm be, de nem jelölöm be reggelit se meg félpanziót se, akkor nem ad ki semmit.
Egyszerűen nem jövök rá, hogy miért és nagyon idegel, hogy több napja ezzel szenvedek.
Ha ez jó is lenne, akkor sem lenne jó szerintem, mivel csomó értéket lehetne beállítani és amíg mindent lekezelek if-fel.. háát.. megöregednék valszeg meg belebonyolódnék.
Tehát gondolom van erre valami jobb megoldás.
Ha dolgoztál ilyen területen, akkor gondolom neked van ötleted erre is.
Nagyon szépen megköszönném, ha tudnál segíteni, persze ha időd engedi.

üdv,
Csabi

Igy van.
Szetszedni az adatokat tobb tablaba, es ugy osszekapcsolni.

A masik (ez nem neked szol sko8): szokjatok le a magyar valotozonevekrol. De ez meg semmi, mert baromira nem eleg. Kezdjetek el setet es getet hasznalni, es rovid, par soros fuggvenyeket irni. Es meg valami: az ilyen kod nem reusable. NE, ne, es ne!

Gondolkodjatok MVC-ben szedjetek megfelelo elemekre a kodot!

"Tartsd magad távol azoktól, akik le akarják törni az ambíciódat! A "kis" emberek mindig ezt teszik, de a nagyok éreztetik veled, hogy te is naggyá válhatsz" - Mark Twain

Miért és miben jobb a PDO a mysqli-től? (kérdezem ezt kezdőként)

Tegyük fel csak mysql-t akarok használni.

Dropbox regisztráció ( 2GB tárhely ): http://db.tt/Fcg29u0k +500 MB neked is, nekem is :)

Stackoverflow:
[link]

Kozelebb all a mostanaban szokasos programozasi stilusokhoz.

"Tartsd magad távol azoktól, akik le akarják törni az ambíciódat! A "kis" emberek mindig ezt teszik, de a nagyok éreztetik veled, hogy te is naggyá válhatsz" - Mark Twain

Sziasztok!

MySQL-nél miért van ilyen sok motor típus? (Engine)
Az INNO_DB miben jobb mint a többi?

Illetve láttam egy példánál, hogy használ egy külön táblát, ahol ha 2 táblát akarok összekötni, akkor létrehoz egy harmadik külön táblát, ahol mindkét tábla id-je van, ez mire jó?

InnoDB-t leginkább a tranzakció kezelés támogatása miatt miatt használják .

Második kérdésedre : tegyük fel hogy van egy hír táblád meg egy kategória tábla (politika ,sports stb.).Nade hogyan kategóriazánád be azt a hírt ,hogy : politikusok fociztak a hétvégén.

MySQL-nél minden storage engine bír valamilyen extrával a többiekhez képest, manapság valóban az InnoDB-t ajánlják, ennek sokkal jobb a teljesítménye, ha írásról van szó, képes row lock-ra, illetve a tranzakciókat is támogatja, de pl. FULLTEXT index-et nem tud.

---

A harmadik táblát kapcsolótáblának szoktuk hívni, arra való, hogy N .. N kapcsolatokat írjunk le velük, például: Products tábla kapcsolatban áll a Properties táblával (terméktulajdonságok, pl.: garancia), emellett egy plusz érték is szerepel, és mindez belekerül egy ProductsToProperties táblába:

ProductID, PropertyID, Value

Kicsit tolni kellene még az adatbázisalapokat.

MCTS: .NET Framework 4, Web applications | <?php die('hard'); ?>

Lehet ez ilyen MySQL specifikus dolog lehet.

Sem sima SQL alapoknál sem MSSQL-nél nem találtam kapcsoló táblákra vonatkozó dolgot.

Lehet egy MySQL-s könyvet is át kell forgatnom

Én simán össze JOIN-olom az összeset ami kell. (3. normálformában lévő táblákat is)

Én egy picit feleslegesnek találom a kapcsoló táblát. Ado.net-nél sem tapasztaltam még ilyet. Nekem ez tényleg új.

milyen mezőtípusban milyen hosszbeállítással tudok én tárolni olyan számokat, hogy 1230,43 0,12 stb úgy hogy ezeket aztán matematikai műveletekhez is tudjam használni normálisan? mert a double meg a float tuti nem jó, ha 0,12-t akarok beírni akkor Warning: #1265 Data truncated for column 'certFee' at row 1
online játék egyenlegeit akarom tárolni meg levonni a költségeket, usa dollárban, és lehet 0,01 dollcsi is a levonandó költség

Lehet, hogy nem tizedesvesszővel, hanem tizedesponttal várja a számot, tehát 0,12 helyett 0.12 kell. A float és a double elméletileg jó törthöz, esetleg próbáld meg double (10,2) formátummal létrehozni a mezőt (10 jegy, ebből 2 tizedes, persze igény szerint).

Gyógyíthatatlan betegség: a "duál kór" -- Sas húsz, foksz kettő!