[vwnc] Database support Native and ODBC
Locked
 
|
Hello to everyone.
I am fairly new to database building and smalltalk, but have done a fair journey of research through different languages (Python, Ruby, Java) and IDE's to find a platform that I feel comfortable with but also has a lot of power. That is why I have ended up at smalltalk, appears to have strong power to complete my current database and gui creation project, but also plenty of ability to perform other future projects I have in mind. I don't want to have to keep learing new tools each time I want to create a project. I like python/sql alchemy but dont feel that the IDE and tools have fully matured yet. Okay onto the specific question, I am creating (for own personal use) a database to store sports information some basic and some calculated values. The goal is to be able to perform both basic functions (print out guides etc) but also complex data mining on sports, times, results, locations, sectioanl times etc. In the smalltalk whitepaper http://www.cincomsmalltalk.com/files/jarober/papers/ObjectStudio8.pdf it mentions the advantages of using native api and odbc databases. I am looking for more clarity about the differences/advantages of native versus ODBC in object studio. Of the native API's listed in the whitepaper I would only be able to get access to ORacle XE, MS Server Express and MS Access 07, for ODBC I probably would want to use Postgres over MySQL. Actually I was planning to use Postgres via ODBC with Glorp until I noticed this section of the white paper, is there a major difference between this support and say Oracle Xe and native api? I feel that (but could be wrong) that relational databases would be more sutiable to OO databases gemstone etc for my type of data, static results (time, measurements, results, names etc). Thanks Sayth _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: [vwnc] Database support Native and ODBC
|
|
Am 23.09.09 06:19 schrieb [hidden email]:
> Okay onto the specific question, I am creating (for own personal use) a > database to store sports information some basic and some calculated values. > The goal is to be able to perform both basic functions (print out guides > etc) but also complex data mining on sports, times, results, locations, > sectioanl times etc. In the smalltalk whitepaper > http://www.cincomsmalltalk.com/files/jarober/papers/ObjectStudio8.pdf it > mentions the advantages of using native api and odbc databases. I am > looking for more clarity about the differences/advantages of native versus > ODBC in object studio. Of the native API's listed in the whitepaper I would > only be able to get access to ORacle XE, MS Server Express and MS Access > 07, for ODBC I probably would want to use Postgres over MySQL. > > Actually I was planning to use Postgres via ODBC with Glorp until I noticed > this section of the white paper, is there a major difference between this > support and say Oracle Xe and native api? For a small, simple, single-user application like yours, there is nothing wrong with ODBC. Using native APIs may have advantages if you want to use specific features like using array binding for executing a statement for many parameter sets with a single call, which you will need for doing mass data updates/inserts. Some native APIs may also have slight performance advantages under certain circumstances. But in your case, you probably don't need any of that, and I wouldn't worry about ODBC performance unless you actually have a problem with it (which I doubt). BTW, VisualWorks has a "native" (i.e. non-ODBC) PostgreSQL interface which should work in ObjectStudio, too. I am not too familiar with ObjectStudio, the PostgreSQL interface might be included in the OS distribution already. You might also want to consider portability to other platforms. Do you want to be able to move from Windows to Linux or Mac OS X? Some of the databases you mentioned are not available for those platforms. > I feel that (but could be wrong) > that relational databases would be more sutiable to OO databases gemstone > etc for my type of data, static results (time, measurements, results, names > etc). What exactly makes you "feel" that? Cincom Smalltalk includes a free OODB implemented in Smalltalk (OmniBase, in the "contributed" directory of the VisualWorks distribution). OmniBase might be suited quite well to your needs, and you don't have to create an object-relational mapping. A relational database would be better for your application if you want to use SQL queries instead of executing Smalltalk code for the complex data mining you mentioned, or if you have to access it from non-Smalltalk applications (e.g., MS Excel). And GemStone - well, I don't think that you can find anything better for implementing business critical application servers. GemStone isn't just a database server - it's an enterprise-grade application server which happens to include a mature OODB. However, it might be too complex for your needs. HTH, Joachim Geidel _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: [vwnc] Database support Native and ODBC
|
|
In reply to this post by flebber
I think the paper suggests that you may
want to use a direct vendor (native) interface instead of ODBC if your
application needs more speed, or if it depends on some special features not
offered via the ODBC interface. ODBC is just another DLL between you and the database
client DLL. The uniformity of the ODBC api is nice, but you lose a bit of
performance going with that extra layer between you and the database. Presumably,
the Smalltalk app code you write will look almost exactly the same whether you
point it at an Oracle or a SQL Server database, or an ODBC source. So, you can
plug your app into any of them, including ODBC, particularly if you are able to
avoid vendor-specific features (like OS8 stored procedures). I hope I didn’t completely
misunderstand your question. Maybe others can weigh in, particularly about OS8’s
nice database GUI, etc. - Dave From:
[hidden email] [mailto:[hidden email]] On Behalf Of [hidden email] Hello to everyone. _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: [vwnc] Database support Native and ODBC
|
|
Sorry, a typo! > vendor-specific features (like OS8
stored procedures). was supposed to be: vendor-specific features (like stored
procedures). It is later than I thought. Somehow,
Outlook did some curious independent pasting. -dw From: Wallen, David I think the paper suggests that you may
want to use a direct vendor (native) interface instead of ODBC if your
application needs more speed, or if it depends on some special features not
offered via the ODBC interface. ODBC is just another DLL between you and the
database client DLL. The uniformity of the ODBC api is nice, but you lose a bit
of performance going with that extra layer between you and the database.
Presumably, the Smalltalk app code you write will look almost exactly the same
whether you point it at an Oracle or a SQL Server database, or an ODBC source.
So, you can plug your app into any of them, including ODBC, particularly if you
are able to avoid vendor-specific features (like OS8 stored procedures). I hope I didn’t completely
misunderstand your question. Maybe others can weigh in, particularly about
OS8’s nice database GUI, etc. - Dave From:
[hidden email] [mailto:[hidden email]] On Behalf Of [hidden email] Hello to everyone. _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
|
|
In reply to this post by flebber
"basic functions (print out guides etc) but also complex data mining on sports, times, results, locations, sectioanl times etc" Complex functions Smalltalk will excel in.. so no issues whether you choose ODBC/ native or OODB. But for basic function of printing you may have to go out of smalltalk if you really want the ease and flexibility of a read doc generator viz: Jasper Reports.. or even a more basic but acceptable pdf writer from ruby ( or maybe python).
For ODBC / native the reasons are as noted by all others.. performance or specific capability of SQL syntax say for limiting rows of return, stored proc execution etc. You can consider GLORP, a slightly steeper climb from just a executeSQL: command capability, but on a longer run highly maintainable and DB independent. For OODBs too that would be a clinching reason, longer term maintenance. But as you say yours more of a hobby personal project, guess plain ODBC to begin with seems fine and graduate as you see the complexity and need directs you.
On Wed, Sep 23, 2009 at 9:49 AM, <[hidden email]> wrote: Hello to everyone. _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
|
|
I was reading this wiki http://wiki.gorisek.com/WikiDoc/WikiPage and may have assigned to much importance to this statement "Regarding performance then basic rule of thumb is: if you are mainly dealing with relationships (especially very complex ones), you should go for OODBMSs. If you are mainly dealing with values and static database schemas, the query engines of RDBMSs are superior."
> Complex functions Smalltalk will excel in.. so no issues whether you choose ODBC/ native or OODB. But for basic function of printing you may have to go out of smalltalk if you really want the ease and >flexibility of a read doc generator viz: Jasper Reports.. or even a more basic but acceptable pdf writer from ruby ( or maybe python). Well while having to leave smalltalk to print is a minor annoyance, nothing too major really:-) On Sep 23, 2009 7:10pm, Sudhakar Krishnamachari <[hidden email]> wrote: > > "basic functions (print out guides etc) but also complex data mining on sports, times, results, locations, sectioanl times etc" > > > > Complex functions Smalltalk will excel in.. so no issues whether you choose ODBC/ native or OODB. But for basic function of printing you may have to go out of smalltalk if you really want the ease and flexibility of a read doc generator viz: Jasper Reports.. or even a more basic but acceptable pdf writer from ruby ( or maybe python). > > > > For ODBC / native the reasons are as noted by all others.. performance or specific capability of SQL syntax say for limiting rows of return, stored proc execution etc. You can consider GLORP, a slightly steeper climb from just a executeSQL: command capability, but on a longer run highly maintainable and DB independent. For OODBs too that would be a clinching reason, longer term maintenance. But as you say yours more of a hobby personal project, guess plain ODBC to begin with seems fine and graduate as you see the complexity and need directs you. > > > > > > On Wed, Sep 23, 2009 at 9:49 AM, [hidden email]> wrote: > > Hello to everyone. > > I am fairly new to database building and smalltalk, but have done a fair journey of research through different languages (Python, Ruby, Java) and IDE's to find a platform that I feel comfortable with but also has a lot of power. That is why I have ended up at smalltalk, appears to have strong power to complete my current database and gui creation project, but also plenty of ability to perform other future projects I have in mind. I don't want to have to keep learing new tools each time I want to create a project. I like python/sql alchemy but dont feel that the IDE and tools have fully matured yet. > > > Okay onto the specific question, I am creating (for own personal use) a database to store sports information some basic and some calculated values. The goal is to be able to perform both basic functions (print out guides etc) but also complex data mining on sports, times, results, locations, sectioanl times etc. In the smalltalk whitepaper http://www.cincomsmalltalk.com/files/jarober/papers/ObjectStudio8.pdf it mentions the advantages of using native api and odbc databases. I am looking for more clarity about the differences/advantages of native versus ODBC in object studio. Of the native API's listed in the whitepaper I would only be able to get access to ORacle XE, MS Server Express and MS Access 07, for ODBC I probably would want to use Postgres over MySQL. > > > Actually I was planning to use Postgres via ODBC with Glorp until I noticed this section of the white paper, is there a major difference between this support and say Oracle Xe and native api? I feel that (but could be wrong) that relational databases would be more sutiable to OO databases gemstone etc for my type of data, static results (time, measurements, results, names etc). > > > > Thanks > > Sayth > _______________________________________________ > > vwnc mailing list > > [hidden email] > > http://lists.cs.uiuc.edu/mailman/listinfo/vwnc > > > > > vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: [vwnc] Database support Native and ODBC
|
|
Am 23.09.2009 um 15:14 schrieb [hidden email]: > Well while having to leave smalltalk to print is a minor annoyance, > nothing too major really:-) A simple yet practical solution is to render HTML and have a browser do the printing. This also supports CSS. XML/XSLT is also an option to create beautiful HTML or PDF. Tools like that save you the hassle of tweaking (native) pixels and fonts in VW. At the same time you get a portable document that can be archived. Andre _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
|
|
Thanks Andre thats great advice
On Sep 24, 2009 12:13am, Andre Schnoor <[hidden email]> wrote: > > > Am 23.09.2009 um 15:14 schrieb [hidden email]: > > > > > Well while having to leave smalltalk to print is a minor annoyance, nothing too major really:-) > > > > > A simple yet practical solution is to render HTML and have a browser do the printing. This also supports CSS. XML/XSLT is also an option to create beautiful HTML or PDF. Tools like that save you the hassle of tweaking (native) pixels and fonts in VW. At the same time you get a portable document that can be archived. > > > > Andre > > > vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: [vwnc] Database support Native and ODBC
|
|
One also has to keep in mind that in today’s day and age
additional hit you’d take by using ODBC vs some Native driver is miniscule
compared to the cost of actually preparing and executing most queries, so that
can’t be that much of a concern? Regards, -Boris -- +1.604.689.0322 DeepCove Labs Ltd. 4th floor 595 Howe Street Vancouver, Canada V6C 2T5 From:
[hidden email] [mailto:[hidden email]] On Behalf Of [hidden email] Thanks Andre thats great advice _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
| Free forum by Nabble | Edit this page |