Delphi sql pro es kontra

Ez a téma lezárásra került a moderátor által. A lezárás oka: T�ma: programoz�s-ELM�LET!!!
Delphi sql pro es kontra
2006-02-10T14:10:49+01:00
2006-02-24T10:13:56+01:00
2022-10-31T09:35:42+01:00
  • A tárolt eljárásos szerver oldali programozásról kérdem, hogy ez hogy néz ki a kliens (Delphi) oldalon? Ha pl. írok egy uj_rendeles(...) nevű tárolt eljárást és azt meghívom, akkor futtatás után be kell zárnom és újranyitnom az összes táblát amit az eljárás módosított, különben nem értesülök a módosításról. Ekkor viszont elvész az aktuális rekord pozíció. Használjak TBookmark-ot vagy Locate eljárást? A generátorokkal meg az a baj, hogy a szerver oldalon előállíott értéket nem látja a Delphi komponens, csak újranyitás után. Hogy csinálják ezt a gyakorlatban?
    Mutasd a teljes hozzászólást!
  • Azt hiszem rosszul emlékeztem. Van egy Session nevű globális változó (a dbTables unitban), ha minden igaz akkor ennek a netfiledir protpertyjét kell állítani. Ha ez sem akkor több ötletem nincs...
    Mutasd a teljes hozzászólást!
  • Megpróbáltam, de valamit rosszul csinálok, mert így el sem indul.
    netfiledir: hálózaton ahol a táblák is vannak
    privatedir: c:\temp
    active: true
    sessionname: s1
    database komponensnél sessionname: s1
    Mutasd a teljes hozzászólást!
    Csatolt állomány
  • Delphihez nézd meg a Firebird-et.
    Könnyű száraz érzés, ingyenes, letölthető, és kb. ugyanaz, mint az IB.
    A dbX kontrolokat többen szidják, nekem 6 gépes hálón semmilyen problémám nem volt még. Igaz, csak a DbEditet, és DbLabelt használom.
    A beépített IB komponenseket is használhatod nyugodtan, az IBQuery-t lekérdezésre és adatmanipulációra egyaránt, az IBDataset-et pl. DBEdithez.
    A trazakciókat mindig kézzel nyisd és zárt, így mindig tisztában leszel a helyzettel.
    Mutasd a teljes hozzászólást!
  • hát semmi sem lehet tökéletes, még MsSql-sem, de ez van .
    100 megát mára azért nem olyan nagy gond letölteni, mint azokat a szolgáltatásokat pótolni ami egy kisebb engine-ből hiányoznak,
    sajnos ez tele van kompromisszumokkal .
    ha jól tervez valaki, akkor debugolás nélkül símán meglehet oldani többszáz sorosat is , csak néha így:
    Mutasd a teljes hozzászólást!
  • A gond akkor van a 100 megás MSDN-nel (ami az SQL Server Express verziónál már nem egészen annyi) ha letölthető trial verziót akarsz csinálni... A Firebird ebből a szempontból jobb, ugyanakkor elég csökött a programnyelve, és elég kínos a debuggolása, ráadásul a .NET-es providere eléggé az alfa állapot környékén leledzik... Őszintén szólva egyébként nem értem hogy a Borland anno miért nem tudott alapvető dolgokat betenni az Interbase-be, mint Pl. alapvető stringkezelés, logikai műveletek, stb. Persze UDF-ben mindent meg lehet csinálni, de egyszerűen nem tudom miért nem lehet ez defaultból a rendszer része, még egy szutyok MySQL is megveri ezen a téren szegény Interbase-t pedig ezért anno pénzt kértek (a 7-esért most is, de azt nem tudom mit tud). Ezen anno rengeteget bosszankodtam.

    Kisebb tárolt eljárások debuggolás nélkül is elvannak (bár egy jó null egy query eredményeképp jó kis effekteket tud produkálni), de egy összetettebb tárolt eljárás (> pár száz sor) már meglepetéseket okozhat.
    Mutasd a teljes hozzászólást!
  • Elég rég csináltam ilyet (úgy 10 éve) de ha jól emléxem a TDatabase-hez rendelni kell egy TSession-t, neki van egy netfiledir és egy privatedir propertyje, az előbbinek egy olyan hálózati drive-on lévő alkönyvtárra kell mutatnia ami az összes programpéldánynál, minden gépen közös (és ide teszi le paradoxusrs.lck fájlt), míg a másik a te helyi drive-od valamelyik alkönyvtárára (Pl. temp könyvtár) mutat. De nem 100% hogy ez teljesn így van, valami ilyesmi rémlik a múltból. Mostanság Firebird-nél gyengébb eszközökkel nem nagyon kezelek adatbázist...
    Mutasd a teljes hozzászólást!
  • Egy kis segítséget szeretnék kérni.
    Írtam egy progit, ami dbf-ekbe dolgozik. Többségében SQL lekérdezéseket és utasításokat használok. Az a problémám, hogy egyszerre csak egy ember tudja használni, mert amint indít egy lekérdezést, létrejön többek között egy paradox.lck és egy paradoxusrs.lck file, gondolom ezek zárolják a táblákat.
    Ha valaki tud kérem segítsen! Kösz, előre is!
    Mutasd a teljes hozzászólást!
  • Persze hogy nem teljesen, mert kb. napokig lehetne ezen eszmét cserélni , és akkor sem lenne mindenkinek tökéletesen igaza vagy nem igaza.
    Az tény hogy csököttek ezek a tárolteljárás nyelvek , de igazából ha jól csinálod az tervezést, meg már évek alatt összeírkáltál hasznos függvényeket, akkor rájössz hogy azért ez is elég, ha valami nagyon gáz xp-t is írhatsz mondjuk c-ben.
    Ha az MSDN is elég akkor az csak 100MB, ha szerver kell akkor egy CD nem okozhat gondot a mai világban.
    A debuggolást régen én is hiányoltam, de rájöttem, hogy az csak a szentbénaságom kompenzálására kell. Most már az is elég ha print-et használok, vagy azt sem. (Pl debug nélkül írtam egy rekurzív sp-csomagot, ami bizonyos korlátok között, de tetszőleges kifejezéseket értékel ki. Nem haltam bele, odafigyeléssel símán kivitelezhető volt.) A debug nélküliség elég jól megtanít egy szintel feljebb léptetni magadat az algoritmuskészítésben. Amúgy meg nem op-rendszert kell írni sp-ben, amire valóban szükség van az tényleg kézbentartható ezekkel is.
    A lényeg, hogy szerintem megéri ez a "kis" hátrány ahhoz a szolgáltatáshalamzhoz képest amire stl és AMeda is utalt.
    Én már beláttam hogy sokkal egyszerűbb úgy írni az alkalmazást, hogy a szerver tartalmazza a teljes "biznisz lóógikát" az alkalmazás csak megjelenít, és ezzel még azt is eléred, hogy tetszőleges nyelven és os alatt írhatsz felületet az adatbázishoz.
    Persze ez nem törvény mindenki képességei és igénye szerint ossza fel magának, hogy mi a legjobb neki ha gondolja próbáljon ki meindent, amit csak akar, én csak elmondom, hogy kipróbáltam, de jobb megoldást is találtam.
    Mutasd a teljes hozzászólást!
  • Viszont jogosultság és sql injection tekintetében verhetetlen a tárolt eljárás (legalább is MSSQL alatt).
    Én pl. nagyon ritkán (értsd: csak ha feltétlen szükséges) adok jogot a dbo-n kívül bárkinek is a táblákhoz, így egy QA-val felszerelkezett user sem tud kárt tenni vagy hozzáférni olyan adatokhoz amihez én azt nem szeretném.
    Mutasd a teljes hozzászólást!
  • Azért ez így ebben a formájában nem teljesen igaz. Az általam ismert adatbáziskezelőknek (Firebird, Postgresql, MySQL, MSSQL) a tárolt eljárás szintaktikája finoman szólva kissé távol áll egy modern magas szintű nyelvhez képest. Mondjuk .NET-nél már lehet managelt kódot elhelyezni a tárolt eljárásban és az már civilizáltabb dolog, de ezzel együtt sem vagyok a mindent tárolt eljárásba dolog híve - bár volt időszak amikor én is így csináltam a rendszereimet. De ezt Pl. firebirdnél nem könnyű megcsinálni, debuggolni meg még nehezebb. A MS SQL pedig jó dolog de egy CD a telepítő lemeze az express verziónak is.
    Mutasd a teljes hozzászólást!
  • csá!

    Az én szerény véleményem, hogy ha egy kicsit is bonyolultabb adatbázisokat akarsz csinálni (> 2 tábla és > 2 mező ) és egy kicsit sem akarsz magaddal hosszútávon kiszúrni, akkor ráálsz valamelyik DBMS programozásra. Nagyából tökmindegy melyikre, amelyik neked szimpatikus. A delphit, vagy szintén tökmindegy mit, csakis kizárólag a felhasználói interfésznek (GUI) használod. Én már sokkk éve csinálom ezt, az elején én is vacakoltam a komponensekkel (főleg más nyelvi környezetben, a delphit még ifjú titán koromban léptem át), de nem sok értelmét látom ezért hagytam vele fel. Az adatbáziskezelést szerver/kliens architektúrában érdemes és könnyebb is csinálni, tehát mindent SQL parancsokkal és tárolt eljárásokkal. Ez azt jelenti, hogy a szerveren írod meg az alkalmazást és azon alakítod ki a felhasználói interfészt (UI) amit gyakorlatilag parancssorból is tudsz használni (!), és ehhez készíted el a delphi programot, ami lehetőleg semmilyen adat transzofrmációt nem végez csak megjelenít és parancsokat hív meg szerveren.
    Egyik oka a véleményemnek, hogy a DBMS-ek sokkal lasabban változnak mint a nyelvi környezetek, és mindent meg lehet oldani rajtuk, hatékonyak és nagyon sok adminisztratív szolgáltatással segítenek.

    röviden ennyi a lényeg

    szerintem...
    Mutasd a teljes hozzászólást!
  • Az SQL-lt nagyon jól kell tudnod forgatni. Mert Sql-el sokkal gyorsabban el tudsz intézni mindent, mint egy while ciklussal még ha ki is kapcsolod a megjelenítési opciókat.

    Én nagyjából már Delphit csak a megjelenítés miatt, az adatbázismanipulációját már szinte mindig SQL-el. Annyi, hogy nem interbaset hanem MySQL-t használok.
    Mutasd a teljes hozzászólást!
  • En az sql fele hajlok, mert Access-nel is azt hasznaltam, csak kivancsi vagyok az elonyokre/hatranyokra, bevett szokasokra...
    Mutasd a teljes hozzászólást!
  • Egy dolog a lényeg: hogy lehetőleg minél kevesebb adat közlekedjen a kliens és a szerver között. Azaz nem áthúzzuk az egész táblát a hálón, módosítjuk majd visszaküldjük, hanem csak azokat a sorokat húzzuk át amik kellene (where feltétel a query-ben). Aztán ha sok elemet kell feldolgozni úgy hogy nincs interakció a userrel akkor jobb egy update parancs vagy egy tárolt eljárás mint egy while ciklus, edit, post, next jellegű megoldás. Amúgy meg gyakorlat teszi a mestert, meg némi józan parasztész...
    Mutasd a teljes hozzászólást!
  • Hali,

    Nemreg kezdtem el foglalkozni a Delphivel es erdekelne, hogy InterBase hasznalata mellett mikor melyik adatbaziskezelesi "modszert" celszeru hasznalni es miert? Gondolok itt most az sql parancsokra es a beepitett komponens alapu hasznalatra.
    Elore is koszi
    Mutasd a teljes hozzászólást!
Ez a téma lezárásra került a moderátor által. A lezárás oka: T�ma: programoz�s-ELM�LET!!!
Tetszett amit olvastál? Szeretnél a jövőben is értesülni a hasonló érdekességekről?
abcd