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

• #9886 amargo addikt akrobet #9878

  Új Válasz 2016-06-12 10:43:08 #9886

  Ú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

  

  amargo

  addikt

  válasz akrobet #9878 üzenetére

  en xml be kezelnem le a problemat es abbol expression segitsegevel generalnam a kodot szerver oldalon. egyszeruen azert xml, mert xml-ul barki tud es kelloen rugalmas a szabalyok leirasara.
  viszont lassabb lesz barmilyen nativ megoldasnal. de gyors es rugalmas is egyszerre nem tudom, hogy lehetne. nyilvan egy erre kulon letrehozott feldolgozoval, amit mar tobben is javasoltak meglehet oldani. de szerintem itt nem ez az elvaras.

• #9882 martonx veterán akrobet #9878

  Új Válasz 2016-06-11 23:55:09 #9882

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

  Szerintem a többiek ezt a C# ellenességet túllihegik, pontosabban félreértik, mivel a feladatot sokkal inkább SQL oldalon kell szerintem megoldani, mintsem C# oldalon. Ha adatbázisban jó, rugalmas és gyors modellt tudsz felépíteni, akkor azt kezelni már teljesen mindegy, hogy milyen nyelvben fogod.
  És ugyanez igaz fordítva is. Ha db szinten elcseszed, na akkor egy szuper rugalmas PHP se ment meg attól, hogy le ne fosd a bokádat nap, mint nap a szabályok átdrótozásakor.
  Én ugyan NoSQL-el állnék neki, de hiszem, hogy hagyományos SQL-el is jól megfogható a probléma, pl. raktam már össze repülőjegy árazó engine-t, aminek kellemesen bonyolult sok dimenziós mátrixokból kellett dolgoznia, és szépen megoldható volt sima SQL-el, 3-4 táblával, meg némi C#-al a DB felett.

• #9880 bambano titán akrobet #9878

  Új Válasz 2016-06-11 23:46:22 #9880

  Ú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

  LOGOUT blog

  válasz akrobet #9878 üzenetére

  rendben, akkor találj ki egy programozási nyelvet, aminek az értelmezőjét c#-ban írod meg. én phpban írnám, mert igazán nagyon durvát szerintem abban lehet kavarni, de ha neked c# kell, nem gond.
  ha az értelmezőt c#-ban írod, akkor le fog fordulni és működni fog további függőség nélkül.

  "Továbbá a kiindulási helyzet is az, hogy már adott a rendszer többi része, tehát valószínűleg késő lenne egy új programozási nyelvet "feltalálni" és az adatbáziskezelőt lecserélni.": az adatbáziskezelő lehet jó vagy rossz korlátozó tényező, de ha csak adatbázison keresztül kommunikálna a rendszer, akkor nem lenne gond, hogy más nyelvű modulokat faragj mellé.

  "Namármost, ha én olyan szinten lennék (de nem vagyok) hogy írjak egy új nyelvet, amiben ezeket a szabályokat kellene írni, attól még nem szűnne meg a szükség a maintenance-re": ha az értelmezőt nem kell módosítani, akkor a kódot emiatt nem kell karbantartani, így az a fajta karbantartás nincs, ami akkor lenne, ha kódba vésnéd a logikát. a szabályrendszer karbantartását meg, szerintem, meg lehetne egyszerűen oldani, ha jól megmakrózod az egészet.

  nem olyan nagy durranás, régi ibm gépeket assemblyben programozták, mert a makro assemblere mocskos jól volt megfaragva.

  hasonlót, kicsit kisebb léptékben, csináltam magamnak nemrég, megvolt egy nem alvós hétvége alatt.

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