Tak opäť som tu s menším problémom. Celá vec spočíva v tom ,že sa pokúšam v tabuľke aktualizovať riadok.
Čo by som však potreboval je kontrola či bola táto query úspešne vykonaná. Skúsil som affected_rows no samozrejme mi to vrátilo len počet riadkov ,ktoré boli nejako zmene čiže ,ak zašlem UPDATE s rovnakými parametrami aké už sú v DB, query sa vykoná ,ale affected_rows vráti nulu.

Prečo mi o to ide? Čo sa týka parent_id tak to kontrolujem či ho user vlastní ,ak áno tak sa pristupi ku query no kľúč tz. "id" schválne nekontrolujem z čoho vyplýva ,že user môže zaslať hocijaké ID. Na dáta to nemá žiaden vplyv, nedá sa to obíjsť kedže tam je parent_id čo potrebujem je ,ale zistiť či sa query vykonola tz. či bolo IDčko v pohode alebo nie...

* Používam mysqli, prepared statements. Viem ,že môžem kontrolovať IDčko pred samotnou query a tak vyhodiť výsledok no nechcem to riešiť týmto štýlom.

Vďaka za každú rekaciu k téme

S-player napísal: * Používam mysqli, prepared statements. Viem ,že môžem kontrolovať IDčko pred samotnou query a tak vyhodiť výsledok no nechcem to riešiť týmto štýlom.

nechápem, prečo preferuješ kontrolu cez query namiesto podmienky v php čo je podstatne rýchlejšie a jednoduchšie, ale je to tvoja vec..

ono sa to bežne robí cez mysqli_affected_rows(). Tým že tam môže ísť hodnota ktorá tam nemá čo robiť si to iba komplikuješ. Nevieš rozlíšiť či sa neupdatlo preto, lebo prišli rovnaké hodnoty ako tam boli alebo preto, lebo tam prišla chyba v zlom ID. Môžeš sa pozreť na mysqli_error() ale je to ako ísť z BA do KE cez Lisabon

rob to ako pisal audio,
ja som tiez raz potrevoval vediet ci sa stlpec aktualizoval, ale z ineho dovodu, tak som do tabulky pridal stlpec s casom aktualizacie a mysql_affected_rows() pekne zafungoval

$update = UPDATE ...........

to ti iba povie, či sa query vykonalo alebo nie. Ale nepovie ti to nič o tom, či sa hodnoty aktualizovali alebo nie

harrison314 napísal:rob to ako pisal audio,
ja som tiez raz potrevoval vediet ci sa stlpec aktualizoval, ale z ineho dovodu, tak som do tabulky pridal stlpec s casom aktualizacie a mysql_affected_rows() pekne zafungoval

Dobrý nápad tak ,ale mať tam tisíce zbytočných hodnôt mi nieje veľmi "po chuti". Musím nad tým popremýšľať ako to spraviť, ono to IDčko nekontrolujem schválne preto lebo nepotrebujem userovi zobraziť "Nemáš nárok na úpravu tohto...". Či sa riadok naozaj aktualizoval potrebujem viac menej pre vlastný log.

Ak začnem kontrolovať IDčko tak to pre mňa znamená zbytočnú funkciu (Resp. funkcie) navyše + zbytočnú query na SQL (Navyše) aby som bol konkretnejší tak na .PHP script sa odosiela pole dát čiže ,ak bude pole.length == 100 tak to znamená 100 požiadaviek na kontrolu ID + vo väčšine prípadov (Ak sa nevyskytne nesprávne ID) tak 100 požiadaviek na aktualizáciu riadku.

Možno to znie smiešne ,ale môže to pre mňa spraviť pekne veľa preto sa pokúšam neriešiť zbytočnosti. Vyššie zmienený "log" (Resp. to ani nieje log ,ale skôr nejaký "result") potrebujem pre akcie na pozadí...

veď mu to ani písať nemusíš. Ak nemá nárok, tak sa query nespustí. Ak má nárok, tak sa spustí a zaloguješ či sa niečo zmenilo alebo nezmenilo. Užívateľ nič nemusí vidieť, žiaden rozdiel nespozoruje.

ten posledný odstavec nekomentujem, smrdí to zlým návrhom

Veď mu to ani nepíšem a je mi úplne jasné ,že user nič nespozoruje... No a momentálne práve riešim ako tú zmenu zalogovať (Bez nejakého IFu pred požiadavkou)


// Skús navrhnúť niečo lepšie čo by nevyžadovalo query na kontrolu. Riadok obsahuje len svoje ID a ID rodiča. Ja som žiaľ neprišiel na nič iné...

S-player napísal:Ak začnem kontrolovať IDčko tak to pre mňa znamená zbytočnú funkciu (Resp. funkcie) navyše + zbytočnú query na SQL (Navyše) aby som bol konkretnejší tak na .PHP script sa odosiela pole dát čiže ,ak bude pole.length == 100 tak to znamená 100 požiadaviek na kontrolu ID + vo väčšine prípadov (Ak sa nevyskytne nesprávne ID) tak 100 požiadaviek na aktualizáciu riadku.

Da sa to spravit aj jednou query na kontrolu cez ALL, IN, ANY, .... , ktoru mozes robit aj po vykonani updatu.

Ano, no tam namiesto uspesne, moze vypisat hodnoty, alebo dat if a porovat hodnoty v db s odslanymi hodnotami.

Ano, no tam namiesto uspesne, moze vypisat hodnoty, alebo dat if a porovat hodnoty v db s odslanymi hodnotami.

Vďaka za tvoje rady ,ale tento spôsob je proste odveci.

Da sa to spravit aj jednou query na kontrolu cez ALL, IN, ANY, .... , ktoru mozes robit aj po vykonani updatu..

Ak si mám vybrať tak radšej budem kontrolvať ID než to či sa zmenili nejaké hodnoty. Dosť k hovnu je ,že v istej sekcii sa dostávam k tomuto:

PARENT:
-> CHILD_1 (Odkaz na P)
--> CHILD_2 (Odkaz na C1)

Parent má ID užívateľa čiže to čo musím prekontrolovať no pokiaľ sa mám k tomu dostať musím isť z C2->C1->P. Áno mohol by som to vyriešiť tým ,že do CHILD_2 pridám ID používateľa no to je opäť veľká kopa zbytočností navyše. Máte nejaké nápady ,ktoré by mi mohli pomôcť? Naozaj mi ide veľmi o rýchlosť, nenáročnosť, minimalizmus scriptu inač by som to mal spravené už dávno minimálne na tri spôsoby. Vďaka

tu sa rieši presne tvoj problém: http://bytes.com/topic/mysql/answers/14 ... -structure
zase platí, že máš zlý návrh. Takto to dopadne keď niekto programuje hurá systémom. Ak je tých úrovni vela, tak to nijako efektne nespravíš (bez toho ukladania parenta ako novej hodnoty). Ak ich je málo (2-3) tak cez join alebo subquery

Tiez odporucam prekopat,
toto si precitaj
http://www.zdrojak.cz/clanky/ukladame-h ... atabazi-i/
http://www.zdrojak.cz/clanky/ukladame-h ... tabazi-ii/
http://www.zdrojak.cz/clanky/ukladame-h ... abazi-iii/

Dík vám obom za linky, pridávam ešte jeden ak by niekto potreboval pomoc (http://www.slideshare.net/billkarwin/mo ... hical-data). Potrebujem sa však s vami ešte aj tak poradiť (Potrebujem si byť istý ,že to neriešim zle). Bol by som rád ,ak by ste mi pomohli.

1. Momentálne vyzerá štruktúra zhruba nejako takto: (Ide o vymyslení príklad snáď z neho výjdete)

USERS:
id...

MEALS:
id, user_id...
#####################################
FRUITS:
id, meal_id...

FRUIT_DESTINATIONS:
id, fruit_id...
######################################
VEGETABLES:
id, meal_id...

VEGETABLES_DESTINATIONS:
id, vegetables_id...



Teraz k novej štruktúre:

USERS:
id...

MEALS::
id...
######################################
FRUITS:
id...

FRUIT_DESTINATIONS:
id...
######################################
VEGETABLES:
id...

VEGETABLES_DESTINATIONS:
id...


TREE:
id, parent_id
1, null[USER]
2, 1[MEAL na utorok]
3, 2 [BANÁN]
4, 2 [POMARANČ]
5, 3 [KOLUMBIA]
6, 3 [EKVADOR]
7, 2 [UHORKA]
8, 2 [CIBUĽA]
...
9, 1 [MEAL na stredu]
...
10, null [ďalší USER]
...

Táto tabuľka mi vytvorí kompletný strom všetkých dát. Pochopil som to takto správne?

*** Mám v tom kúsok bordel kedže nejde len o jedenu vec napríklad komentáre a ich "napájanie sa" ,ale o rozličné dáta. Ak by to malo fungovať takto tak tabuľka "tree" bude zrejme potrebovať ešte jede stĺpec pre org. IDčka

Namiesto neuplnych tabuliek radcej povedz (ako clovek), co chces vlastne v databaze uchovavat, lebo z hentoho mam pocit, ze nato v ziadnom pripade strom netreba.

Tak môžem povedať na rovinu ,že nejde o nič na štýl komentárov tz. ,že je nepravdepodobne aby sme sa dostali napríklad k nejakému šiestému childu. User bude mať na 95% troch potomkov ako to je v tomto prípade ,ak sa niečo zmení tak maximálne štyroch (To zrejme ,ale nie). Čiže vyššie zverejnená štruktúra je momentálne 100% rovná tej mojej ibaže s inými názvami.

No a čo potrebujem s týmto celým spraviť je:
- Patrí MEAL userovi?
- Patrí FRUIT/VEGETABLES userovi?
- Patrí FRUIT_DEST/VEGE.DEST userovi?

Čo ma serie je to ,že keď chcem zistiť či user vlastní tretí child tak mi to vezme nejaké tri query... Ak chcem zistiť či user vlastný druhý child tak mi to vezme dve query (Výber MEAL_ID a následne čeknutie USER_ID && MEAL_ID)


// Ak by to bolo založené na X/XX potomkoch tak to mi je jasné ,že takýmto štýlom to riešiť netreba veď by som to mal X tabuliek preto som to riešil tak ako to je teraz.

S-player napísal:Tak môžem povedať na rovinu ,že nejde o nič na štýl komentárov tz. ,že je nepravdepodobne aby sme sa dostali napríklad k nejakému šiestému childu. User bude mať na 95% troch potomkov ako to je v tomto prípade ,ak sa niečo zmení tak maximálne štyroch (To zrejme ,ale nie). Čiže vyššie zverejnená štruktúra je momentálne 100% rovná tej mojej ibaže s inými názvami.

No a čo potrebujem s týmto celým spraviť je:
- Patrí MEAL userovi?
- Patrí FRUIT/VEGETABLES userovi?
- Patrí FRUIT_DEST/VEGE.DEST userovi?

Čo ma serie je to ,že keď chcem zistiť či user vlastní tretí child tak mi to vezme nejaké tri query... Ak chcem zistiť či user vlastný druhý child tak mi to vezme dve query (Výber MEAL_ID a následne čeknutie USER_ID && MEAL_ID)


// Ak by to bolo založené na X/XX potomkoch tak to mi je jasné ,že takýmto štýlom to riešiť netreba veď by som to mal X tabuliek preto som to riešil tak ako to je teraz.

To co si mapisal mi je nanic, ja som nechcel pocut technicke veci ani ID-cka, povedz mi ake tam su data s pohladu usera, napr.: "pouzivatel si bude moct v systeme pridavat jedlo pre konkretne dni aj kam ma byt zaslane".

-> User si pridá do DB svoj "meal" ,ktorý obsahuje niekoľko vlastností povedzme názov, deň ,na ktorý je tento meal určený a kopec iných...
-> FRUIT user si pridá nejaké ovocie ,ktorý spadá po daný meal opäť tabuľka obsahuje niekoľko vlastnosti
-> FRUIT DEST k danému ovociu sa pridá destinácia (Jedno ovocie môže mať viac destinácii) napríklad Afrika a pridá sa tam aj niekoľko dalších vlastností povedzme napríklad podnebie krajiny, počet obyvateľov, priemerná cena atp, atp...

Z tejto štruktúry vyplýva ,že user má nejaký svoj meal ,pod ktorým je niekoľo druhov ovocia/zelenín a každé ovocie/zelenina má svoje detaily (Z kadiaľ pochádza atd)

Čo sa týka práce s týmito dátami tak user si ich proste nahodí následne si ich môže čeknúť v nejakej tabuľke (Tabuľka všetkých meal, vyberie si nejaký meal a zobrazí sa mu list všetkých potravín/ovocia, vyberie ovocie a môže vidieť jeho detaily).

* Treba však brať do úvahy ,že user môže upravovať hodnoty a presne kvôli tomu potrebujem kontrolovať či user vlastní danú položku.

Pokiaľ by si potreboval ešte nejaký bližší popis kľudne napís a pokúsim sa ti ju zodpovedať.

Toto neni strom, v pravom slova zmysle,a ani implemetacne.
Strom v sebe uchovava hierachycky zoradene informacie rovnakeho typu (klasicky staty>vysie uzemne celky>mesta).

Ty budes mat tabulku pre puzivatela, tabulku pre MailyMeal (bude v sebe obsahovat den ako atribut), tabulku Meal, ktora bude zdruzovat aj ovocie aj zeleninu (ak maju vela spolocnych atributov), tabulku Destinations, v ktorej budes mat destinacie, a jednu na prepojenie Meal s Destinaciou (kardinalita N:N).

Áno ja tomu chápem veď som napísal ,že kebyže riešim napríklad len napríklad komentáre (Rovnaký typ) a každý následujúci komentár spadá pod predchádzajúci tak mi je úplne jasne ,že to nemôžem riešiť takto ako som riešil to vyššie a nahodil by som strom. (Nejakú hierarchiu). Mal som tie tabuľky nahodiť asi hneď na začiatku pretože som tým pomotal hlavu vám aj sebe aj keď som písal len o dvoch childoch nie X.

Čiže teraz je problém ako overovať dáta aby som kvôli tomu nemusel isť cez 3 veci.