P.S. Sorry for not replying to this for so long, but I have been without a computer for the last week ... and possibly for the next week too ... right now, I'm on someone else's machine. --------------
On Wed, 7 Mar 2007, Smylers wrote: > On February 27th Darren Duncan writes: > > One common usage scenario, of relational-join in particular, is doing > > operations on tabular data, where you want to know something that > > involves matching up columns in several tables. > > <Snip excellent example> > > I've seen lots of programs that do things like that. But by a long way > it's far more common to have the data tables in a database and use SQL > for the joining than for the data to be elsewhere, such that SQL can't > be used and it has to be read into Perl data structures for doing the > joining. My main point here is that it should be easy to code any common programming task in Perl itself, rather than coding it in some other language like SQL. Perl is a better language than SQL, in general, and we should be able to expres all database operations using Perl alone, and it should be possible for that Perl to be cleaner and at least as concise as SQL; moreover, SQL isn't capable of cleanly expressing a lot of concepts that Perl can express, so better to avoid the baggage. While there is a strong benefit to having a dedicated database engine, there is no reason that this can't be written in Perl, rather than some other language, and some support in the language itself for fundamental concepts will make it easier to write and use such Perl native engines. Also, a lot of people work with smaller or medium-sized data sets for which there isn't that great a performance hit for processing the data with more simple and naive implementations that have all the data in Perl data structures. One may, for example, be processing data from several text files, or that was recently input from the user. I see the situation here as being somewhat analagous to the situation with people writing code using inlined C because Perl couldn't express what they wanted in an efficient manner; Perl 6 added native support for things like native numeric types, and other things that PDL was used for, so people wouldn't have to write in a non-Perl language, and keep things simpler. Likewise, we shouldn't have to write in SQL, or in pseudo-Perl-SQL, but just write in Perl. This isn't to say that external database engines can't still be used. But it should be easier to use them transparently, such that you can write your relational operations in pure Perl regardless of whether your data is in Perl variables or in data structures tied to external engines. All this said, I recognize that a lot of details can be provided in a Perl 6 module rather than being in the core language specification, and maybe that very well may be the best option. But I still can't help feeling that some of this naturally fits in the core language as much as Perl 6's replacement for PDL does. > DBI is a module, not a core part of the Perl language. I think it would > be odd for Perl 6 to have core support for these operations when most > users would use DBI instead. To this I say there is room for both. Ideally, Perl 6 would have bundled an ideal native interface for RDBMSs, and a default built-in implementation that just uses Perl data structures and is simple. But CPAN authors can .does() that interface in their own modules, such that theirs provide bridges to other engines, often removing the need for people to use DBI-as-it-is directly, if at all. Of course, DBI-as-it-is still has its uses, just as there are still always uses for writing inlined C. Larry's Synopsis docs *do* include example roles or traits called "Database" do they not? What could that refer to if not something similar to what I'm talking about? > Are there Cpan modules in existence for doing this kind of thing in Perl > 5? I will note that there is a very new distro called DBIx::Perlish that is probably worth looking at. I didn't make it, but it presents some very good ideas such that would be good to have. Take as some inspiration. -- Darren Duncan P.S. My lack of a computer has set back my progress, but once I get it back, I still hope to have working prototypes of my proposals within a few weeks.
