Vlákno názorů k článku Linuxová kancelář a správci databází od anonym - V práci používáme databázi kontaktů (momentálně cca 500...
-
V práci používáme databázi kontaktů (momentálně cca 500 kontaktů), ke kterým si občas dopisujeme osobní poznámky a potřebujeme v tom všem vyhledávat. Úplně nejdřív to kolega před lety zpracoval v MS Works a teď jsem to překlopili do SugarCRM. Sugar je ovšem značně velká aplikace (asi tak 98% funkcí vůbec nepotřebujeme) a navíc vyhledávání v kontaktech funguje trochu zvláštně.
Pokud bych se pokusil využít např. Kexi nebo Base od OO, bude možné, aby do databáze (na našem serveru) mohli přistupovat současně všichni naši uživatelé a popřípadě každý z nich tam mohl provádět i úpravy?
Dodám, že jsme na to čtyři a každý používáme jiný operační systém (2x WXP, 1x OS a 1x Ubuntu). Na serveru je Mandriva.
Předem díky za případné tipy! -
Alfons (neregistrovaný)V případě Kexi budete muse použít něco jiného než sqlite neb ten je pouze signle user. Ale pokud použijete PostgreSQL či MySQL na serveru,tak na tom budete moci pracovat všichni současně.
Ale ovšem minimálně PostgreSQL NENÍ bezúdržbový RDBMS, takž čas od času je potřeba věnovat čas jeho správě. -
anonymníUdrzet v chodu Oracle je mnohem vice prace nez to same s PGSQL. DB2 je nekde mezi nima. Pracuji se vsema a Oracle je nejhorsi db co se tyce vyzadovaneho bejbysitingu.
Oracle ma ale 2 podstatne vyhody: je draha a zakaznici ji maji radi. Tedy prodejem resenich zalozenych na Oracle vydelate velky balik. -
Alfons (neregistrovaný)Oracle na tom není zas tak zle. Dle mých zkušeností hodně špatného s Oraclem dělají tzv. enterprise aplikace (obvykle jsou to ty Java + Web aplikace). No řekněte - koho z vás by napadlo si při startu aplikace udělat pool 30 otevřených připojení a ty držet ... a držet ... a neuzavírat ani při ukončení aplikace. Tohle je typický problém s každou druhou intranetovou aplikací.
-
Když ji píše dement (a zároveň ji nikdo netestuje), tak ano. Ale v té zmíněné Javě se většinou o databázová spojení stará aplikační server a případně ORM. Držet si už od začátku deset (nebo třeba i třicet) připojení není nic až tak zvláštního – nemusí se čekat, až se připojení otevře (zrovna u Oraclu to chvilku čeká → dost by to zpomalovalo otevření první stránky na webu). -
Alfons (neregistrovaný)Sorry, ale špatně. Proto se přeci implementuje connection pool, abych neměl otevřených 30 připojení aniž cokoliv na db dělám. Pool právě zajišťuje , že je vždy k dispozici X (typicky 1-3) otevřených připojení a pokud se vyčerpají, tak se otevřou další (předem) až do vyčerpání přiděleného počtu connection. Pochopitelně, že pool tyto connection po navrácení recykluje (popř. ukončí a vytvoří nové). Tohle corporátní Java vývojáři nepobrali (teď je to osobní zkušenost, nikoliv nadávání na Javu jako takovou) a vykládají si to jako udělání 30 connection, které neodpojuji ani při restartu aplikace a při startu si prostě naalokuji 30 nových user session. K zblití. A pochopitelně, pokud se jedná o single server (nikoliv farmu), tak po 3-4 restartech aplikace následuje vytuhnut v důsledku nemožnosti vytvoření další connection.
-
LENIN POWER! (neregistrovaný)prestante tu brecet o 30 nepouzitych connectionech v poolu, to se bezne dela protoze tenhle druh zateze ma dost vyrazny spicky a otevreni spojeni do oraclu nejakou dobu trva, tak je potreba mit rezervu. s 1-3 connectionama v poolu nevystacite poradne ani na testovacim stroji.
jinak pro zajimavost db2 umi interni connection pooling transparentni pro aplikace. Mate treba soucasne otevrenych 8000 pripojeni do db zvenku a obsluhujete to 150ti agentama, coz vetsinou staci ponevadz je vetsina dlouhodobe idle u tehle aplikace pracuje soucasne asi 5% uzivatelu. ten pooling se dela aby to setrilo pamet serveru ne aby byly connectiony do db rychlejsi. -
LENIN POWER! (neregistrovaný)No vida, to jsem nevedel. Precetl jsem si k tomu dokumentaci:
http://download.oracle.com/docs/cd/B28359_01/server.111/b28310/manproc001.htm
http://download.oracle.com/docs/cd/B28359_01/server.111/b28310/manproc003.htm#sthref479
Pry to ale nepouzivame (jedeme Oracle10) z duvodu nizsi spolehlivosti. Jinak koukam ze Oracle uz umi session multiplexing jako db2 connect. -
x (neregistrovaný)S tymto prispevkom nemozem suhlasit. Problem nie je 30 otvorenych spojeni na DB. Connection pooling je vyhodny a to predovstkym pri praci s Oracle, pretoze neustale pripajanie a odpajanie na Oracle je neefektivne a ovela pomalsie ako vyuzitie existujuceceho spojenia z poolu. V pripade aplikacneho servera (Java) si mozte Connection pool upravit.
Problem je vsak niekde inde. Problem je v tom, ze Enterprise aplikacie sa snazia byt univerzalne, cize su programovane tak, aby Ste mohli pouzit akukolvek z "mainstream" databaz. A tu je kamen urazu.
Kazda databaza ma svoje specifika a zakonitosti. Univerzalne aplikacie tieto specifika a zakonitosti popieraju. Spominali Ste Oracle, tak uvediem priklad pre Oracle. Pri Oracle ak chcete dosiahnut skalovatelnost aplikacie a minimalizovat waity pri parse faze mali by ste pouzit tzv. viazane (bind) premennne, ktore zapricinia, ze plan pre podobne queries (podobne je mylsene tym, ze zmena dochadza na urovni hodnot v query) sa ulozi v pamati (shared pool) a znovu pouzije. Cize namiesto hard parse sa vykona len soft parse. Ako cloveku dlhodobo administrujucemu Oracle nemusim hovorit, ze hard parse je operacia, ktora vyrazne ovplyvnuje service time, cize dlzku trvania, nez sa dostanete k pozadovanemu vysledku.
Ak je aplikacia pisana aby podporovala viacere druhy DB, napr. MSSQL, PostgreSQL, MySQL a Oracle, tak minmalne kvoli MySQL aplikacia nemoze podporovat viazane premenne. Co ma v pripade Oracleu vazny dopad na performance (zbytocne uzamykanie systemovych prostriedkov atd.) a taktiez to ma aj urcity dopad na bezpecnost (security) aplikacie.
Taktiez velmi zalezi kto a ako dane aplikacie pise. Spominam si na niektore SQL prikazy, ktore su obsiahnute v niektorych enterprise aplikaciach, z ktorych mi bolo takmer doplacu. Vedel by som menovat zodpovedne firmy a aj velkych integratorov, ktori sa nas snazili presvedcit, ze vsetko je OK, ale radsej nebudem. -
LENIN POWER! (neregistrovaný)To je pravda, mne by ovsem zajimalo zda je to pravda nebo ne, nikde ho nejedem.
Pamatuju starej informix nez ho koupila IBM a to byla hrozna sracka. Jelikoz ibm informix porad dale vyviji a pocet zakazniku informixu klesa (neb se jedna o umirajici platformu kterou nepodporuje prakticky zadnej toolchain) tak je logicke ze by potrebovali nove informix zakazniky aby mohli z ceho financovat ten vyvoj. Doporucuji informix pro OLTP aplikace.
Sama IBM zverejnila jakousi roadmap pro informix ze ho bude podporovat do urciteho data +- 5 let a pak se holt uvidi jak budou vypadat sales. Dneska bych do databaze s tak nejistou budoucnosti nesel, zvlast kdyz db2 se dost zlepsila, existuje dost dobra free verze a nativni xml support je cool.
