Fórumok
Sziasztok!
Melyik adatbazist javasolnatok, es mert? Nem feltetel az ingyenesseg. (Oracle,MSSQL,PostgreSQL,Egyeb)
Es melyik programnyelvet erdemes valasztani a fejleszteshez (java,php,delphi,egyeb)?
A project, (ha egyatalan lesz) 1-2 ev tavlataban, jelenleg a lehetosegeket kutatom. Java+Orcle parost nezegettem, vagy erdemes az Oracle appserveret, vagy a tomcat is jo lehet ekkora feladatra?
Szerveroldalon nincs megkotes, (linux/win/..). Kliensek jelenleg win-ek.
Egy szolgaltato ceg ugyfel szazezres nagysagrend), szanla, reklamacio, szerzodes.. kezelesehez, nagy tomegu szamla elokeszites, nyomtatasa. Kb. 50-60 felhasznalo, tobb telephely.
Esetleg ugyfelek lekerdezhetnek adatokat interneten keresztul.
Hozzászólások
oracle biztos jó választás, állítólag az ibm db2 is hasonló. Még el lehet gondolkodni a postgresql-en, de ilyen feltételekkel már nem biztos, hogy megéri.
Ha úgy írod meg az oldalt, hogy nem használsz kiszolgáló-specifikikus dolgokat, akkor mindegy, hogy hol futa servlet/jsp, hiszen mindenhol működni fog.
programnyelv - tök 8, bár a php sztem nem ez a kategória, a delphi meg nem igazán portolható...
Ha a kliensek alatt webes felületet értünk.
Java 1.5 v. 1.6 + JBoss 4 + postgresql 8 + linux az egész alá. Apache2 a JBoss elé. Ha ezeket tudod is használni, akkor nem érhet meglepetés. Ez így ingyen van és a strapát is bírja. Ha a várható terhelés kicsi a JBoss helyett mehet a tomcat. Jóval kisebb az erőforrás igénye és kezesebb is.
Én a helyedben Oracle-hez nem nyúlnék egy bottal sem...
Miért nem nyúlnál orahoz? Azt tudom, hogy vannak benne őskövület megoldások, meg "érdekes" megoldások is, de úgy tudom, hogy nagyon stabil és mindenek előtt az adatok biztonsága. Meg vannak olyan szolgáltatásai, amit még a pg sem tud (és ez igaz fordítva is ;-).
A postgreshez van céges support is.
Oracle kapcsán itt két termék merült fel.
Oracle AS
A felmérések szerint a 3 legnépszerűbb AS: Bea WebLogic, JBoss, IBM WebSphere. Ezt a 3-t használják Mo.-n is (legalábbis azoknál a bankoknál (egy kivétellel, de az sem Oracle AS), és biztosítóknál, akiknek a rendszereibe már volt szerencsém betekinteni). Szóval az Oracle AS nyugodt szívvel felejtős.
Oracle DB
Nagyon elterjedt nemzetközileg és nálunk is. Ettől függetlenűl web alkalmazásoknál semmilyen olyan pluszt nem ad, ami okot adna a használatára. Ráadásul, nagy, robosztus és leginkább egy bloatware-re emlékeztet. Adatvesztés? Mi MSSQL-lel (nah az is egy érdekes lény) és PostgreSQL-lel dolgozunk legtöbbet (ofc. Oracle mellett) és még egyszer sem volt adatvesztésünk egyikkel sem. Pedig az ország egyik bankjában (tudod, akiben megbízol) is MSSQL a portál adatbázisa. Adatvesztés ellen inkább hw-esen szoktak védekezni (áram ellátás, biztonsági mentések). Talán brutálisan nagy táblákra (sok-sok millió sor) az Oracle ad valami pluszt, de az ilyen alkalmazások ritkák. Jah és az érdekes megoldásokra pl.: mikor lesz autincrement az Oracle-ben (és most a szekvenciás-before insertes-triggeres bohóckodást ne számoljuk ide)?
lol... Örülök, hogy a mérhetetlen dilettantizmus nem veszik ki soha a szakmából, így nekem legalább mindig lesz zsíros munka... :D
mire valasz ez a troll duma? :)
--
Gabriel Akos
Úgy tudom, a mysql nem tud particionált táblákat. A postgres tud?
Rémlik, hogy olvastam ilyenről. Mit is jelent pontosan?
termeszetesen tud.
--
Gabriel Akos
Hosszabb távon és nagy cég esetén javaslom az Oracle adatbázist.
Rövid távon és kis cég esetén, bármi más csak Oracle nem.
Mivel az adatok biztonsága egy ilyen felhasználásnál előkelő szempont, ezért minimum Postgresql az ingyenesek közül, de gondolom ilyen mértékű felhasználás esetén van pénz az adatbázisszerverre is, tehát Oracle, DB2, stb. Azt már eldöntöttétek, hogy mennyire akartok tárolt eljárásokkal dolgozni?
Ilyen szintű feladatnál egyszerűen meg kellene vizsgálni legalább a három megemlített nagy rendszert és csak komoly támogatással rendelkező ACID adatbáziskezelő jöhet szóba.
A több telephelyre mit akartok? Elosztott adatbáziskezelést vagy állandó online kapcsolattal fog menni? Utóbbi esetben a szoftver központilag lesz, vagy minden telephely sajáttal rendelkezik?
A tobb telephely alando online kapcsolatot jelent (berelt vonal a nagyobbak kisebbek adsl-en jonnenek)
egy kozponti adatbazist gondoltam.
A software kozpontilag lenne, vagy delphi eseten monden kliensen lenne a program, bar ez utobbinak mennyire van jovoje? Igaz nem portolhato, de nem is kovetelmeny.
Szamlazas, adatrogzites idejen eleg sok UPDATE muvelet fog futni, parhuzamosan.
Tarolt eljarasok hasznalata, ha azzal optimalisabb az adott (resz)feladat megoldasa, akkor igen.
Delphi: semmennyire, amúgyis ronda megoldás és sok probléma forrása lesz, ha a kliensek közvetlenül a táblákban turkálgatnak.
Egyébként megjegyzem, hogy lehet van már kész nyílt forrású szoftver a feladatra vagy annak egyes részeire (számlázásra van).
Elég hamar el kell dönteni az alkalmazandó technológiát, módszertant és nem árt rendesen ismerni is azt!
"Delphi: semmennyire, amúgyis ronda megoldás és sok probléma forrása lesz, ha a kliensek közvetlenül a táblákban turkálgatnak"
Ezt kifejtenéd?
Akár web-es, akár kliens-szerver az alkalmazás, mindkét esetben ő írja meg és az ő alkalmazása fog a táblákban turkálni.
Annyi a különbség, hogy a jelenlegi divat ellenére web-es alkalmazásokat ügyvitelre használni nem túl hatékony megoldás több szempontból sem:
- nagyobb adatforgalom
- validáló algoritmusok dupla megírása
- nagyon rossz, lassú kezelhetőség
Szerintem, aki látott már valaha adatrögzítőt dolgozni, biztos nem javasolna web-es megoldást. Esetleg valami kiegészítő lekérdező modult érdemes web-re tenni.
Én az ellen szóltam, hogy a kliensoldal csinál mindent az adatbázist meg csak adatraktárnak (fájlrendszernek) tekintjük. Amikor változik egy tábla és valaki elfelejti lecserélni a klienst már szopás van, nem beszélve arról, hogy ha rosszul írják meg a klienst, akkor sok adat utazik feleslegesen. Egy szóval sem mondtam, hogy webes legyen a kliensfelület.
A "webes alkalmazas" nem egyenlo a html-es klienssel.
Lehet pl OpenLaszloval vagy Adobe Flex-el is klienst irni, es akkor webes is meg "fatclient" is egyszerre.
Automatikusan frissul ha kell, bazi szep, bazi kenyelmes, es megis a szerveren lehet a logika megfelelo resze.
--
Gabriel Akos
Sztem normális adatbázisnál mindent a szerver csinál. Kliensek optimális esetben kérnek select-eket és az adatbázis tárolt eljárásait hajtatják végre. Legalábbis ez lenne üdvözítő!
Üdvözítő lenne, de több probléma is van ezzel.
Az adatbázis-kezelők tárolt eljárásai gyakorlatilag egyáltalán nem hordozhatók, így adatbázis-váltásnál írhatod újra az egész üzleti logikát.
Másrészt vannak azok az esetek, ahol egy beviteli képernyőn egy-két mező értéke határozza meg, hogy a többi mezőnek mi az értékkészlete vagy épp látszik-e egyáltalán. Ilyen esetekben az üzleti logika keményen ott kell, hogy legyen a kliensben. Ha kliens-szerver az architektúra, akkor elég, ha az alkalmazásban van az üzleti logika, néhány kritikus rész esetleg mehet tárolt eljárásba. Több réteg ekkora feladatnál szerintem pocsékolás. Kliens-szerver architektúra több száz kliens felett kezd gázos lenni, de még akkor is tuningolható.
Azért a deployment kérdését se hanyagoljuk el...
Franc akar szívni a kliensek program- és dll-verzióinak egyezőségének ellenőrzésével... A kliens-szerver alkalmazásmodellt jobb lenne elfelejteni már végre...
Elosszor is koszonom a sok ertekes hozzaszolast.
-----
_Joel: Ok, ha a ceg aldoz tanfolyamra, akkor megkereslek pm-ben. Bar ez a 1,5-2 honap elegge irrrealisnak tunik ennel a rendszernel legalabbis.
Mico: Szerencsere nem az en dolgolm eldonteni, de szeretnek azert valamennyire kepben lenni, ha odakerul a sor ne akkor jojjek le a falvedorol :)
-----
Maga a rendszer elege egyedi, s nem a spanyolvi(g)asz ujboli feltalalasa a cel, hanem a meglevohoz modernizalasa.
Ugy latom kliens-szerver vs. alkalmazasszerver eleg szep vallashaboru bontakozuk ki :) En a sajat tapasztalataim alapjan a kliens-szerver felallas tunik szimpatikusabbnak.
Itt a kornyeken fesszegettek meg az MSSQL, C# ezekrol it nem sok hagzott el, ennyire felejtosek?
Itt a cegen belul mar tobb nagyobb alkalmazas is lel lett cserelve a regi dos/fileserver (esetenken dbase) webes, kliens-server, oracle, mssql vegyesen programokra (ezek egy reszet u.a. a ceg szalitotta aki az elozot) ezek nagy tobbsege osszesegeben sokxor lassabbak mint az elodeik, pedig mind szerver, mind kliens oldalon jelentos fejlesztesek voltak. Ez mennyire "normalis"? Remelem ertheto a kerdes.
"ezek nagy tobbsege osszesegeben sokxor lassabbak mint az elodeik"
Azt hiszem, ideje fejlesztőt váltani... Fájlszerveres megoldásnál SQL-nek sokkal gyorsabbnak kell lennie.
Ha váltotok, mindenképp nézzetek meg potenciális cégektől származó alkalmazásokat megnézve a programok reakcióidőit és azok változását egyre több adattal.
szerintem eloszor igeny alapjan dolgozz ki egy kovetelmeny spec-et, aztan ahhoz valassz kornyezetet.
Szerintem mysql is jatszik, en hasonlora most az 5.1-et tesztelgetem es eddig nem talaltam kulonosebb gazt. Viszont a legendas teljesitmenye latvanyosan esik, ha ACID kepes tablaformatumot hasznalsz (mint pl. innodb), szoval "nincs ingyen ebed", nem lesz 100x gyorsabb.
Egyetertek, en is a mysql-re + php-re szavaznek. A mysql-ben is egyre tobb minden bele kerul, a tranzakcioktol kezdve a triggereken at, amittomenmimeg. En is amondo vagyok, csinalj egy specifikaciot, mit kell tudni a rendszernek + neked mekkora van (ugy ertem, a budzsed), es az alapjan az egyes szempontokat sulyozva hozd ki a gyoztest.
ASK Me No Questions, I'll Tell You No Lies
Oracle + .Net
Morzel
szerintem nagyobbak:
Oracle + Java(/?.Net)
Db2 + WebSphere
Postgresql/Oracle/egyeb + JBoss
Oracle (!adatbázis, nem az alkalmazás és pizzasütő szerverei) minden furcsasága ellenére stabil és jól összetákolt rendszer, bár néha tényleg falnak lehet menni tőle :) Érdemes kitapasztalni - ez sok idő és tanulás - mert nagyon mellé lehet nyúlni vele teljesítményben. Viszont a pl/sql és java kedvelése nem rossz dolog, csomagok, tárolt eljárások, triggerek stb., valamint kiegészítők (érdemes enterprise verziók felé kacsintani) - viszont webes része szerintem sem elég bejáratott még.
A "nagyok" kategóriából sokak szerint csak az mssql lóg ki - bár ezt mások cáfolják :) - főleg milliós rekordszámoknál, de ehhez nem értek, csak hallottam többektől pl. erp-vel kapcsolatban oracle vs mssql témában.
Db2 talán kevésbé van szem előtt, de szintén nem rossz, Postgresql ingyenessége mellett egyre kiforottabb lesz, ráadásul tele jó ötletekkel, viszont érdemes ezt is jól megismerni, mert tud kellemetlen perceket szerezni.
En meg mindig a Glassfish + (Open)Solaris + Postgresql hármast használom, ahol csak tudom, és bejön (bar van ahol Winen fut Glassfish es MS SQL a backend, igazabol tokmindegy fejlesztoi szemszogbol). Fejlesztéshez a JPA (Java Persistence API) + Wicket (wicket.sourceforge.net) lett a "company standard", hol EJB3 stateless session bean reteggel egy .ear-ban, hol meg siman csak egy web application-kent egy .war-ban. Szolj, ha erdekel tanfolyam vagy konzultacio a temaban, tudok ra adni arajanlatot. Egy uj alkalmazas fejlesztese a fenti eszkozokkel 4-5 entitas CRUD-szeru admin kepernyoivel + 3-4 custom funkcionalitassal, pdf generalassal (erre iText-et hasznalunk), excel import/export-tal (jExcel api) kb 1,5-2 honap 2 frissen betanitott emberrel...
Szerintem elég jó irányba kezdtél nézelődni.
Ha ez egy százezres ügyfélkört kezelő rendszer, akkor biz nem árt, ha biztosan megy, ergo nem árt hozzá a support, és valószínű, hogy pénz is akad rá.
Innentől egyértelmű, hogy Oracle, vagy DB2 a neked való db platform (részemről Oracle párti vagyok, de ez már valamennyire ízlés dolga is). Mondjuk az IBM "vendor locking" tekintetében eléggé erős IMHO, főleg ebben az országban, ami nem túl pozitív...
Alkalmazás fronton mindenképp javaslom, hogy J2EE alkalmazásként valósítsd meg az egészet, a szabványok messzemenő betartásával (ha lehet, kerüld a JBoss/tomcat/akármi specifikus hívásokat). Ha így jársz el, bátran gondolkozhatsz később is az alkalmazásszerver megváltoztatásán, ha netán az eredeti választás valami miatt (teljesítmény, skálázhatóság, ár) a végén mégsem tűnne annyira kifizetődőnek... Ha így fejlesztesz, mindegy, milyen J2EE alkalmazásszerveren futtatod a rendszert, mindenképp mennie kell.
Amit még javasolni tudok, hogy szép dolog az adatbázisfüggetlen kód írása Java-ban, de ezt már kevésbé javaslom. Ha kiválasztottad, milyen adatbázist szeretnél használni, akkor gondolkozz el azon, melyek azok az üzleti funkciók, amiket érdemes tárolt eljárásként megvalósítani.
Tipikusan baromira nem érdemes valami nagy iterációs feldolgozásnál az alkalmazásszerveren példányosítani sokmillió objektumot, azoknak az adatait értelemszerűen jópárszor oda-vissza megjáratni a hálózaton (pláne ha EJB, broáf), amikor mindez elintézhető az adatbázison belül is, három kurzort (recordset-et, ahogy tetszik) nyitva tartva...
az adatbázis-független kód valamelyest megoldható, méghozzá úgy, hogyha a használt objektumokról teljesen le van választva az adatbázis-hozzáférés, vagyis külön rétegbe kerül. Ha valamiért nem jó az a kód, ami adott adatbázisszerverhez megfelelő volt, akkor még mindig le lehet róla választani az implementációt, anélkül, hogy a kód többi részét érintené.
én vagyok a hülye valszeg, de mi a baj a:
debian + mysql + php megoldással?
Debian:
- Nincs támogatás. És itt ne arra gondolj, hogy elakadsz és nincs kitől kérdezni, mert van. De vmi miatt a te vasadon az épp frissített kernel mondjuk nem megy. Mondjuk kénytelen vagy mégis, biztonsági okokból frissíteni. Csinálsz magadnak backport fix-et az előző kernelverzióhoz? Sajnos láttunk már ilyet. És ilyenkor vagy megcsinálod magadnak, vagy vársz, hogy hátha a következő, ki tudja mikor érkező frissítés majd jó lesz.
mysql:
- Már bocs, de az egész mysql skálázhatóság, használhatóság, és funkciók tekintetében is egy vicc, ha egyszer az életben dolgoztál már rendes adatbázison. Elhiszem én, hogy jó hobbi, de semmi több. Akinek százezres ügyfélköre van, az már tényleg áldozzon egy tisztességes adatbázisra, annak már ez nem tétel.
A mysqlnek gyakorlatilag semmilyen működő válasza nincsen a nagy szervezetek igényeire.
php:
- Ez már inkább ízlés kérdése. Akár alkalmazható is lenne, de a skálázhatóság azért itt sem annyira jó, mint manapság egy Java alkalmazásnál. Persze az is igaz, hogy mindkettőt el is lehet rontani, és akkor bármelyikre rá lehet sütni, hogy lassú sz*r...
Nagy, összetett rendszer készítésénél viszont a Java erős típusossága, és sok más kötöttsége azért nagyban növeli az átláthatóságot.
debian (alias kernel): vannak konzultacios cegek, amelyek segitenek, ha kell. Bar imho egy par eves rutinnal rendelkezo unix admin szamara ez nem lehet gond - legalabbis nekem meg nem volt.
mysql: imho http://www.mysql.com/why-mysql/toptenreasons.html url-en azert nem rossz feature-ok vannak
ASK Me No Questions, I'll Tell You No Lies
Debian: jó dolog, de support nélkül...
mysql: teljesen más kategória, arra való, hogy sql "fájlrendszerként" viselkedjen nagyforgalmú, elsősorban nem kritikus weboldalak mögött. Ilyen üzletkritikus rendszerekhez nem való, márpedig egy százezres nagyságrendű ügyfélkört lekezelő rendszer üzletkritikusnak számít. Az üzletkritikus azt jelenti, hogy a szoftver illetve a rendszer hibája komoly anyagi és üzleti kárt tud okozni az azt használó vállalkozásnak és az ügyfeleiknek.
php: a mysql-nél kifejtettek igazak rá. Nem való üzletkritikus rendszerbe.
"php: a mysql-nél kifejtettek igazak rá. Nem való üzletkritikus rendszerbe."
Ez azert nem igaz, lasd SugarCRM, Asterisk, eGroupware, stb...
Az viszont igaz, hogy rengeteg ganymester PHP programozo van, akik rontjak a PHP "hirnevet".
A Javaban irt dolgokat sokkal nehezebb elrontani.
Igazan jo programozo PHPban is tud jo rendszert csinalni (lehet kicsit nehezebben mint Javaban).
De az ilyen szintu PHP programozo nem olcso, egy arban van a hasonlo kepessegu Javassal. :)
--
Gabriel Akos
"Az viszont igaz, hogy rengeteg ganymester PHP programozo van"
Kezdve a php fejlesztőivel. Nincs rendes dokumentáció, folyton csak foltozgatnak átalakítanak valamit, kivesznek dolgokat és egy verziófrissítés után borul az alkalmazásod is. Ha komolyabb dolgot akarsz, akkor könnyen előfordulhat, hogy nem tudod elkerülni az operációs rendszer függő dolgok használatát. Nagyon széthúzó a köréje épült világ: ezerféle megoldás van ugyanarra a feladatra, de egyik sem az igazi, vagy lehet, hogy találsz egy jót, de nem biztos, hogy 1-2 év múlva is ugyanolyan jó lesz. stb. ezek miatt utáltam meg a php-t.
A hozzászólásod többi részében gyakorlatilag leírtad azt, ami miatt nem jó kritikus rendszerekhez a php.
Debian support nélkül? HP nem mostanában erőlteti nagyon? (közben atyja szép lassan átvándorol Solarist jobbítani :P )
Mysql-t nagyobb rendszernél én sem szívlelném (pedig meglepő, miket próbálnak "varázsolni" vele :), viszont Postgresql-t már igen - lehet hozzá támogatást kapni, tud tranzakciókezelést, beágyazottakat, illeszthető több nyelvvel stb.
Php minden flame nélkül egy nagyon gyors fejlesztést lehetővé tévő nyelv, de nagy rendszereknél valóban zűrös lehet a doksi, átgondolatlanságok stb. Érdekes, hogy más szkriptnyelv (perl, python) nem igazán került szóba, pedig ennyi erővel akár lehetne.
Szabványos kontra specializált megoldásoknál mindig érdemes megfontolni, kik fogják fejleszteni, meddig és milyen supportot kell hozzá biztosítani, megéri-e a teljesítménytöbbletet a speciális kód? Ha fontos, hogy még jópár évig kapj hozzá fejlesztőt, akkor én is inkább Java/.Net alapú megoldást javasolnék, ha viszont nagyon kell a teljesítmény, akkor pl. Oracle PL/SQL szintig legalább érdemes lemenni objektumalapú varázslatok helyett.
Eloszor valaszolok konkretan a kerdesre, aztan mondok mast :)
Programnyelv: Java
Adatbazis: PostgreSQL
Ekkora feladatot mar szokas 3 retegu architekturaba szervezni, azaz egy alkalmazasszerver is jatszik. Erre JBosst ajanlok.
Az Oracle mint RDBMS jo lehet, bar en tobb hatranyat latom mint elonyet.
Appservernek az Oracle IAS egy vicc, okadas, bugos, felejtos. Barmi mas jobb mint az IAS.
Egyebkent meg a feladatra van "kesz" megoldas, csak adaptalni kell. Valoszinuleg olcsobb-gyorsabb-jobb megoldas mint a 0-rol kifejleszteni ismet (feltalalni a kereket/spanyolviaszt). A dolgot ugy hivjak hogy ERP rendszer. Konkretan az Adempiere-t ajanlom, ami open source. Telepitesben, testreszabasban tudunk segiteni, ha erdekel keress meg maganban.
--
Gabriel Akos
Mindenki aki a PHP/MySQL/Debian kombót ajánlotta pakoljon össze és menjen vissza kernelt fordítani. Ez nem a ti topikotok :)
Az original posternek pedig: ha a te hatásköröd eldönteni, hogy milyen technológia lesz használva annak ellenére, hogy ennyire nincs tapasztalatod, akkor nagyon-nagyon szomorú vagyok. Ha csak kívülállóként érdeklődsz, akkor bocs.
Hogy konstruktívat is tegyek hozzá: szerintem ilyen jellegű munkához teljesen sux a webes kliens. Rich client esetén lehet .NET-ben meg Javában gondolkozni. Mind a kettőnek megvan a maga szépsége és a maga baja. Nem értek egyet abban, hogy mindent az adatbázisba kell beledrótozni, mert ezzel nagyon hamar vendor lock-inben találod magad. Érdemes úgy csinálni, hogy adott esetben az üzleti logika basztatása nélkül hozzá lehessen tenni egy webes/mobil/stb felületet, vagy valami teljesen mást.
De ha több százezer ügyfélről van szó, akkor esetleg lehet venni kész ERP-t is?
"Mindenki aki a PHP/MySQL/Debian kombót ajánlotta pakoljon össze és menjen vissza kernelt fordítani. Ez nem a ti topikotok :)"
Ez kemény beszólás volt, de igazat kell adnom neked.
ms sql 2005 + .net