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

• #9908 bambano titán akrobet #9893

  Új Válasz 2016-06-13 14:30:24 #9908

  Ú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

  

  bambano

  titán

  válasz akrobet #9893 üzenetére

  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ó

• #9902 martonx veterán akrobet #9893

  Új Válasz 2016-06-13 10:49:30 #9902

  Ú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 akrobet #9893 üzenetére

  "De mit csinálsz ha váltani kell egy másik providerre, neaggyisten valamilyen no-sql megoldásra?" - ok tegye fel a kezét, aki naponta vált MS SQL-ről Oracle-re és vissza SQL - NoSQL pedig még ORM-el sem átjárható, mivel teljesen más szemléletmódot, felhasználást várnak el.
  Egy programnál mindig el kell dönteni, hogy milyen infrastruktúrán fog futni, és utána abból kihozni a legjobbat. Tipikus félreértés, hogy az ORM azért jó, mert elfedi a DB layert, és könnyű átjárhatóságot biztosít (az meg még nagyobb félreértés, hogy SQL - NoSQL átjárhatóságot is biztosítana). Mármint az átjárhatóság SQL-en belül még nagyjából igaz is, de ennek csak akkor van szerepe, ha az ember tudatosan, direkt pont olyan rendszert fejleszt, amit kb. bárhova el akar adni, és célja, hogy Oracle, MySql, PostgeSQL, MS Sql, bármilyen SQL felett tudjon működni a rendszere. Ebben az esetben némi plusz munkával valóban meg lehet írni ORM-el úgy a rendszert, hogy az tökéletesen átjárható legyen.
  ORM-et elsősorban inkább azért használunk, mert kényelmes vele dolgozni, a kód valóban olvashatóbb lesz tőle, de fontos, hogy folyamatosan tartsuk szem előtt, hogy az ORM csak egy eszköz, és nagyon könnyen hibás architektúrákhoz vezethet, ha csak és kizárólag egy ORM-re alapozva fejlesztünk. Erre tökéletes példák vagytok ti.

  Ez az SQL-ben legyen logika dolog teljesen eset függő, nincs rá jó válasz. Én az általad megfogalmazott problémával kapcsolatban mondtam, hogy ebben az esetben szerintem tipikusan sokkal jobb megoldás tud lenni, ha komolyabban az SQL-re bízná magát az ember, és komolyabban elgondolkodna az SQL-ben való adatmodellezésen (nem is feltétlenül érdemi logikának kellene talán az SQL-ben lenni, egyszerűen csak végre komolyabban kellene gondolni, tervezni az SQL oldalon is a tábla struktúrákat, amikkel a várt dinamikus szabály rendszert könnyen lehetne modellezni, majd azt utána C# oldalon felhasználni).
  Pláne amikor későbbi hszediből ki is derült, hogy a DB-t tényleg ahogy esik, úgy puffan alapon használjátok, szóval egyre biztosabb vagyok a meglátásom helyességében.
  Szóval nem akarok olyan erős kijelentéseket tenni, hogy csak így, vagy csak úgy a jó, az elmúlt pár évben mindkét megoldást használtam, mindig azt amire éppen az adott esetben szükség volt.

  Főállásomban pont az elmúlt években volt / van egy ilyen komolyabb szemléletváltás, amikor az eredetileg mindent EF-el oldjunk meg, és kapja meg az adatot a C#, aztán majd abban jobban feldolgozzuk szemléletet a több milliárd adatsoros tábláknál már fel kellett, hogy váltsa az "oké, akkor amit lehet SQL oldalon oldjunk meg, de azért amit nem muszáj, az menjen továbbra is EF-el" szemlélet. Hidd el, pont ugyanúgy lehet mindent tesztelni SQL felhasználása mellett is, csak mondjuk egy teszt nem 5 másodpercig fog futni, hanem fél percig. De ha elég jól párhuzamosítod őket, akkor végül időben se tart feltétlenül tovább.
  Minden csak hozzáállás kérdése, még az általad felvázolt alapvetően hibásnak tűnő architektúra is valószínűleg tesztelhető maradna némi refaktorálás után, megfelelő mockolásokkal.

• #9896 lezso6 HÁZIGAZDA akrobet #9893

  Új Válasz 2016-06-13 09:25:27 #9896

  Ú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

  

  lezso6

  HÁZIGAZDA

  LOGOUT blog

  válasz akrobet #9893 üzenetére

  Én sose értettem, hogy miért jó az "univerzális" adatbázis nagyobb rendszerek esetén. Ha képlékeny még, hogy milyen DB kell, akkor még talán megértem, de ennyi erővel meg lehet, hogy a C#-ot kell dobni. A SQL -> noSQL váltási kényszer belekalkulálását meg aztán végképp baromságnak tartom, nagyon másra való a kettő. Egy esetleges DB migrációra fel lehet ugyan valamennyire készülni (ha előre tudod, hogy lesz), de az egy worst-case scenario, emiatt eltoszni a kódot butaság.

• #9895 emvy félisten akrobet #9893

  Új Válasz 2016-06-13 09:22:23 #9895

  Ú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 akrobet #9893 üzenetére

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

  Atirod. Adatbazist a legritkabb esetben lehet 'csak ugy' valtani, hiaba hasznalsz ORM-et.

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