Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations Chriss Miller on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
for database what should i use
- Thread starter vrmewada
- Start date
dbc If you are really meaning to use pws and msaccess for web dev, then there odbc allows you to stay in the 'windows' world. You can see the Windows help for the macros in access and use many of the VB object/classes/methods listed.
If you go the dbi route, you will write code that is generally portable to other systems using other databases.......just change the connect string and your flying on MySQL or other. .....and uses standard sql syntax.
However, I would question the use of pws, even as a development environment. Apache is free and reasonably easy to setup and ubiquitous on the web. I would also question the use of msaccess, even as a development environment. It will not allow multi-user access. Usually, when I see a web app developed to use Access, the data does not really justify using a 'database'. Most web data is not really 'relational'. Consequently, a strong case can be made for using flat files with an index and a little flocking, if the data is fairly straight forward, or going to MySQL of PostGres or SQL Server (annoying to work with from Perl), if the data is truely relational and massive.
I hope I have not completely muddied the waters. I would be interested to read other perspectives on this.
[sig]<p> <br><a href=mailto: > </a><br><a href= > </a><br> keep the rudder amid ship and beware the odd typo[/sig]
If you go the dbi route, you will write code that is generally portable to other systems using other databases.......just change the connect string and your flying on MySQL or other. .....and uses standard sql syntax.
However, I would question the use of pws, even as a development environment. Apache is free and reasonably easy to setup and ubiquitous on the web. I would also question the use of msaccess, even as a development environment. It will not allow multi-user access. Usually, when I see a web app developed to use Access, the data does not really justify using a 'database'. Most web data is not really 'relational'. Consequently, a strong case can be made for using flat files with an index and a little flocking, if the data is fairly straight forward, or going to MySQL of PostGres or SQL Server (annoying to work with from Perl), if the data is truely relational and massive.
I hope I have not completely muddied the waters. I would be interested to read other perspectives on this.
[sig]<p> <br><a href=mailto: > </a><br><a href= > </a><br> keep the rudder amid ship and beware the odd typo[/sig]
vcherubini
Programmer
goBoating or vrmewada:
Do you know the database that tek-tips uses? I would think that it is either Access or MySQL since it is done in Cold Fusion.
Thanks
-Vic [sig]<p>vic cherubini<br><a href=mailto:malice365@hotmail.com>malice365@hotmail.com</a><br><a href= software</a><br>====<br>
Knows: Perl, HTML, JavScript, C/C++, PHP, Flash, Director<br>
Wants to Know: Java, Cold Fusion, Tcl/TK<br>
====[/sig]
Do you know the database that tek-tips uses? I would think that it is either Access or MySQL since it is done in Cold Fusion.
Thanks
-Vic [sig]<p>vic cherubini<br><a href=mailto:malice365@hotmail.com>malice365@hotmail.com</a><br><a href= software</a><br>====<br>
Knows: Perl, HTML, JavScript, C/C++, PHP, Flash, Director<br>
Wants to Know: Java, Cold Fusion, Tcl/TK<br>
====[/sig]
- Thread starter
- #4
thanx
goboating
i am sorry but i am still confusing can u explain me the diffrence between using the win32::0dbc and dbi in detail.
is the dbi is only for the convinions while u want to change your database from one to another..????
and i have started mine work with the msaccess and want to use oracle later on.
ya i need to use the database because mine database is relational and it can me massive.
i know the asp so i am very familiar with the pws so i started to work with the win. plateform i will switch over to apache later on..
waiting for your reply.
vikram
[sig][/sig]
goboating
i am sorry but i am still confusing can u explain me the diffrence between using the win32::0dbc and dbi in detail.
is the dbi is only for the convinions while u want to change your database from one to another..????
and i have started mine work with the msaccess and want to use oracle later on.
ya i need to use the database because mine database is relational and it can me massive.
i know the asp so i am very familiar with the pws so i started to work with the win. plateform i will switch over to apache later on..
waiting for your reply.
vikram
[sig][/sig]
Hi Vikram,
There is a book called, "Programming the Perl DBI" authored by Alligator Descartes & Tim Bunce. Of all the O'Reilly published books on Perl/CGI, this one has been the most helpful to me in working with SQL, DBI, Oracle and Perl/CGI. It has a detailed comparison in answer to your question in Chapter 7, ODBC and the DBI and gives relevent details as to the differences and strengths.
DBI, as you know, is a Perl module. It is the standard database interface when working with Perl. DBI requires database type dependent drivers - which you may see - such as DBD::Oracle, DBD::ODBC, DBD::MySQL and so on. This really does not complicate matters as much as it sounds. Once you have the DBD setup, it is really cut and paste code afterwards to reuse it.
Win32::ODBC is more closely aligned with Windows products, which may, for some, satisfy their needs. It has extensive ODBC function support whereas the DBI is a little lacking. Also, DBI, is more closely aligned with UNIX, LINUX, and other non-Windows OS's. Win32::ODBC Functions supported include, Tables, Columns, Special Columns, Statistics, Primary keys, Foreign keys, and GetTypeInfo - the DBI supported only Tables and GetTypeInfo as of February 2000.
The advantage of Win32::ODBC over the DBD::ODBC is that most of the ODBC API is available; attributes, options and metadata is available, and most significant - scrolling cursors are supported which is useful in interactive browsing applicatons.
Your best bet for additional information is back to the source - go to Microsoft's MSDN and use their search utility. It used to be - I'm not certain if it still is but their search answers can be overwhelming so be as specific as you can.
To borrow from the book I mentioned earlier, there are some disadvantages to using Win32::ODBC compared to DBD::ODBC - there are no separate prepare and execute steps, there is no automatic error handling and most significant, Win32::ODBC is slower than DBD::ODBC.
It basically comes down to your needs and at the moment it sounds like you want more of the ODBC API at your disposal which means go with the Win32::ODBC - If you port to non-Windows later, you can use Win32:
BIODBC which provides some emulation of Win32::ODBC. Win32:BIODBC is bundled with the DBI module. When you're ready to make a change (not including OS/Webserver specific changes) you can change from:
use Win32::ODBC
to
use Win32:BIODBC
You could even run it from the command line.
perl -MWin32:BIODBC script_name_here.
If you do make the jump from the Windows ODBC, you really should get the book or borrow it from someone who has it - as I mentioned before - it is the most useful one for me of the O'Reilly Perl books.
Quite frankly, I don't care what webserver you decide to use but your choice of OS has some pretty obvious and well-exploited holes in it. If you're developing for an Intranet application behind a fairly secure firewall/proxy - you might be okay, but you should look to the future and something that has some greater long term reliability. If you are going to have more than a few users relying on this as a platform, it would be worth your time investment to learn and go beyond 98 (your users will thank you too). I'm not an MS basher or an anyone basher for that matter, but while 98 is "pretty" it does not have the reliability of the UNIXalike OS's.
Good luck,
higginsd [sig][/sig]
There is a book called, "Programming the Perl DBI" authored by Alligator Descartes & Tim Bunce. Of all the O'Reilly published books on Perl/CGI, this one has been the most helpful to me in working with SQL, DBI, Oracle and Perl/CGI. It has a detailed comparison in answer to your question in Chapter 7, ODBC and the DBI and gives relevent details as to the differences and strengths.
DBI, as you know, is a Perl module. It is the standard database interface when working with Perl. DBI requires database type dependent drivers - which you may see - such as DBD::Oracle, DBD::ODBC, DBD::MySQL and so on. This really does not complicate matters as much as it sounds. Once you have the DBD setup, it is really cut and paste code afterwards to reuse it.
Win32::ODBC is more closely aligned with Windows products, which may, for some, satisfy their needs. It has extensive ODBC function support whereas the DBI is a little lacking. Also, DBI, is more closely aligned with UNIX, LINUX, and other non-Windows OS's. Win32::ODBC Functions supported include, Tables, Columns, Special Columns, Statistics, Primary keys, Foreign keys, and GetTypeInfo - the DBI supported only Tables and GetTypeInfo as of February 2000.
The advantage of Win32::ODBC over the DBD::ODBC is that most of the ODBC API is available; attributes, options and metadata is available, and most significant - scrolling cursors are supported which is useful in interactive browsing applicatons.
Your best bet for additional information is back to the source - go to Microsoft's MSDN and use their search utility. It used to be - I'm not certain if it still is but their search answers can be overwhelming so be as specific as you can.
To borrow from the book I mentioned earlier, there are some disadvantages to using Win32::ODBC compared to DBD::ODBC - there are no separate prepare and execute steps, there is no automatic error handling and most significant, Win32::ODBC is slower than DBD::ODBC.
It basically comes down to your needs and at the moment it sounds like you want more of the ODBC API at your disposal which means go with the Win32::ODBC - If you port to non-Windows later, you can use Win32:
BIODBC which provides some emulation of Win32::ODBC. Win32:BIODBC is bundled with the DBI module. When you're ready to make a change (not including OS/Webserver specific changes) you can change from:use Win32::ODBC
to
use Win32:
BIODBCYou could even run it from the command line.
perl -MWin32:
BIODBC script_name_here.If you do make the jump from the Windows ODBC, you really should get the book or borrow it from someone who has it - as I mentioned before - it is the most useful one for me of the O'Reilly Perl books.
Quite frankly, I don't care what webserver you decide to use but your choice of OS has some pretty obvious and well-exploited holes in it. If you're developing for an Intranet application behind a fairly secure firewall/proxy - you might be okay, but you should look to the future and something that has some greater long term reliability. If you are going to have more than a few users relying on this as a platform, it would be worth your time investment to learn and go beyond 98 (your users will thank you too). I'm not an MS basher or an anyone basher for that matter, but while 98 is "pretty" it does not have the reliability of the UNIXalike OS's.
Good luck,
higginsd [sig][/sig]
- Status