Vlákno názorů k článku Firebird SQL 1.5 za dveřmi od Pepa - Prominte ze vstupuji do diskuskuse, kdyz si proti...

  • Článek je starý, nové názory již nelze přidávat.
  • 19. 9. 2003 8:37

    Pepa (neregistrovaný)

    Prominte ze vstupuji do diskuskuse, kdyz si proti vam pripadam jako amater, ale po precteni prispevku o prenositelnosti ci neprenostelnosti a vhodnosti DB, tak proste musim.
    Existuji prece minimalne dve situace kdy se rozhoduje o tom na cem to pojede. Pokud vyvijim tzv. specialni aplikaci pro jednoho zakaznika, tak mam bud danou db nebo si ji zvolim podle potreb aplikace. A pokud delam aplikace ktera se bude prodavat X zakaznikum (a neni to zrovna pouhy seznam dat) tak musim pocitat s tim ze tech db bude proste vic a ruznych. Mohu sice nastavit ruzna omezeni na cem jsem to schopen odladit, ale vysledek je stejny: pokud to pojede jenom na jedne, tak mne s tim tak kde uz maji koupenou (nebo jinak ziskanou ) jinou db VYHODI.
    Co se tyka kvalit jednotlivych db, tak si myslim ze diskuse je celkem o nicem pokud porovnavate neporovnatelne.

  • 19. 9. 2003 8:59

    Jozef Hribik (neregistrovaný)

    Pokiaľ programujete v Jave a skutočne objektovo, tak by ste mal vedieť čosi o ORM = Object Relational Mapping. Odporúčam pozrieť štandard JDO, resp. "neštandardné" open-source projekty Hibernate a iBATIS. Umožnia vám znížiť náklady pri programovaní prenositeľnosti na viacero DB.

    http://www.hibernate.org
    http://www.ibatis.com
    http://www.jdocentral.com/

  • 19. 9. 2003 9:06

    Pavel Stěhule (neregistrovaný)

    To co jste napsal je svata pravda. Ta debata se vede asi o necem jinem. Zda-li mam pouzivat jen ty vlastnosti SQL, ktere jsou podporovany vsude (a co chybi osetruji na aplikacni urovni) nebo zda-pouzivam i ty ne vsemi podporovane vlastnosti (mohu mit jednodussi aplikacni uroven, ale n databazovych vrstev)

  • 19. 9. 2003 9:36

    Jozef Hribik (neregistrovaný)

    Súhlasím.

    Pozrite si iBATIS. Umožní Vám použiť všetky špeciality danej DB.

    Uvediem príklad Oracle vs. MS SQL. V MS SQL použijem autoincrement a v Oracli sequence generátor. Taktiež môžem použiť na mieru šitú storovanú procedúru.

    iBATIS mi umožní v Jave napísať jednoduchú metódu v business logike, napr. "Personnel.getStupidManagers()". Pritom len správne nakonfigurujem ORM engine iBATIS tak aby pri volaní tejto metódy zavolal napr. storovanú proc v Oracli, ale pri nakonfigurovaní MS SQL to môže byť view. Krásne je to, že vrstva business logiky nevie nič o tom aká DB je momentálne použitá.

  • 21. 9. 2003 15:13

    lzap (neregistrovaný)

    Otázkou je, nakolik to zpomalí práci s databází a hlavně, zda-li to neomezuje využít všechny vlastnosti dané databáze. Každá architektura je v nečem jiná, lepší, viz. například práve MGA u Firebirdu/PostgreSQL.

    Já jsem zkoušel hibernate na tlustém klientovi, nahrával jsem z dat líný strom a dával to do komponenty JTree. Všechno bylo katastrofálně pomalé a aplikace se spouštěla snad 10 vteřin. S čistým JDBC to bylo 3x rychlejší. Jen jsem to sice zkoušel, ale indexy jsem měl nastavené správně...

    Který ORB je nejlepší na tlusté klienty a vůbec, má cenu používat JDO a podobné technologie mimo webové a EE servery?

  • 22. 9. 2003 10:40

    Jozef Hribik (neregistrovaný)

    Máte čiastočne pravdu. Ale keď zvládnete nastavenia zvoleného ORM, tak pokles výkonu bude pravdepodobne minimálny.

    Autor Hibernate (Gavin King) vypísal odmenu tomu, kto mu dokáže, že použitie Hibernate je pomalšie viac ako o 10% oproti priamemu JDBC. Skúste mu poslať váš príklad.

    Ja robím momentálne len webové aplikácie (tenký klient). ORM nasadím len vtedy, keď zákazník požaduje možnosť prechodu na inú DB v blízkej budúcnosti. Ale inak som stále zástancom viacvrstvovej architektúry, takže napr. vzor DAO používam bežne.

    PS: Skúste si pozrieť iBATIS. Možno vás presvedčí viac ako Hibernate. Má skvelý DAO Manager. Vyskúšal som ho aj s Hibernate, ale momentálne používam technológie iBATIS (DAO Manager + SQL Mapper).