Starší komentáře ke článku: Úvod do JDBC
Zpět na článek | Úvodní stránka Interval.cz
Datum vložení: 5.3.2003 8:01:31
Predem dekuji za kvalitni clanek a nyni par otazek.
Jak je to s rychlosti jednotlivych typu, pominuli JDBC-ODBC bridge, zajima me typ 2, IMHO bude nejrychlejsi protoze pouziva primo nativni ovladac?
Dale by me zajimalo, jestli nevite o JDBC driveru pro MSSQL 7.0 (free i pro komercni ucely), pozuivam standardni JDBC-ODBC bridge (sun.jdbc.odbc.JdbcOdbcDriver) a nejsem snim moc spokojen.
Datum vložení: 5.3.2003 15:30:53
Dobry den!
Co se tyka hodnoceni te rychlosti, tak to se neda presne specifikovat, zalezi na typu aplikace, na ktere chcete ten vykon merit. Kazdopadne bych si netroufal ani obecne rici, ze ovladac typu 2 bude rychlejsi. Asi pokud byste meril ciste jen datovy prenos, tak ano. Ale to jiz dneska davno neplati, ptz mnoho aplikacnich serveru vyuziva svuj vlastni caching, optimalizaci pripojeni a v podstate integruje nativni ovladace do sveho prostredi. Proto zde neni problem v hodnoceni rychlosti s ohledem na JDBC ovladac, ale na architekturu (klient-server vs. vicevrstevna architektura). Obecne co do prenosu dat a odezvy bude urcite rychlejsi klient-server, ale to plati obecne (kdyz neuvazujete limitaci HW ani SW). Ale v realu je optimalnejsi pouzit vicevrstvou architekturu, ktera i pres vyssi "ukecanost" ma v dusledku vyssi vykon poskytovany klientum (v pripade, ze se jedna o velke mnozstvi klientu).
Co se tyka toho ovladace pro MSSQL, tak pokud budete chtit odladeny JDBC ovladac, tak musite prejit na SQL2K. Ovladac je zdarma a muzete ho stahnout zde:
<a href='http://msdn.microsoft.com/downloads/default.asp?URL=/downloads/sample.asp?url=/MSDN-FILES/027/001/779/msdncompositedoc.xml' target='_blank'>http://msdn.microsoft.com/downloads/default.asp?URL=/downloads/sample.asp?url=/MSDN-FILES/027/001/779/msdncompositedoc.xml</a>
Datum vložení: 5.3.2003 16:23:32
Dobry den,
diky za odpoved. To by samozrejme reseni bylo, pokud bych zakaznika presvedcil, aby presel z MSSQL 7.0 na 2000, coz se mi asi nepovede.
Datum vložení: 5.3.2003 16:27:17
Ja to chapu, ale Vas klient by zase mel pochopit, ze tomu bude tak vzdy, ze novejsi verze bude nabizet vice moznosti, nez starsi ;) Jinak pokud mohu doporucit, tak ten prechod ma vyznam pro pripadne velkeho klienta. Kazdopadne nova verze MSSQL serveru, co je nyni v alfa verzi bude natolik prevratna i co do vykonu (uz jen testy alfa verze naznacuji, ze Microsoft obsadi vsechna prvni mista v TPC-C), ze by Vas klient mel uvazovat o upgrade ;) Ale jak jsem rekl, to vse zavisi na narocnosti systemu a jeho vytizenosti.
Mejte se.
JS
Datum vložení: 17.3.2003 12:26:36
Když už píšete o základech J2EE, nebyl by zajímavější článek o CMP/BMP EJB nebo o JDO než pořád a všude základy JDBC? Na sourceforge.net je nová verze xpetstore, parádní ukázka tandemu ant+xdoclet, která ilustruje dva typy perzistence: CMP EJB+ValueObjects a hibernate+POJO. Promiňte mi ale základy JDBC mi nepřijdou příliš zajímavé ani aktuální.
Datum vložení: 17.3.2003 12:56:55
Ten clanek o JDBC jsem jiz mel dlouho napsany, vlastne od minuleho roku a jen jsem ho ted zverejnil. Osobne si myslim, ze neni na tom nic neaktualniho, naopak jsem zazil, ze se me mnoho lidi v minulem roce ptalo na prave tyto veci. O EJB psat nebudu, nebot je nepokladam za zrovna nejlepsi technicky model. Ale to je muj osobni nazor. Kazdopadne pokud Vy to pokladate za vhodne, nic Vam nebrani, abyste napsal tento clanek sam. Ja si ho pak velmi rad prectu. Preji hezky den.
Datum vložení: 17.3.2003 14:38:20
EJB jsou jednou z hlavních součástí J2EE a kolem nich se točí celý aplikační vývoj. :-) I pres tak casto kritizovane EntityBeans jsou EJB stale vlajkovou lodi J2EE. Clanku o JDBC bylo na ceskych webech uz docela dost (zvlaste o zakladech :-) opravdu se Vas nechci nijak dotknout, ale po Vasich prvnich dvou super clancich me tento trochu zklamal. JDBC je podrobne probrano v kazde knize o jave narozdil napr. od JMX MBeans nebo JAAS, o tech toho zatim v nasem rodnem jazyku moc nebylo.
Datum vložení: 17.3.2003 14:44:46
Ja s Vami souhlasim, ale musim rici, ze ja osobne jsem velkym odpurcem konceptu entity beans. To, ze jsou v J2EE neznamena, ze je to blbost ;) Stejne tak jsem byl a jsem odpurcem COM/DCOM architektury a to i presto, ze pracuji pro Microsoft. Ale tyto technologie pokladam za spatne, ale chapu, ze maji svoje zastance. Ale ja k nim nepatrim a to, ze jsou soucasti nejakeho standardu me nemuze zmenit v tom, abych je nepokladat za neco, co tam nema byt. Jinak jeste vysvetleni k tomu JDBC. Mym cilem bylo uvest serii clanku o J2EE a .NET, mel jsem JDBC jiz dlouho napsane a chtel jsem publikovat pak o ADO.NET, pak dalsi temata jako napr. JNDI a k tomu AD, remoting, JMS atd. V podstate udelat analogicky serial o techto principech v podani ruznych platforem a ukazat, ze je lze kombinovat a ze je vhodne je znat obe. Clanky o JNDI a JMS uz mam skoro napsane, ale nechci je publikovat, chci ted napsat, jak jiz jsem uvedl neco o .NET technologiich (aby to bylo spravedlive, ptz ted to bylo o Jave ;) ). Kazdopadne diky za namet ;)
Datum vložení: 17.3.2003 15:51:05
Dekuji Vam za Vasi trpelivost, v diskuzi u Vaseho prvniho clanku pisete, ze mojebanka.cz nahradila entityBeans alternativnim resenim. Pouzili nejaky komercni object/relational mapping software (TopLink, cocobase), nebo ciste vlastni reseni? Co je podle Vas optimalni nahrada entityBeans? Apache OJB? hibernate?
Datum vložení: 17.3.2003 16:10:34
Nechci a ani nemohu resi KB komentovat. Kazdopadne entity beany se v mnoha projektech, co jsem videl, projevily jako velky problem s ohledem na vykon systemu. Podle mne maji vyznam session a message beany, ale entity jsou jen snaha o to, co vyborne vyresil Microsoft se svymi datasety (a k tomu ciste i s ohledem na XML formatovani). Jsou zde i jine moznosti (napr. jsou to hierarchicke datasety, ktere maji nejake OSS implementace pro J2EE, ale malokdo to zna, a proto to neni tolik rozsirene).
Datum vložení: 17.3.2003 16:29:35
dekuji, myslim ze tyto jine OSS moznosti, ktere malo kdo zna a nejsou tolik rozsirene by byly opravdu zajimavym nametem na clanek ;-)
Datum vložení: 25.8.2003 13:47:14
Nema byt nahodou v JConnectionPool.getConnection(...) spis:
return getConnection(<B>false</B>, timeout);
namisto:
return getConnection(<B>wait</B>, timeout);
?
Takhle v pripade nedostupne Connection neskonci wait() nikdy a na hodnote timeout nebude zalezet.
Krome toho rekurze je v tomhle pripade nebezpecna s ohledem na mozny StackOverflowError, pokud nebudou Connections k dispozici a timeout bude maly.
P.
Datum vložení: 1.9.2003 12:52:32
Zajímalo by mne jak si zjistím názvy sloupečků v tabulce.
Datum vložení: 17.1.2004 21:06:16
dobrý den s programováním v Jave teprve začínám a podle obrázku je JDBC Typu 3 přesné řešení mého problému, mohl by mi rosím někdo poradit jak spojení Typu 3 vytvořit? Za radu předem děkuji
Datum vložení: 27.8.2007 12:51:21
Dobrej, jsem na tom ještě hůř než Vy, (začínám až teď) mohl by jste se se mnou podělit o poznatky pro připojení? Předem děkuji.
Datum vložení: 28.4.2006 11:58:08
Spojední do databáze jsem rozchodil až poté, co jsem String url = " jdbc.odbc.Ukazka"; změnil na: String url = "jdbc:odbc:Ukazka";