RDBMS to hold Perl objects?

J

James Willmore

Is there a free RDBMS that can handle Perl objects?

DBD::SQLite
(http://search.cpan.org/~msergeant/DBD-SQLite-0.29/lib/DBD/SQLite.pm)

DBD::Sprite
(http://search.cpan.org/~turnerjw/DBD-Sprite-0.47/lib/DBD/Sprite.pm)

DBD::Trini (Pure Perl DBMS)
(http://search.cpan.org/~miko/DBD-Trini-0.01/Trini.pm)

These *may* be what you're looking for.

HTH

--
Jim

Copyright notice: all code written by the author in this post is
released under the GPL. http://www.gnu.org/licenses/gpl.txt
for more information.

a fortune quote ...
Kerr's Three Rules for a Successful College: Have plenty of
football for the alumni, sex for the students, and parking for
the faculty.
 
A

Aaron Sherman

J Krugman said:
Is there a free RDBMS that can handle Perl objects?

Anything that can hold strings can hold the results of the Storable
module (which ships with Perl now). I don't know of any slick
implementations that allow you to transparently access the values
without going back through Storable for full RDBMSes, but you can do
quite a lot using MLDBM and MLDBM::Sync.

Enjoy!
 
R

Robert

Randal said:
If you want a free RDBMS, there's plenty. I recommend DBD::SQLite as
a serverless solution, or DBD::pg and PostgreSQL as a proper database.
Stay away from MySQL for new installations, no point in it anymore.
Simply wrong! Now once PG goes native on Windows THEN I see no point.
Until then MySQL it is. Firebird is looking really good as well. ;-)

Of course he didn't say a platform so the whole argument is a moot one.
 
A

Aaron Sherman

Robert said:
Simply wrong! Now once PG goes native on Windows THEN I see no point.
Until then MySQL it is. Firebird is looking really good as well. ;-)

Using google groups, so please understand I would have set a
followup-to if I could :-(

MySQL is the easiest database to maintain that I've ever used. It fits
in with the UNIX Tao quite nicely and manages tables the way a UNIX
admin would expect.

This is in stark contrast to just about every other DB I've used, so I
use MySQL pretty much exclusively (especially after having to install
PostgreSQL once and having admined Oracle for a few years).

PostgreSQL is a nice database, and I'm glad MySQL has competition that
keeps it moving forward (as the PostgreSQL folks have had the same),
but as soon as sub-selects appear in a stable release my last reason
for considering anything else will evaporate (though if you need
sub-selects, you probably have a serious problem with your data
architecture in most cases).

Back to Perl: you should be designing your code so that it will work
with any back-end and carefully isolating database-specific features
using your choice of abstraction model. MySQL is great for rapid
prototyping, but in a produciton environment, you may find that you
need certain performance tuning features more readily available in
Oracle. Or you may find that you have to talk to an existing DB2
back-end. Always best to modularize the back-end.
 
T

thumb_42

Aaron Sherman said:
Using google groups, so please understand I would have set a
followup-to if I could :-(

MySQL is the easiest database to maintain that I've ever used. It fits
in with the UNIX Tao quite nicely and manages tables the way a UNIX
admin would expect.

I'd have to agree with Randall Schwartz on this one. (well, kind of anyhow..)

Postgresql is better as a "proper database". Supports transactions, and as
far as I know, always did. MySQL - maybe it does, maybe it doesn't, you have
to check to be sure.

Transactional support is essential for any serious work.

MySQL is nice when you have data that is almost always read-only, until it
ships with transaction support enabled by default, AND mysql with
transaction support is most common, I don't trust it. (maybe it's changed
some since I last truly explored it)

I'd much perfer mysql for an addressbook, but even a recipe collection could
be riddled with issues, since the ingredients might be relational you could
end up with missing parts. If the application has no real support for adding
recipes, (Ie: it's added once or on occasion from a mirror or something, and
you just need a web query interface then MySQL might be an ideal choice)

Of course, mysql IS more common than postgresql. :-(

Jamie
 
R

Robert

I'd have to agree with Randall Schwartz on this one. (well, kind of anyhow..)

Postgresql is better as a "proper database". Supports transactions, and as
far as I know, always did. MySQL - maybe it does, maybe it doesn't, you have
to check to be sure.

Transactional support is essential for any serious work.

I would say that there are a whole bunch of sites currently on the
Internet that would disagree with you.
MySQL is nice when you have data that is almost always read-only, until it
ships with transaction support enabled by default, AND mysql with
transaction support is most common, I don't trust it. (maybe it's changed
some since I last truly explored it)

I'd much perfer mysql for an addressbook, but even a recipe collection could
be riddled with issues, since the ingredients might be relational you could
end up with missing parts. If the application has no real support for adding
recipes, (Ie: it's added once or on occasion from a mirror or something, and
you just need a web query interface then MySQL might be an ideal choice)

Of course, mysql IS more common than postgresql. :-(

Jamie

It IS more common and it does better as a x-plaform solution. Postgresql
is working on that. By that time though Firebird 1.5 will be out and I
will be using it. It is a *proper* database and x-platform to boot.

Robert
 
C

Chris

Randal said:
Stay away from MySQL for new installations, no point in it anymore.

Because why? I'm really curious as to your reason for stating this like
you did without at all implying that I disagree (since you mention
PostgreSQL).

Chris
 
C

Chris

Robert said:
Simply wrong! Now once PG goes native on Windows THEN I see no point.
Until then MySQL it is. Firebird is looking really good as well. ;-)

Of course he didn't say a platform so the whole argument is a moot one.

Maybe it would be prudent to ask Randal why he said what he said rather
than responding like this. Surely he has a good reason for saying so.
It's not like Randal's some clueless newbie Perl poster... Since I've
already asked him, maybe you would enjoy considering his reason(s) when
he responds.

I'm not sure how Firebird validates the existance of MySQL...?

Chris
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,482
Members
44,901
Latest member
Noble71S45

Latest Threads

Top