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

• bambano titán

  #9908

  #9893 akrobet

  2016-06-13 14:30:24

  Új Válasz

  Ú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

  

  bambano

  titán

  #9893 akrobet

  #9893 akrobet

  Akkor let's agree to disagree Értem én hogy sql-ben érdemes olyan részeit az alkalmazásnak átírni ami a legtöbbet használt és EF nem képes rá megfelelően gyorsan futó query-ket generálni.

  De mit csinálsz ha váltani kell egy másik providerre, neaggyisten valamilyen no-sql megoldásra?

  Nem lehetetlen SQL-ben megírt kódot tesztelni, karbantartani, csak nagyon hamar el fog menni tőle a kedved, ha egy olyan business model-ed van, ami kb 300 egyedi entitásból áll 15+ level mélységű relationokkel...

  nem tudok elképzelni olyan helyet, ahol mssql-t ne lehetne találni. tehát ha szolgáltatót is kell váltani, adatbázismotort nemigen.
  másrészt ha nosql-re kellene váltanod, ott a legkisebb problémád lesz az, hogy pár eljárás volt az sql motorban. sql-ről nosql-re váltani az kb. a komplett alkalmazás újratervezését jelenti.

  "Nem lehetetlen SQL-ben megírt kódot tesztelni, karbantartani, csak nagyon hamar el fog menni tőle a kedved, ha egy olyan business model-ed van, ami kb 300 egyedi entitásból áll 15+ level mélységű relationokkel...": itt nem arról van szó, hogy az egészet tedd procedurális sql-be, hanem arról, hogy azt az egy problémát, amivel a threadet elindítottad, azt tedd ilyenbe.

  nekem vannak kétségeim, hogy jól van-e tervezve az az adatbázis, amiben 15+ level mélységű relációk vannak, különös tekintettel a view-ekre...

  "nagyon hamar el fog menni tőle a kedved": ezt a szempontot nem annyira szokták figyelembe venni... nekem pl. a felvételi elbeszélgetésen elmenne a kedvem, ha mssql-ről esne szó

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