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

• #9242 inf3rno nagyúr Bambula5 #9221

  Új Válasz 2015-11-02 19:26:46 #9242

  Ú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

  

  inf3rno

  nagyúr

  válasz Bambula5 #9221 üzenetére

  Elvileg a postgresql, amit írtál elég lehet. Ha túl lassú lenne, akkor váltanod kell noSQL-re vagy newSQL-re. Az utóbbiból nézegettem ruby-s gem-eket, NuoDB-hez volt valami tűrhető, de már azt is 2 éve nem fejlesztik, lehet, hogy fel se tudnád telepíteni, build failing-et ír a travis. [link] Nem egy jó nyelv ilyen szempontból a ruby, meg amúgy sem, legalábbis sokan nem szeretik. Én inkább távol tartom magam tőle.

• #9240 inf3rno nagyúr Bambula5 #9221

  Új Válasz 2015-11-02 19:08:13 #9240

  Ú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

  

  inf3rno

  nagyúr

  válasz Bambula5 #9221 üzenetére

  Szerintem eleve rossz a kérdés. Inkább azt kellene feltenni, hogy milyen típusú adatbázis felel meg ennek az adatnak. Az is egy szempont, hogy mennyit vagy hajlandó pénzben rászánni meg hogy mi az iránycél sebességben.

• #9224 dabadab titán Bambula5 #9221

  Új Válasz 2015-11-02 15:05:52 #9224

  Ú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

  

  dabadab

  titán

  válasz Bambula5 #9221 üzenetére

  A táblákba szétszedés a sebességet nem fogja feltétlenül javítani
  Azt már tudod, hogy mi alapján kell keresned?
  Mert ha a tulajdonságok alapján (amik elég dinamikusnak tűnnek), akkor lehet, hogy jobban járnál egy nosql adatbázissal.

  (#9223) emvy: tisztán a gyakorlatitapasztalatmentes okoskodás szintjén azért segíthet, ha nem minden rekordon külön lemezblokkból kell összevadászni, hanem egy olvasással megvan egy rakat sor (feltéve, hogy a sorok elég rövidek)

• #9223 emvy félisten Bambula5 #9221

  Új Válasz 2015-11-02 15:04:23 #9223

  Ú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

  

  emvy

  félisten

  válasz Bambula5 #9221 üzenetére

  Az, hogy a tabla nagy, semmilyen problemat nem jelent.

• #9222 Jim Tonic nagyúr Bambula5 #9221

  Új Válasz 2015-11-02 14:58:03 #9222

  Ú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

  

  Jim Tonic

  nagyúr

  válasz Bambula5 #9221 üzenetére

  A problémám az lenne, hogy tekintettel a rengeteg termékre és azok különböző tulajdonságaira nem lenne szerencsés egy táblában tárolnom őket. Miként lehetne megoldani, hogy egy-egy alkategória létrehozásánál létrejöjjön egy hozzá tartozó termék tábla? Gondolom ez a keresést is felgyorsítaná...

  Triggerekkel lenne a legelegánsabb megoldani, de szerintem nem ez a jó irány. Óriási adatbázisokban sem szokás ugyanolyan típusú adatot más táblában tárolni. Az tudod milyen mélységig vannak alkategóriák? Szerintem egyéb paramétereket kell használni, és okosan indexelni.

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