Re^2: Death and Return of TIMTOWTDI

Think about it this way - I, as a business analyst, need to know that there is a standard way of talking to a database in Perl. Otherwise, the language is unsafe, and therefore - unused. DBI is actually a major selling point for Perl in many industries. CGI is another. They are standards. Standards don't mean that TIMTOWDI is dead. It does mean that TIMTOWDI better shut up when the PHB is listening to the presentation!

I will admit, I am not familure with the design behind DBI (haven't had the chance to check out the code), but there is also another standard SQL. Yes, I am aware that there are ways to work with DBI and SQL together... but then we bring in DBM. There are three standards, well, atleast DBI and SQL are standardised to my knowledge, that could present themselves to a table. Each with their purpose, and place of usage.

As per CGI.pm, I personally do not like it. I've worked on some coding with a different interface, and blah, blah, blah, for things I think are slightly more my style. I've looked through the code for CGI.pm, it is pretty tight, however that tightness really removes some usability. (Yes, I know, I will now get about twelve flames saying that CGI.pm is God, and I obviously know nothing because of that). Most of that code appears hackish in nature (refering to CGI.pm of course), and well... that is a whole different discussion.

-- Jamie Payne

Comment on Re^2: Death and Return of TIMTOWTDI

Replies are listed 'Best First'.
Re^3: Death and Return of TIMTOWTDI by dragonchild (Archbishop) on Jun 05, 2004 at 04:04 UTC
I will admit, I am not familure with the design behind DBI (haven't had the chance to check out the code), but there is also another standard SQL. You're right - you have no idea what you're talking about. DBI and SQL have nothing to do with each other; they are orthogonal technologies. The only link between them is that they are both related to RDBMSs in some way. DBI has to do with how to physically pass messages to a given database. SQL has to do with how you ask a database a question. DBM (which is mostly unrelated) has to do with how to store information in a database. When you use DBI, you generally pass messages written in SQL. As for CGI ... it is not God. It happens to be a piece of code that has been hacked to bits and optimized to Hell and back. It also happens to be the most used piece of Perl code ever, even more than strict. Now, if you want to roll your own CGI, go right ahead. I use a piece of hand-rolled CGI code for a specific purpose. But, don't expect others to use it. Stern does know what he's doing. (There is another node here by Ovid, I think, that discusses a code review of CGI and how it's quite amazing how unmaintainable it is.) ------ We are the carpenters and bricklayers of the Information Age. Then there are Damian modules.... sigh* ... that's not about being less-lazy -- that's about being on some really good drugs -- you know, there is no spoon.* - flyingmoose I shouldn't have to say this, but any code, unless otherwise stated, is untested	[reply]
Re^4: Death and Return of TIMTOWTDI by dakedesu (Scribe) on Jul 04, 2004 at 08:47 UTC
You're right - you have no idea what you're talking about. DBI and SQL have nothing to do with each other; they are orthogonal technologies. The only link between them is that they are both related to RDBMSs in some way. DBI has to do with how to physically pass messages to a given database. SQL has to do with how you ask a database a question. DBM (which is mostly unrelated) has to do with how to store information in a database. When you use DBI, you generally pass messages written in SQL. So, please, master of wise archain arts. How is passing messages to a Database different from asking it questions? As I recall there are also the 'update' and 'insert' statements that do not sound like questions to me. They seem to imply commands to me. This post is not meant to be beillegerant, it is meant to ask a question so that I might learn more. -- Jamie Payne	[reply]
Re^5: Death and Return of TIMTOWTDI by mpeppler (Vicar) on Jul 04, 2004 at 09:30 UTC
DBI is an API used to connect to a data source, and pass it commands. SQL is a language used to interact with a certain class of database sources. So you use DBI to send SQL to the server, if your server speaks SQL and there is a DBI driver available for it. Michael	[reply]
Re^6: Death and Return of TIMTOWTDI by dakedesu (Scribe) on Jul 04, 2004 at 12:12 UTC
Re^7: Death and Return of TIMTOWTDI by mpeppler (Vicar) on Jul 04, 2004 at 18:23 UTC
Some notes below your chosen depth have not been shown here
Re^5: Death and Return of TIMTOWTDI by dragonchild (Archbishop) on Jul 04, 2004 at 20:35 UTC
When using DBI to communicate with a database, you pass messages. Those messages could be commands, questions, whatever. There are other APIs for any given database. DBI is just way of abstracting away the different ways to communicate to different databases. However, talking with an Oracle database is different from talking with a MySQL database. They have implemented the language SQL in subtly different ways. Every command and every question is a message. Computer programs don't make a differentiation between them. Humans do. ------ We are the carpenters and bricklayers of the Information Age. Then there are Damian modules.... sigh* ... that's not about being less-lazy -- that's about being on some really good drugs -- you know, there is no spoon.* - flyingmoose I shouldn't have to say this, but any code, unless otherwise stated, is untested	[reply]
Re^6: Death and Return of TIMTOWTDI by dakedesu (Scribe) on Jul 05, 2004 at 15:52 UTC
Re^7: Death and Return of TIMTOWTDI by dragonchild (Archbishop) on Jul 06, 2004 at 01:36 UTC