Beefy Boxes and Bandwidth Generously Provided by pair Networks
P is for Practical
 
PerlMonks  

Re: Mixing Mysql and Perl

by Ovid (Cardinal)
on Jan 09, 2004 at 23:18 UTC ( [id://320250]=note: print w/replies, xml ) Need Help??


in reply to Mixing Mysql and Perl

Basically, you're describing a multi-tiered application with clearly defined responsibilities for each tier. While there are many ways to go about this, one of the most popular is to use an object persistence framework. One that is fairly easy to use is Class::DBI. This module allows you to create objects that model your database tables. You can read a short tutorial at perl.com, if you're interested.

It's important to remember, though, that this is not always a good fit for your code. Objects are heirarchical in nature; MySQL is not (this is sometimes referred to as the "object-relational impedance mismatch"). Class::DBI sidesteps this issue by ignoring it and leaving it up to the programmer to deal with. However, it's dead simple to use, easy to integrate with an existing database and I'm a big fan of it.

Tangram is another object persistence framework that attempts to properly map the heirarchical nature of objects to databases. The documentation describes various strategies that Tangram supports and the pros and cons of them. Here's an interesting quote from the documentation:

One of the paramount issues about mapping inheritance is how well the mapping supports polymorphism. Any Object-Oriented persistence facility that deserves its name needs to allow the retrieval of all the Fruits, and return a heterogeneous collection of Apples, Oranges and Bananas. Also, it must perform this operation in an efficient manner. In particular, polymorphic retrieval should not cost one SELECT per retrieved object.

The issues that it describes are ones that Class::DBI has unless the programmer takes care to work around this.

Though I understand that Tangram can be fitted to an existing database, this is probably not optimal. Instead, you define a class heirarchy and allow Tangram to design the database for you. It seems pretty clean and Tangram is now being actively developed once again, so if you see older information on it, be aware that it may be out of date.

For more information, check out http://poop.sourceforge.net/. This is an excellent introduction to the pros and cons of many Perl OO Persistence strategies. In particular, it will tell you whether or not MySQL is supported.

Update: I almost forgot to mention Pixie. From the docs:

my $pixie = Pixie->new->connect( 'dbi:mysql:dbname=test', user => $user, pass => $pass); # Save an object my $cookie = $pixie->insert($some_object); undef($some_object); # Get it back my $some_object = $pixie->get($cookie);

Pixie basically says "forget about a framework, I just want to store an object." And that's what it does. Thus, you don't need to worry about designing the database. Simply use your objects and store and retrieve them as needed. No muss, no fuss. I've not used it, but it sounds very interesting.

Cheers,
Ovid

New address of my CGI Course.

Replies are listed 'Best First'.
Re: Re: Mixing Mysql and Perl
by exussum0 (Vicar) on Jan 10, 2004 at 01:48 UTC
    Pixie basically says "forget about a framework, I just want to store an object." And that's what it does. Thus, you don't need to worry about designing the database. Simply use your objects and store and retrieve them as needed. No muss, no fuss. I've not used it, but it sounds very interesting.
    Problem with stuff like that, is your objects and your tables don't always conincide. Most of the time they don't. For instance, say you have 4 or 5 types of users that all inherit from the same base object. Their base data may be the same, but the extended part of it may store differently. You wouldn't store ALL the data in one table and you may not wish to have certain columns laying about if your user types are grossly different.

    Pixie may be great for simple things, but if things get complex, modules like pixie would lead into an "interface represents your database model" which is a pitfall.


    Play that funky music white boy..

      sporty wrote: Problem with stuff like that, is your objects and your tables don't always conincide.

      sporty, have you ever looked at Pixie? I don't know what you mean by "objects and tables don't always coincide". The Pixie philosophy is simple: we want to persist objects. And that's all it does. There's no complicated framework or worrying about how the tables relate. You store objects. You retrieve objects. That's it.

      You also wrote "interface represents your database model". The underlying database is completely independant of the object interface and, in fact, that was one of the design goals. Pixie doesn't care what your interface is. However, I could be misunderstanding what your concerns are, so if you care to elaborate, I'd love to hear what you have to say.

      Disclaimer: I've not used Pixie either. I toss it out there because Piers Cawley (who's done a lot of work on Pixie) recommended it and I have a lot of respect for him.

      Cheers,
      Ovid

      New address of my CGI Course.

        Yes, I took a look at it.

        Your object attributes don't always coincide with your table columns. It's not always 1-1. And the pixie model may be great and all, but if you hook it up to a db, then you must care what it does for performance sake. A missing index could cause a world of trouble if pixie decided to pull back an object using the wrong method (verb, not object).

        If piexie doesn't care about how your db is laid out, then see above, it may not be using indicies correctly, or not doing thins in an efficient manner, ala selecting large groups of data (multiple rows etc..).

        If you haven't used pixie yourself, I'm not quite sure how you can be so confident in it, regardless of who wrote it, since the best programmers in the world can still make the strangest mistakes. You prolly won't believe me anyway, here is a document from IBM on pixie and it's drawbacks as well as its pluses.

        As you see, for small projects, it prolly does wonders, but for a huge project, I doubt I would look at it all that quickly, since custom SQL is usually better than that generated by a general api.

        -s


        Play that funky music white boy..
          A reply falls below the community's threshold of quality. You may see it by logging in.

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://320250]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others rifling through the Monastery: (6)
As of 2024-03-28 14:08 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found