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

• #1779 laracroft senior tag Peter Kiss #1778

  Új Válasz 2016-01-08 09:17:08 #1779

  Ú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

  

  laracroft

  senior tag

  válasz Peter Kiss #1778 üzenetére

  ~15000

• #1658 martonx veterán Peter Kiss #1657

  Új Válasz 2015-03-26 08:14:38 #1658

  Ú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 Peter Kiss #1657 üzenetére

  Jogos, a default mysql szerver beállítások egy kalap szart se érnek

• #1601 balaaa88 aktív tag Peter Kiss #1600

  Új Válasz 2015-01-09 13:40:43 #1601

  Ú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

  

  balaaa88

  aktív tag

  válasz Peter Kiss #1600 üzenetére

  Hát nincs mögöttem szerencsére (?) 10, de még 5 év tapasztalat sem, de most már tudom, hogy ezzel (is) óvatosan. Konkrétan lehalasztotta az egész ESXi-t a dolog. Illetve önmagán kívül még egy gépet kinyírt, de azt szerencsére hard reset után rendben visszajött. A MYSQL szervert meg szépen visszaállítottam 3 nappal korábbra (szerencsére magyarázkodni nem kell), aztán most az is fut szépen, de ha a jövőben ilyet csinálok, megnézem, hogy mekkorák a táblák már ugyan.

• #1579 Diopapa addikt Peter Kiss #1578

  Új Válasz 2014-10-04 10:58:12 #1579

  Ú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

  

  Diopapa

  addikt

  válasz Peter Kiss #1578 üzenetére

  Nagyon köszönöm a PM-ben nyújtott segítséged is!

• #1420 fordfairlane veterán Peter Kiss #1417

  Új Válasz 2013-08-20 23:53:56 #1420

  Ú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 Peter Kiss #1417 üzenetére

  Mi kérünk elnézést?

  Jah, hát lassan ott tart a dolog.

• #1418 biker nagyúr Peter Kiss #1417

  Új Válasz 2013-08-20 21:47:52 #1418

  Ú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

  

  biker

  nagyúr

  válasz Peter Kiss #1417 üzenetére

  Kérlek mutasd meg a hirdetésem, mert az aláírásban lévő szöveg, ami nem is link, körítés nélkül nehezen értelmezhető szolgáltatás hirdetésként, fikaverseny győztese cím ezennel a tied

• #1410 biker nagyúr Peter Kiss #1408

  Új Válasz 2013-08-20 14:58:54 #1410

  Ú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

  

  biker

  nagyúr

  válasz Peter Kiss #1408 üzenetére

  nem minden alkalmazás lényege a rugalmasság. ez is egy szempont, de nem mindenek feletti.
  Ezen túl külön tábla csak azoknak jár, amit garantáltan többször felhasználunk és/vagy sűrűbben írjuk6olvassuk mint a termékek táblát (kategóriák, értékelések, statisztikák, kosárban lévő cikkek, korábban vásárolt cikkek, stb)
  de mondd már meg, miért nem lehet egy táblában minden termék jellemző?
  id, név, rövid leírás, hosszú leírás, cikkszám, szállítói kód, vonalkód, cimkék, kat_id, szállítási idő, áfa osztály, ára, akciós ára, akció eleje, akció vége, eredeti ára, és még fejből nem tudom, mik
  te ezt szétdarabolnád? akkor minden darabolással egy redundáns termék_ID oszloppal hízlalod az adatbázist...

  martonx: nem arról volt szó, kinek az apukája erősebb, és kinek van több tapasztalata, hanem leírtam egy gyakorlati tapasztalatomat, ennyi.

• #1407 biker nagyúr Peter Kiss #1406

  Új Válasz 2013-08-20 13:54:31 #1407

  Ú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

  

  biker

  nagyúr

  válasz Peter Kiss #1406 üzenetére

  akkor úgy mondom, nem eléggé látványosan gyorsít

  egyébként igen, fulltext search miatt kell a match/against, és ez legalább relevancia szerint is tud rendezni, score-ra.
  a 30+ oszlop nem tervezési hiba, max egy másik elv...

  ha van egy termék és 30 jellemzője, akkor mitől jobb 16 táblába szétpakolni és egy segédtáblába mondjuk összeszedni a jellemző><ID párokat, mint egy woocommerce féle webshop esetén?

  nálam 150.000 termék 150.000 sor, a woocommerce a széthányt termékjellemzők miatt ugyan 4-5 oszloppal dolgozik, de 15.000 termék 670.000sort foglal el, és lassú mint egy halott disznó a jégen

• #1405 biker nagyúr Peter Kiss #1403

  Új Válasz 2013-08-20 06:49:00 #1405

  Ú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

  

  biker

  nagyúr

  válasz Peter Kiss #1403 üzenetére

  Sima select/where felallast meg latvanyosan nem is gyorsit az index, tapasztalat
  Match/against eseten igazan latvanyos, no meg kovetelmeny is mert csak indexbol dolgozik

  150.000 soros 30+ oszlopos 250megas tabla keresese index nelkul 6 oszlopra (termek nev, leiras, cimke, kategoria megjegyzes stb) 15-25mp
  Index es select 2-5mp
  Index 6 oszlopra es match against utan 0,01-0,06 sec, max 0,15 sec, erre mar mehetett a live search result box

• #1404 Drótszamár őstag Peter Kiss #1403

  Új Válasz 2013-08-18 22:55:11 #1404

  Ú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

  

  Drótszamár

  őstag

  válasz Peter Kiss #1403 üzenetére

  Értem, köszi. Át fogom nézni a táblákat e szerint, hogy hol min lehet gyorsítani.

  Az előző táblába tettem 800.000 rekordot, és egyelőre nincs lassulás. Köszönöm mégegyszer a segítséget.

• #1402 Drótszamár őstag Peter Kiss #1400

  Új Válasz 2013-08-18 21:46:32 #1402

  Ú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

  

  Drótszamár

  őstag

  válasz Peter Kiss #1400 üzenetére

  Köszönöm, nagyon sokat gyorsult így az ellenőrzés. Az eddigi 3-5 percről lement kb 1s-re.
  Tolok még a táblába teszt adatot, hogy lássam meddig bírja.

  Akkor a rossz indexelés volt a gond. Eddig úgy tudtam az a lényeg, hogy legyen az adott oszlopra index, de ezek szerint az adott WHERE feltételben szereplő mezőkre kell közös index.

• #1401 Drótszamár őstag Peter Kiss #1400

  Új Válasz 2013-08-18 21:33:51 #1401

  Ú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

  

  Drótszamár

  őstag

  válasz Peter Kiss #1400 üzenetére

  Köszi, mindjárt kipróbálom a két mezős indexet.

  Bejön a 10.000 adat. Ebből csinálok egy nagy SELECT-et, ami nézi a duplikációt, visszaad 0 és 10.000 sor közötti adatot attól függően, hogy van e dupla adat, vagy nincs. Amit visszaadott a SELECT, azokat a dátumokat kukázom a bejövő adatok közül (mivel duplák), és a maradék adatból csinálok egy nagy insert-et.

• #1399 Drótszamár őstag Peter Kiss #1398

  Új Válasz 2013-08-18 21:13:21 #1399

  Ú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

  

  Drótszamár

  őstag

  válasz Peter Kiss #1398 üzenetére

  datum BTREE
  Egyedi: Nem
  Csomagolt: Nem
  Számosság: 126492
  Illesztés: A
  Nulla: YES

  muszer_id BTREE
  Egyedi: Nem
  Csomagolt: Nem
  Számosság: 1
  Illesztés: A
  Nulla: YES

  Megszokásból MyISAM. Van erre a feladatra jobb tároló?

• #1312 Brown ügynök senior tag Peter Kiss #1310

  Új Válasz 2013-06-27 17:12:37 #1312

  Ú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

  

  Brown ügynök

  senior tag

  válasz Peter Kiss #1310 üzenetére

  Ilyen lekérdezéssel szerencsére én még nem találkoztam.

  @martonx: Átnéztem a táblákat és nincs olyan nagy vegyítés a motoroknál.

  Egyébként októberben költözik a cucc modernebb vasra, addig nézek valami okosságot a MySQL optimalizációjáról szóló fejezetében.

• #1305 martonx veterán Peter Kiss #1304

  Új Válasz 2013-06-26 22:27:49 #1305

  Ú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 Peter Kiss #1304 üzenetére

  Az f pont biztos nem, a g-t, h-t nem részletezted.

• #1285 spammer veterán Peter Kiss #1283

  Új Válasz 2013-06-12 19:44:03 #1285

  Ú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

  

  spammer

  veterán

  válasz Peter Kiss #1283 üzenetére

  És így?

  $result = $db->query("SELECT COUNT(id) FROM posts");
  $RowCount = $result->fetch_row();
  echo "Total" . $RowCount[0];

  Működik, csak a kérdés, hogy mint módszer, ez is rossz-e?

  Egyébként ha csak 'id' -t COUNT-olok, az számít valamit, vagy lényegtelen, és írjak nyugodtan csillagot? (Az elvileg ugye mindent kiválaszt).

  (#1284) fordfairlane: igen, már értem, csak először rosszul értelmeztem

• #1282 spammer veterán Peter Kiss #1281

  Új Válasz 2013-06-12 19:21:03 #1282

  Ú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

  

  spammer

  veterán

  válasz Peter Kiss #1281 üzenetére

  Aha, rosszul értelmeztem, így már oké:

  SELECT id FROM posts

• #1269 martonx veterán Peter Kiss #1267

  Új Válasz 2013-05-30 00:31:27 #1269

  Ú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 Peter Kiss #1267 üzenetére

  Plusz milliós nagyságrendű soroknál már jelentős helyet tudsz megtakarítani. Ha az a meződ index, akkor a hely megtakarítás máris duplázódik.

• #1265 spammer veterán Peter Kiss #1264

  Új Válasz 2013-05-25 19:15:12 #1265

  Ú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

  

  spammer

  veterán

  válasz Peter Kiss #1264 üzenetére

  Oh shit, szóval az volt a baj, hogy már volt néhány sorom, és mikor létrehozta volna az oszlopot így azok alapból üresek voltak, így már nem is lehetnek egyediek (mert nincs tartalmuk). Ehh... Most már jó, köszi

• #1232 spammer veterán Peter Kiss #1231

  Új Válasz 2013-05-18 15:03:41 #1232

  Ú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

  

  spammer

  veterán

  válasz Peter Kiss #1231 üzenetére

  Köszi, akkor jó. Azt hittem, hogy ha az adatbázisban be van állítva a kódolás (meg a php head-jében), akkor nem kell pluszban beállítani.

• #1209 Phvhun őstag Peter Kiss #1208

  Új Válasz 2013-04-30 08:11:02 #1209

  Ú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

  

  Phvhun

  őstag

  válasz Peter Kiss #1208 üzenetére

  és a history tábla az ugyanazokat a oszlopokat tartalmazza, mint az aktiális, vagy csak a változásokat ( Changetime, Changed_by, Data_name, Old_data, New_data ) ? mondjuk így

• #1194 Jinxb1rd addikt Peter Kiss #1193

  Új Válasz 2013-04-24 23:29:00 #1194

  Ú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

  

  Jinxb1rd

  addikt

  válasz Peter Kiss #1193 üzenetére

  Nem lehet ezzel emgelégedni, gondolj csak bele. Az össze termék nagybetűvel kezdődik, akkor az összes termék elő szava kieshet így.

• #1154 #68216320 törölt tag Peter Kiss #1153

  Új Válasz 2013-03-20 07:56:02 #1154

  Ú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

  

  #68216320

  törölt tag

  válasz Peter Kiss #1153 üzenetére

  Egyik sem. Hanem ezzel a táblaszerkezettel a LEFT JOIN és Group By sajnos nem elkerülhető, ami esetemben piszok sok sort eredményezne teljesen feleslegesen. Gyakorlatilag az elméleti része volt hibás, hisz miért számoljon minden lekérdezésnél, ha ugyanaz lesz az eredmény. De már megoldódott, kis változtatással, optimalizálással.

  select p.*, avg(eb.ertek_szam), avg(ep.ertek_szam) from pinceszetek p
  left join borok b on p.id = b.pinceszet_id
  left join ertekelt_borok eb on eb.bor_id = b.id
  left join ertekelt_pinceszetek ep on ep.pince_id = p.id
  group by p.id;

  Ez egy leegyszerűsitett verzió, tökéletesen működik, de lassú.
  pl. 3000 pincészet, pincészetenként 15 bor, boronként 50 értékelés. felesleges sorok a join miatt. ennyi.

• #1133 pvt.peter őstag Peter Kiss #1132

  Új Válasz 2013-03-11 09:33:31 #1133

  Ú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

  

  pvt.peter

  őstag

  válasz Peter Kiss #1132 üzenetére

  Köszi szépen, leszedem, megnézem mit is tud

• #1104 DanielK addikt Peter Kiss #1103

  Új Válasz 2013-01-07 06:25:19 #1104

  Ú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

  

  DanielK

  addikt

  válasz Peter Kiss #1103 üzenetére

  Nagyon szépen köszönöm!

  A joinra rájöttem (google révén), de a sorrendre nem, ezért mindig hibaüzenetbe ütköztem...

• #1062 laracroft senior tag Peter Kiss #1061

  Új Válasz 2012-12-06 09:59:19 #1062

  Ú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

  

  laracroft

  senior tag

  válasz Peter Kiss #1061 üzenetére

  Jaja ezt olvastam, de továbbra sem értem mi a különbség a count(*) és a count(1) között...

  my fault

• #972 Sk8erPeter nagyúr Peter Kiss #968

  Új Válasz 2012-10-30 10:44:21 #972

  Ú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 Peter Kiss #968 üzenetére

  Köszi az ajánlást, ezt kipróbáltam, és tényleg meglepően gyors! Ráadásul elég modern a felülete (ahogy a cikkben is kiemelik), egész kényelmes és intuitív a kezelése.
  Ami engem zavar, és elég gyorsan feltűnt, az első pár perc tesztelgetés után:
  1.) táblákra kétszer rákattintva először a struktúráját mutatja, ami még önmagában nem lenne gáz, de magához a tartalmához viszont kénytelen vagyok az SQL Management Studio-hoz hasonlóan rákattintani jobb gombbal, majd Use in Query menüben kiválasztani a Selectet. Pedig tesztelésnél van, hogy inkább azt szeretném megnézni, hogy mi a táblák tartalma, a struktúráját meg alapvetően elég kevésszer módosítom.
  2.) amikor az előbb említett Use in Query > Select menüpontot kiválasztom, akkor a hosszú, legörgetett táblalistában felugrik magának az adatbázisnak a nevére, igazából itt a bal oldali hasáb görgetési állapota nem tudom, miért nem tud független lenni a jobb oldalitól, miközben úgyis AJAX-szal töltődik be a tartalom, miért kell, hogy felugorjon a fókusz az adatbázis nevére. Ez nagyon zavaró tud lenni, ha ismét ugyanazon a táblán akarsz valami műveletet végezni, és már megint scrollozhatsz le a listában.
  3.) a query-k összepakolásánál hiányolom azt, ami megvan phpMyAdminban: a query összeállításánál felkínált lista a mezők nevével, amire elég csak rákattintani, és bedobja a textarea-ba.

  Ettől függetlenül elég ígéretes, és tényleg nagyon gyors. De azért sztem a fentiekben még fejlődnie kell, mert elég alapvető igények (nem?).
  Egyébként hol tárolja az elmentett dolgait? Nem kér külön adatbázist, táblák beállítását, mint mondjuk a phpMyAdmin. localStorage-ban vagy ilyesmi?

  ============

  (#969) lakisoft :
  Már elég rég használtam, de a MySQL Wordbench a dbForge Studio for MySQL-hez képest elég sok mindenben elmaradt, sok mindent hiányoltam belőle. Most nincs előttem, nem ugrik be hirtelen, mik voltak ezek, de a query-k összepakolása a dbForge-ban iszonyat kényelmes, míg a MySQL Workbench-ben nem nagy szám, nem lehet olyan szépen összerakni komplexebbeket.
  Az is hozzátartozik viszont, hogy a dbForge nem ingyenes.

• #963 Speeedfire félisten Peter Kiss #962

  Új Válasz 2012-10-18 22:19:46 #963

  Ú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

  

  Speeedfire

  félisten

  válasz Peter Kiss #962 üzenetére

  Oh, hogy az a. Valóban, most esett le, amit PazsitZ írt, hogy a leszűrt halmaz.
  Köszi srácok.
  Úgy látszik késő van már nekem...

• #961 Speeedfire félisten Peter Kiss #959

  Új Válasz 2012-10-18 22:14:45 #961

  Ú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

  

  Speeedfire

  félisten

  válasz Peter Kiss #959 üzenetére

  A 2. képen miért nem jeleníti meg a 18,19-es id-jú sorokat?
  Illetve ha a limit 20, 50 akkor pedig a 25. id-val rendelkező az első nála.

  Ennyire rövid az agyam, hogy nem jól emlékszem a limitre?
  Az első paraméter a kezdő érték, a második pedig, hogy az elsőtől kezdve mennyi rekordot jelenítsem meg. Vagy nem?

  
  PazsitZ: Hát akkor marad a where. Bár nekem tényleg úgy rémlik, hogy a limit-tel is lehet így játszani.

• #952 martonx veterán Peter Kiss #951

  Új Válasz 2012-10-18 09:08:27 #952

  Ú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 Peter Kiss #951 üzenetére

  megelőztél, tökéletesen egyetértek.
  A több select használata, és az azokból szerver oldalon eredmény összeidétlenkedése tipikus SQL-ezni nem tudó programozói attitűd. Ezek nem hogy gyorsítanak, de brutálisan lassíthatják az adatfeldolgozást.

• #912 Sk8erPeter nagyúr Peter Kiss #909

  Új Válasz 2012-09-17 19:17:00 #912

  Ú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 Peter Kiss #909 üzenetére

  Na, ez tök jó, ilyen sem sűrűn volt közöttünk, most mindegyik mondatoddal egyetértek. (Lehet, hogy ez egyszer nem fogunk vitába szállni, pezsgőt bontok ) Kivéve azzal, hogy "nem PHP-s, tudom, kapjam be". Én aztán nagyon nem vagyok PHP-rajongó. Jelenlegi terveim szerint a jövőben webes területen éppen ASP.NET-re szeretnék átállni teljesen, vagy valamelyik Java-s technológiára. Eleve mondjuk az általam kedvelt C#, Java, C++ nyelvek közül bármelyikben sokkal szebben lehet kódolni (kevésbé sarkall gányolásra, vagy engedi azt), mint PHP-ben (tudom, kapjam be ).
  Addig is az általad említett PHP-s frameworkök engem is foglalkoztatnak, pont ezek a "menőbbek", amiknek a használatát már sokszor szerettem volna megtanulni.

• #907 Sk8erPeter nagyúr Peter Kiss #906

  Új Válasz 2012-09-17 18:16:54 #907

  Ú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 Peter Kiss #906 üzenetére

  Ha már itt tartunk, milyen framework az, ami tapasztalataid meg kódja alapján szted jónak minősül?
  Minden frameworknek van valami bakija, de kíváncsi vagyok, szted melyik az, amelyiket lehet jónak nevezni.

• #904 Speeedfire félisten Peter Kiss #903

  Új Válasz 2012-09-17 17:50:56 #904

  Ú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

  

  Speeedfire

  félisten

  válasz Peter Kiss #903 üzenetére

  Nekem ebből az jön le, hogy ORM-es.

  And Yii Active Record (AR), implemented as a widely adopted Object-Relational Mapping (ORM) approach, further simplifies database programming. Representing a table in terms of a class and a row an instance, Yii AR eliminates the repetitive task of writing those SQL statements that mainly deal with CRUD (create, read, update and delete) operations.

• #895 Speeedfire félisten Peter Kiss #893

  Új Válasz 2012-09-16 20:07:57 #895

  Ú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

  

  Speeedfire

  félisten

  válasz Peter Kiss #893 üzenetére

  Agyalok a monoDb-n, de majd meglátom mi lesz belőle. Vagy másra gondolsz?
  Ebben nem vagyok otthon annyira.

  
  Soak: Pontosan.

• #892 Speeedfire félisten Peter Kiss #891

  Új Válasz 2012-09-16 19:52:20 #892

  Ú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

  

  Speeedfire

  félisten

  válasz Peter Kiss #891 üzenetére

  Lehet úgy is, megy így is. Ez a legszebb az egészben.

  SQL-ben nem, de a model tudja és legtöbbször AR-el szoktam a lekérdezéseket megcsinálni.

• #888 Sk8erPeter nagyúr Peter Kiss #887

  Új Válasz 2012-09-16 17:29:04 #888

  Ú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 Peter Kiss #887 üzenetére

  "A tbl_user táblában miért van benne a salt?"
  Na igen, ezt én is kérdeztem, még mindig nem látom az okát.

• #767 Soak veterán Peter Kiss #766

  Új Válasz 2012-06-21 10:30:43 #767

  Ú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

  

  Soak

  veterán

  válasz Peter Kiss #766 üzenetére

  Köszi a választ, de nem igazán értem meg mondom őszintén . Ha egyik user másik user akkor nem csak 1 kapcsolat lehet? Mi van ha van az egyik usernek 100 kapcsolata?

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