"...azzal együtt veszed meg." - arra próbáltam célozni, hogy a MS csinált egy jópár frankó komponenst, vagy csak osztályt, amit több alkalmazásban is használ. Te amikor egy ilyen alkalmazást megveszel, akkor újra és újra megveszed ugyanazt az elemet. Mint a windows, az office, a vstudio, stb. részét. De ez csak piszkálódás volt, igazából nincs ismeretm erről, hogy egy-egy terméknek mekkora része az újrahasznosított bittömeg.
"Adatbáziselérés ADO-val teljesen független az adatbázismotortól" - cáfolnálak. Akkor miért van a Recordset.Support metódus. Ennek pont az a célja, hogy megkérdezd, hogy a provider mit nyújt. Elég alapvető funkciókra tud nemet mondani: AddNew, AbsolutePosition, Bookmark, Delete, ..., Update És még egy kis finomság a helpből: "Although the Supports method may return True for a given functionality, it does not guarantee that the provider can make the feature available under all circumstances. " - vagyis, még akkor sem biztos, hogy mindig menni fog, ha a support rámondta az áment. Erről ennyit.
"Mit értesz az alatt, hogy korlátozott az ODBC? " - a fentiekből látszik. Pl. Nem lehet törölni, felülírni, rendesen lekérdezni, meg ki tudja még mit nem. Ezeket tapasztaltam, text, DBF, Excel állományoknál. Ahol igazából nincs is motor, csak adatok. Persze ha van motor, akkor az biztos löki a dolgokat. De ezekből csak az MS SQL-t volt szerencsém kipróbálni. Ezért is kérdeztem, hogy van-e más tapasztalat valakinél. (Pl. Access.)
Tranzakciókezelés. Adatbázis szinten gondolod ugye ? A MySQL nem támogatja, ha jól tudom, viszont a PostgerSQL igen. Ez hogyan vezérelhető PHP-ből? Nem tudom, csak most tanulom...
(kicsit később) Most az előbb néztem meg egy példaprogit (a Te kedvedért kerestem), ebben szerepel: pg_exec($database,"commit"); Akkor így!
persze ha meg valami bibi van, akkor "rollback".
"Az IIS tényleg nem a legelterjedtebb szerver, de csak emiatt elutasítani?" - na jó nem utasítom al, csak a háttérbe helyezem. Nekem nagyon tetszett az NT/MSSQL/IIS/ASP felállás. Hálás benne programozni, pedig a komponensfejlesztésig még nem is jutottam el.
Nem. Ezek a komponensek az Op.R részei, azzal együtt veszed meg. A komponenseket teljesen mindegy milyen eszközzel éred el, a sebesség ugyanaz, lehet script, VB, C, akármi. A web-programozást nem tekintem különbnek mint akármilyen más alkalmazás fejlesztését. Amikor egy rendszert készítesz a webes felhasználói felület egy lehetőség, a natív win32 pedig egy másik. A funkció attól még nem változik.
Az IIS tényleg nem a legelterjedtebb szerver, de csak emiatt elutasítani?
Adatbáziselérés ADO-val teljesen független az adatbázismotortól, programozni ugyanúgy kell, legyen script, VB, C, java, stb. Ne vegyél MSSQL-t, vegye meg a cég, akinek fejlesztesz. Használj Oracle-t Linux alá, az asszem ingyenes, de a supportot neked kell megoldanod. De egy normális méretű cégnél a szoftverköltség elenyésző a munkabér/konzultációs költséghez meg a hardver árához képest, nem ezen múlik a dolog, szóval az adatbázis kiválasztása elsődlegesen nem ár kérdése.
A VB betyárt nem becsülném le, ha tényleg betyár, akkor alig van olyan dolog, amit ne tudna megírni, az is az eszköz korlátai miatt van (pl. elég macerás több szálat indítani VB-ből). Neked okozott már problémát ez a korlát? Az, hogy sok koca-programozó is VB-t használ, az gondolom amiatt van, hogy az alapokat könnyű megtanulni.
Mit értesz az alatt, hogy korlátozott az ODBC?
Viszont nem reagáltál még a tranzakció kezelésre. Az ASP oldal is része lehet egy tranzakciónak, vagy ez a funkció nem kell senkinek? PHP és tranzakciókezelés hogy áll?
"Olyat is tudok mutatni ahol Java/Informix van a háttérben. Mutassak? " Persze, kiváncsain várom.
"A probléma ott kezdődik ha a "képben" akarsz keresni. " - gondoltam, hogy ezen a környéken fogsz kilyukadni. Nagy méretű rekordokat "látni" nem igazán lehet SQL-ből. (Biztos vannak szuper kiterjesztések, amikről gőzöm sincs.) De bízom abban, hogy nem is kell, vagy meg lehet kerülni a dolgot. Pl. felindexeled barnaságra is a felvitelnél, ha ez a szempont is kell. Persze ha maguk a szempontok is dinamikusan változnak, az más, akkor meg vagyok lőve. Pl. egy tetszőleges mintát kell keresni.
Mondjuk én eleve nem tenném BLOB-ba, hanem csak filenévre indexelnék és script-ből nyomnám a filet, nem adatbázisból az adatokat. A HTML-eket is meghagynám fileban, és abban kerestetném, oprendszer közeli hívással. Kíváncsi lennék, hogy az adatbázis keresés gyorsabb-e.
"...ami a szerveren fut gyorsabb mintha a kliens oldalon futtatnád meg." No nem a kliensre gondoltam, hanem a Java serverre (ha van ilyen?), vagy a web serverre. Te is írod, hogy csak az db közeli cuccokat tegyük db-be, de akkor mit bízzunk az SQL serverre, amit Java-ban írtunk meg? Mert gondolom tárolt eljárásként futtatva azért nagyságrendekkel hatékonyabb egy db piszkálás, mint Java-ban UDR-ként.
Na mindegy, hátha majd jobban megértem, ha már egyáltalán foglalkoztam a Javával.
> Tudnál jó példákat hozni arra, ahol Java van a háttérben a szerver oldalon? Mármint ilyen site-okat ? Sokat ?
Aha:) Olyat is tudok mutatni ahol Java/Informix van a háttérben. Mutassak?
> Milyen típusokra gondolsz ? Mire jók ezek ?
Példa: adva van egy kép-galéria, és az a feladatod, hogy ezt benyomjad egy DB-be, egyetlen (számottevő) funkcionalitást kell megvalósítanod, ti. keresést a képekre. A tárolás maga nem probléma (BLOB). Amíg olyan dolgokra kell rákeresned, hogy szerző, kép címe, dátum, stb. nem probléma, fogod és felindexeled. A probléma ott kezdődik ha a "képben" akarsz keresni. Pölö: "keress olyan képet a galériában ahol a barna szín a domináns" - fordítsd le ezt nekem standard SQL-re:) Nem fog menni mert BLOB-ok tartalmába nem tud belenézni az adatbáziskezelő. De elmondhatom a fentit XML, HTML dokumentumokra is: csinálj egy dokumentum-tárat, ahol lehet a tartalomra keresni. (Persze nem varchar, meg char - annál nagyobbak a doksik). Na, iIyen típusú feladatokra jó az ORDBMS...
> A másikat jól értem? Javát futtat az SQL server?
Igen.
> Tárolt eljárásként, vagy hogy?
Majdnem. Annyi a kül., hogy a tárolt eljárás az futtatható kód, az UDR (User Defned Routine) az osztály: C, C++ esetén DLL, SO Java esetén meg Java class. Na meg persze a tárolt eljárások nyelve elég primítiv nyelv - legalábbis az Informix SPL egyszerű BASIC alapú nyelv, az Oracle-t (PL-SQL vagy mi) nem ismerem.
> Hatékony ez így, ha az SQL server kicsit több mint adatbázis szerver ?
Hát általában, ami a szerveren fut gyorsabb mintha a kliens oldalon futtatnád meg. Mondjuk szükséged van egy spéci aggregátum függvényre, mondjuk ki akarod számolni egy oszlopban az átlagtól való köbös eltérést (nem akarod, de a példa kedvéért tegyük fel mégis:)) Most akkor melyik a jobb: írni egy Java rutint, ami a szerveren fut meg (SQL lekérdezéssel mindenestül) vagy letölteni a táblát a kliensre és ott elvégezni a számítást?
Van valami párhuzamosítási lehetőség is, ezt azonban marhára nem értem:)
> Vagy csak adatbázis elérés közeli dolgokat érdemes így benyomni az adatbázisba ?
Hát szerintem általában rossz megoldás ha a (magasabb szintű) API-kat az adatbázisba nyomod be. Szal, DB-be szerintem is adatközeli, alapszintű rutinokat kell berakni, a többi megyen a middleware vagy kliens oldalra...
A vitatott témában (mit is használjunk?) találtam egy cikket, ami TRIKÓ malmára hajtja a vizet. Egy cég ecseteli, hogy miért és hogyan tért át NT/IIS/MSSQL platformról Unix/Apache/Java/Oracle környezetbe. Elég tanúlságos. Itt olvasható!
TRIKÓ: Köszi a választ! A Java-t nem törlöm a listámról, de nem ugrom rá rögtön. Nyűgjeim vannak vele. Igaz én csak a kliens oldali programokat ismerem, azokat is, csak felhasználói szemmel, de nem csípem őket. (Nagyok, lassúak, böngésző inkompatibilisek) Hogy szerver oldalon mit lehet vele? Biztos sokat! Majd meglátjuk egy-két hónap múlva.(Remélem a C++-ból tényleg csak felejteni kell hozzá :))
Tudnál jó példákat hozni arra, ahol Java van a háttérben a szerver oldalon? Mármint ilyen site-okat ? Sokat ?
Informix: profinak tűnik. Jól hangzanak a pluszok. Bár én nem járok ilyen szinten, hogy az izgatna, hogy a saját adatípusaim hogy integrálódnak a szerverbe. Többnyire elboldogulok az alaptípusokkal, vagy az azokból átnevezett sajátokkal. Milyen típusokra gondolsz ? Mire jók ezek ?
A másikat jól értem? Javát futtat az SQL server? Tárolt eljárásként, vagy hogy? Hatékony ez így, ha az SQL server kicsit több mint adatbázis szerver ? Vagy csak adatbázis elérés közeli dolgokat érdemes így benyomni az adatbázisba ?
Akkor meg miért nagy szám, hogy Javában írod ?
Hol a határ ? Konkrét példa ?
XML: Igen, ez nekem is néma csend. De nem sokáig !
Bocs, ha hülyéket kérdeztem. Bocs, hogy nyaggatlak. De örülnék ha válaszolnál.
vbela:
Igen, igen, igen. Ez mind szép és jó. Az MS jól kifundálta és jó sok pénzt is keresett vele. Gondolok arra, hogy biztos egy csomó olyan "gyári komponens" van amit egy jópár programmal együtt mindig meg is veszel. Újra és újra.
Na most azt nem értem, hogy ha megtanultál a Visual Studioval programozni, akkor nincs értelme mást tanulni. Az attól függ! Ha egy Visual Basic betyárral van dolgunk, aki néhány kattintással összedob egy windowsos progit, akkor szerintem van még hova fejlődnie. Ha persze valaki A MFC-t ismeri forrás szinten, bitről bitre, akkor bocsánat, hogy élek.
Meg én most nem tisztán programozói szemmel, hanem web programozói szemmel nézem a dolgot. Az pedig tény, hogy az IIS igencsak kisebbségben van, és egyre jobban kisebbségben lesz az interneten. Az általad képviselt irányzat pedig erősen kötődik hozzá és az NT-hez.
Még valami. Próbáltam már többféle adatbáziskezelővel ASP-s alkalmazást írni. Egyedül a MS SQL-lel sikerült. A távoli (másik gépen futó) pl. RDB elérés tetű lassú volt, az egyéb ODBC-s elérés (DBF,?) , pedig annyira korláűtozott a funkcionalitásban, hogy gyakorlatilag semmire sem használható. Tehát vegyek MS SQL-t ? Kicsit drága nem ?
Erről jut eszembe Access tapasztalata van valakinek? Mit tud az ASP az Accessel ? Támogatja az összes ADO-n keresztüli hívást? Persze tudom az Access az csak játék, nem SQL szerver. De azért mégis ?
A meglevo komponenseknel az Op.R-hez vagy a fejleszto kornyezethez adott komponenseket ertettem, szoval nem kell utanajarni. Ha programoztal egy ideje pl. a Visual Studioval, akkor nincs ertelme megtanulni mas nyelvet, hiszen abban mar - elvileg - profi vagy. A COM komponenseknek (persze ez lehet akar Java, EJB, Corba is) az a szep, hogy nativ win32 alkalmazasokhoz is hasznalhatod meg webes alkalmazashoz is, szoval a ujrahasznalhatosaga sokkal jobb, valamint az objektumok lehetnek mainframen is, valamint konnyen lehet skalazni a rendszert.
A script/prog nyelvek hasznalata szerintem feladatfuggo, az eppen legalkalmasabbat kell hasznalni.
Volt valami hozzaszolas az Oracle objektumkezeleserol. En ugy tudom, hogy lehet sajat tipusokat (objektumokat) definialni, amit kozvetlenul SQL-bol lehet hasznalni. Nem ertem a middleware emliteset, de javitsatok ki ha nincs igazam.
> Szóval félre a rizsával, mit tudnak ezek? Hol válik el a határ a közepes és nagy alkalmazás között ? Tudnál néhány konkrét példát mondani olyan dologra, amit Java-ban játszi könnyedséggel meg lehet csinálni, de az említett szerver oldali szkriptekkel nem?
[Kicsi,közepes és nagy]
Vannak a mennyiségi adatok: hits-per-day, filesize-per-day, transactios-per-day stb. Mondjuk 1 millió hits az már nagynak számít:)
A másik, hogy mennyire összetett a rendszer. Egy online börze, egy online aukció (ebay) vagy mamut könyvesbolt (amazon) ezek "nagy" integrált rendszerek. Pölö vegyük az Amazont (már amennyire ismerem): itt a mezei kereskedelmi alkalmazás (megrendelés kezelés, fizetés) mögött van online analitika (ti. nyomon követi, kielemzi hogy mit csinálsz és reagál rá), valahol "odabent" pedig adattárház megoldás (az adattár részleteit nem ismerem, csak tudok róla hogy van, feltételezem azonban, hogy a termékek, megrendelések, stb. adatbázisát megspékelték egy üzleti int. rendszerrel).
[Java]
OOP és újrahasznosíthatóság. Egy szkriptet, vagy szkripteket max. sablonként használhatsz újra. A Java osztályokat viszont egy-az-egyben.
EJB - a vizuális ("komponens" alapú) fejlesztést támogatja.
Szal, azt lehet mondani, hogy Javaban tudsz keretalkalmazást, komponenseket csinálni, szkripteknél erre nincs, vagy csak nyögve nyelősen van lehetőség, mármint egy bizonyos kódhossz fellett... Így hirtelen más nem jut eszembe)
- - -
Ha a tanulás szemszögéből nézem a dolgot, akkor az is szempont, hogy Javaban (szinte) mindent megtudsz csinálni: tudsz kliens oldalon programozni, tudsz kliens-szerver módban, tudsz web-kiterjesztéseket írni, van middleware, és be tudod pakolni az adatbázisba (erről ld az lentieket is). Szóval a szkriptelés az röghöz kötött valami (shell szkriptek, javascript, webszerver-szkriptek, stb.) a java azonban általános célú. Magyarán több helyre el tudod adni magad a Java tudásod birtokában.
> Az Informix-et nem ismerem, de gondolom tud mindent, amit egy rendes SQL szervernek tudni kell. Mit tud még ? Vagyis mik a pluszok ? 4GL, utilities, web-es kiterjesztés ? Vagy csak gyors és jó ?
[Pluszok]
Pluszok vannak, jó sok, de 3 dolog az, ami kunszt:) Az egyik az ORDBMS (jó mi:) magyarul: Object Relational Database Management System). ORDBMS, azaz kiterjeszthetőség: user-defiiált adattípusok bepakolása és kezelése direkt az adatbázismotorban. Ilyet rajta kívül (a nagyok közül), csak az IBM tud. Az Oracle middleware megoldással dolgozik (azaz köztes szerverek kezelik le a spéci adatokat és nem maga a motor).
A másik a Java:) Ti. lehetőség van Java kódokat berakni az adatbázismotorba, azaz a szerveren fut meg a kód és nem a kliens avagy middleware oldalon. Ilyen megoldása az Oraclenek is van.
A harmadik az XML-támogatás, erről visza marha keveset tudok:)
Lehetne még beszélni a Javas adatbázisokról, de már így is marha hosszú lettem, na meg ha tovább dumálok, előbb vagy utóbb, FUD lenne belőle:) Ja, annyit az Informix rovására, hogy Magyarországon, sacc per kábé 90%-os az Oracle piaci részesedése...
> Mennyibe fájnak ezek a rendszerek ?
Hát attól függ mire kell... Ha felhasználó vagy és több useres (vagy processzoros) szervert akarsz, nos ahhoz vastag pénztárca kell. Ha csak fejlesztésre kell az olcsó (az Informix fejlesztői liszensze Linux alá, most éppen 50 rongy).
Ami a Javas adatbázisokat illeti, ott van ingyenes demó ill. az Informixé Javas motorja benne van a Sun JDK-ban is, ami ingyenes.
Látszik, hogy van rálátásod a témára. Meg gondolom ezzel foglalkozol főállásban ("kutya kötelesség"). Hálás lennék, ha válaszolnál néhány kérdésemre, mert én még csak néhány hónapja kezdtem ezzel a témával (webes programozás) foglalkozni és jó volna, ha nem kellene felesleges kanyarokat tennem. Távolabbi terveim között szerepel, hogy átnyergeljek erre a területre.
Az NT, ASP-vel nagyjából szakítottam, mert nem tetszett benne, hogy egy olyan szerverhez kötődik, ami drága és kevésbé elterjedt, mint az Apache. Pedig gyorsan tanulható, logikusan felépített, és valóban könnyen fejleszthető, ha valaki tud komponenseket fejleszteni. (Én eddig nem próbáltam.) Van benne fantázia, de jelenleg
a piacnak csak egy kisebb szeletét birtokolja. Igaz ez biztos a pénzesebb szelet. :)
Kézenfekvő volt a Linux / MySQL (...SQL)/ PHP (Perl) váltás. Sokan dícsérik, elterjedt, gyorsnak tűnik. Elég sok viszonylag összetett alkalmazást láttam rajta. Meg a Netcraft-tal lekérdezett, általam ismert site-ok legtöbbjén is hasonló összeállítás fut.
A linux-ba beleszerettem, pedig csak néhány hete ismerem. Eddig semmi gondom nem volt vele. Néhány órás agyalás után mindent sikerült beállítani. Jó, hogy minden csomag frissiben letölthető a netről ingyen.
(Az MS cuccok beszerzéséhez vagy vastag pénztárca, vagy megfelelő ismeretségi kör szükséges.)
De most hallom a te "hited": Informix / Java.
Azt sejtettem, hogy a Java nem maradhat ki az életemből, de még későbbre tartogattam.
Szóval félre a rizsával, mit tudnak ezek? Hol válik el a határ a közepes és nagy alkalmazás között ? Tudnál néhány konkrét példát mondani olyan dologra, amit Java-ban játszi könnyedséggel meg lehet csinálni, de az említett szerver oldali szkriptekkel nem?
Az Informix-et nem ismerem, de gondolom tud mindent, amit egy rendes SQL szervernek tudni kell. Mit tud még ? Vagyis mik a pluszok ? 4GL, utilities, web-es kiterjesztés ? Vagy csak gyors és jó ?
Mennyibe fájnak ezek a rendszerek ?
A válaszokat előre is nagyon köszönöm, és remélem, hogy mások is okulnak belőle.
> Az SQL server pl. nagyságrendekkel többet tud, mint egy ingyenes unixos.
Talán mert Sybase volt eredetileg. Szal nem nulláról startoltak...
> Szóval Linux / MySQL / PHP (esetleg Perl). Én most ebben hiszek.
Csak, hogy újabb "hitvitát" kezdeményezzek...
Linux / Informix / Java - nagy alkalmazásokhoz. Én most ebben hiszek. Ami azt illeti kutya kötelességem...
Linux / mySQL-Postgresql / Python, Tcl, PHP (Perl) - kis v. közepes alkalmazásokhoz. És a PHP a lóláb, mert annak (szemben a Python-nal, Tcl-lel) nincs Java "connectivy-je". Ugyanakkor viszont marha divatos.
Néhány szó a hitvitához. Szerintem mind a két nyelv (vagy inkább technológia) szuper. Lentebb már elég jól kifejtettétek a különbségeket. Én úgy látom, hogy mindekettőben nagyszerűen lehet egyszerűbb és közepesen összetett (mit pl. ez a fórum) alkalmazásokat gyorsan, hatékonyan fejleszteni.
Mégis amikor választani kellett, a php mellett tettem le a voksot. Miért? Nézzétek meg, hogy melyik web server nyomul jobban. Kétségtelenül az Apache.(http://www.netcraft.com) Min ? Unix-on.
És akkor már helyben is vagyunk. Egy pár óra alatt, ingyen (!) fel tudsz állítani egy profi unix-os web servert, SQL-serverrel, server oldali script technológiával. Mégegyszer mondom gyorsan, ingyen.
Szerintem jók a MS cuccok is, még az is lehet, hogy többet tudnak. Az SQL server pl. nagyságrendekkel többet tud, mint egy ingyenes unixos. (Bár kérdés, hogy egy kis web-es alkalmazásnál kell-e?) Még azt is megkockáztatom, hogy az utóbbi időben egész jó a minőségük.
A COM, ActiveX, ADO... pedig telitalálat. Frankón átjárható az egész windows-os miskulancia. De mennyit kell ezért perkálni, ha legálisan csinálod ? NT server, SQL server, Visual Studio. Ugye, ugye ?
Szóval Linux / MySQL / PHP (esetleg Perl). Én most ebben hiszek.
> Viszont hozzátenném, hogy IIS esetén valószínűleg mindenféle COM-komponenseket alkalmaznék, ha csak lehet, aminek a futási sebessége lényegesen gyorsabb, mint egy script nyelvé.
Annó olvastam egy összehasonlító tesztet: rsz. prog. nyelvek kontra script nyelvek. Ugyanaz volt a prg. feladvány, oszt: kódolás-idő-, kódhossz-, futásidő-, memória igény-, megbízhatóság-, stb. teszt. A nyelvek közt volt C, C++, Java, Python, Perl, JavaScript, stb. Csak azért említem, mert a teljesítmény teszt eredménye meglepő volt: a scriptek alig maradtak el a prg. nyelvek (C, C++) mögött. Ha érdekel előkeresem a címet...
> Meglévő komponensekkel meg gyakorlatilag mindazokat a szolgáltatásokat el lehet érni, amit felsoroltál a PHP-hez.
Idő (utánajárás: komponensnek, doksinak), pénz (ha nem találsz ingyenest).
Akárhogy is egy erős standard library vonzereje nem lebecsülendő, nehéz neki ellenállni - én pölö 2 kézzel fogom vissza magamat, nehogy php-ben kezdjek fejleszteni:) (Alapvetően Javas vagyok, és hiába, Java az nincsen a PHP-ben)
Na végre, ez az összehasinlítás már ér valamit. Köszi.
Nem tagadom, hogy árukapcsolás, de akkor is ingyen van, és a w2k már alapból tartalmazza. Egy nagyobb cégnek meg ugyan mindegy, hogy meg kell venni 1 db szerver licencet a webszerver miatt, a gép ára többszöröse az op.R-ének.
Viszont hozzátenném, hogy IIS esetén valószínűleg mindenféle COM-komponenseket alkalmaznék, ha csak lehet, aminek a futási sebessége lényegesen gyorsabb, mint egy script nyelvé. Meglévő komponensekkel meg gyakorlatilag mindazokat a szolgáltatásokat el lehet érni, amit felsoroltál a PHP-hez. Aki meg VB-hez szokott, annak meg elég egyszerű VBScriptre átállnia.
Továbbá nem hinném, hogy lebecsülendő volna az automatikus tranzakciókezelés vagy pl. a kliensoldalról "közvetlenül" elérhető adatbázis lehetősége, bár kevés gyakorlati megvalósítást láttam rá eddig.
> hiába van benne az NT/IIS-ben az nem más mint árukapcsolás
Ezt pesze az ASP-re mondtam.
Megjegyzem, (ha már nekiláttam kiigazítani magamat), hogy vannak szolgáltatók, akik ingyen tárhely mellett, ingyen ASP szolgáltatást adnak. Ha tud valaki hasonlót PHP (vagy Perl, Python, Tcl)-ügyben és a címet ide beírná, nos azt borzasztóan megköszönném neki:)
> minek fizessek súlyos pénzeket az ASP-ért? Amikor xarabb?
Ha a pénz számít a PHP télleg olcsóbb (hiába van benne az NT/IIS-ben az nem más mint árukapcsolás), lévénhogy a PHP teljesen ingyenes.
Ami a "xarabbat" illeti, ez, már meg ne sértődj tré beszólás volt...
Sokféleképpen lehet összehasonlítani a két nyelvet (habár az ASP nem is nyelv, hanem egy technológia szkriptek beágyazására, ill. néhány előredefiniált objektum): egyszerűség, API-khoz szükséges kódmennyiség, idő, sebesség, standard library, kiterjeszthetőség, stb.
Ami a technológiát illeti (alkalmazás beágyazása HTML lapokba), nem látok lényeges különbséget PHP, és ASP között.
A gyorsaságon lehet vitatkozni - ezzel szemben tesztelni kellene:) Nem tudok ilyen tesztről Apache-CGI kontra IIS-CGI tesztről már hallotam, (ott az Apache volt a nyerő), viszont Apache(v. IIS)-PHP kontra IIS-ASP tesztről még nem.
Az egyszerűség izlés kérdése, a magam részéről itt se látok lényeges különbséget.
A standar library és kiterjeszthetőség szempontjából érdekes a szituáció:
A PHP standard könyvtárat össze nem lehet hasonlítani az ASP-vel, előbbi sokkal erősebb. Az ASP ezen a téren szinte nulla: össz-vissz 4 objektuma van előredefiniálva (session, aplication szintű kezelés ill. response, request a page kezeléshez), ill. ehhez jönnek még a VBScript/JavaScript beépített könyvtárai. Ezzel szemben a PHP-ben minden, ami fontos ott van: vannak FTP, POP3, LDAP, NNTP, függyvények, adatbázismanipuláló könyvtárak, reguláris kifejezések, socket kezelés, stb.
A kiterjeszthetőségnél fordított a helyzet: PHP-nél dunsztom nincs hogyan lehet egyszerűen modulokat fejleszteni (gondolom C-ben), ezzel szemben ASP alatt triviális és sokoldalú lehetőség van kiterjesztésre: egyrészt adva van az ActiveX alapú fejlesztés (lehet mondani ez windoz-specifikus, de az ASP, amúgy is elsősorban windoz) ill. adott a Java alapú fejlesztés (ez persze windoz-független). Viszont akár Java-ban, akár "ActiveX-ben" (C++, VisualBasic) fejlesztesz osztályokat, a beágyazást az ASP lekezeli marha egyszerű módon. Nem tudok róla, hogy PHP-ben ennek meglenne a párja.
Ami a fejlesztés idejét, szükséges kódmennyiséget, stb. illeti, val. a PHP viszi el a pálmát amíg egyszerű, közepes és standard alkalmazásokról van szó. Nagy alkalmazásokat se PHP-ban se ASP-ben nem fejleszt az ember:) Tehát maradnak a nem standard alkalmazások.
Tény azonban, hogy mivel marha sok minden eleve be van építve a PHP-be, nehéz nem-standard alkalmazást találni...
> Trikó: a Java már rég halálra ítélt nyelv...
Félreinformáltak. Pillanatnyilag max. az lehet a kérdés, hogy az IBM (HP) télleg megbuktatja -e a Java2-t vagy sem. Maga a Java él és virul, mint állás, pediglen a legkeresetebb programozói állások közé tartozik.
Ha megveszed a Win oprendszert, akkor az IIS-t is ingyen letoltheted. Szoval az ASP is ingyen van.
Egyebkent nem gyoztel meg arrol, miert olyan vacak az ASP.
Nem rég kezdtem el foglalkozni a php-val és az a véleményem , hogy ez a legjobb. Könnyű megtanulni, ingyenes, gyors stb. Egy kicsit beástam magam a témában a neten és egy hét olvasás után olyan programot írtam, ami működteti a websiteomat. Egyébként érdemes megnézni, szerintem jó referencia :) (www.surf.to/gabs33) A weboldalt ingyen írtam (php3) és ingyenes szerveren van. (még reklám sincs!! - csak a surf.to miatt...) akkor + minek fizessek súlyos pénzeket az ASP-ért? Amikor xarabb? (Trikó: a Java már rég halálra ítélt nyelv...) Aki nem ért velem egyet, az írjon nyugodtan, kíváncsi vagyok az ellenérvekre is! Ha kell segítség a magyar tutorialhoz, szóljatok, van egy két használható címem és anyagom! Csinálhatnánk esetleg egy komolyabb PHP oldalt! (ilyen még úgy sincsen M.O-n) Na sziasztok: G
A PHP anyag engem is érdekelne. Nekem is van még egy kettő, ha megkapnám az anyagot, akkor összeraknám a többivel és felraknám a http://krea.bke.hu szerverre, ahol falu kollégával egyébként is egy PHP3 fórumot kívánunk indítani. Ha nem túl nagy a cucc, akkor becsatolva elküldheted a korsos@freemail.hu címre, vagy csak küldj egy értesítést, hogy hol van, majd én leszedem.
Az ASP többféle szkript nyelvvel tud együtt működni (azért vannak megkötések). Defaultként a szerverben benne van a VBScript, JScript, de mehet PerlScript, REXX is, feltéve hogy a hozzátartozó scripting engine telepítve van. Mármost, ami a JScriptet illeti, hát nem tudom, mérföldekkel áll közelebb a C-syntaxhoz mint a PHP...
> kitalaljak, hogy platformot valtunk (aaaa, nem ilyen meg senkivel nem tortent), akkor birom vinni magammal amit eddig csinaltam.
Van Linux, Solaris portja: Chili (www.chilisoft.com) sőt elvileg akármilyen platformon futtatható, lévén van Java implementációja is (www.halcyonsoft.com)
Hat nem is tudom, bele kellene-e menni egy ilyenbe, sokat, hidd el sok mindent. Es meg tobbet fog tudni. De ez egy olyan hitvita, aminek semmi ertelme, mert nyilvan az ASP is sok olyat tud, amit a PHP nem.
Hozzam egyszeruen kozelebb all a C-style syntax, es megnyugtat a tudat, hogy ha a rendkivul hozzaerto project managereket holnap egy trainingen eppen egy masik vendor ebedelteti meg, es kitalaljak, hogy platformot valtunk (aaaa, nem ilyen meg senkivel nem tortent), akkor birom vinni magammal amit eddig csinaltam.
Az IIS konfigurálásánál beállítottam neki, hogy a php3 kiterjesztésű fájlokra a php-t hívja meg, ugyanígy paraméterezve, de akkor sem akart működni.
Elküldöm Neked mail-ben a php3.ini-t, hátha Te észreveszel benne valami bibit.
