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

LINQ/Ambition for Perl?

by Anonymous Monk
on Sep 28, 2007 at 22:03 UTC ( [id://641621]=perlquestion: print w/replies, xml ) Need Help??

Anonymous Monk has asked for the wisdom of the Perl Monks concerning the following question:

LINQ (http://msdn2.microsoft.com/netframework/aa904594.aspx) and Ambition (http://railsontherun.com/2007/9/16/ambition-why-should-you-care) lets you write database queries in a "real language" instead of SQL.

Do we have something similar in Perl?

Replies are listed 'Best First'.
Re: LINQ/Ambition for Perl?
by erroneousBollock (Curate) on Sep 29, 2007 at 03:58 UTC
    LINQ is not really about writing SQL queries in a real language. It's about providing declarative access to all kinds of data (such as is found in most functional programming languages).

    Microsoft has already implemented LINQ access to

    • classes implementing IEnumerable<T>
    • the XML DOM
    • relational databases

    I've never seen Ambition so I can't comment on it.

    What you seem to be after is an EDSL (embedded domain specific language) for SQL. Update: DBIx::perlish, DBIx::Abstract might be worth a try.

    Also, there's nothing stopping you adding XML and enumerator support to any existing perl data-access library.

    -David

      Thanks for the reply and the explanation. Glad to see that we have something similar in Perl. The approach is interesting for me, as I have since always hated writing SQL statements, especially embedded inside Perl.

      But now, do lots of people really use this stuff to a moderate degree of complexity in the real-world, in the production? By moderate complexity I mean a set of at least 100 or so tables, queries which is up to a screen in length, 5+ joins, and the like.

        But now, do lots of people really use this stuff to a moderate degree of complexity in the real-world, in the production?
        I certainly don't. For that matter, I don't usually embed SQL in my code. I prefer to look at a database as a separate service with its own APIs, whether they are implemented as perl with DBI or C with PL/SQL. I feel the data tier should be separately testable and that changes to the database structure should not effect the applications that use it.

        By moderate complexity I mean a set of at least 100 or so tables, queries which is up to a screen in length, 5+ joins, and the like.
        I feel that if you've got 100 tables, you're likely suffering from bad design. If the schema is not digestible by a single human at a glance, then it's a likely candidate for being broken into multiple co-operative systems.

        Similarly, if you're frequently joining over 5 tables, it's probably because you've over-normalized. Normalization is important, but not at the expense of performance and understandability.

        There are exceptions: Sequencing over archive tables is a good use of many joins/unions. Joining over many static lookup tables (int -> string) is probably not a good idea - likely you want to fetch and cache the lookup tables to hashes on the client; it's cheaper to send INTs to the client for the main queries.

        I have no problem with complicated queries, but I often find that they're mostly unnecessary and/or performance killers. If you treat the database as an API you can layer a minimal amount of code around the database to implement the API. Treated as a separate entity that API is free to implement appropriate caching and replication semantics where they're most useful.

        -David

        I know this is an old thread but I can't help but adding my 2c. IMO, linq is awesome but only for linq to objects or linq to xml. As a replacement for SQL it's not really that useful imo. It just adds an extra unnecessary layer that makes it more difficult to debug and optimise. It's also more difficult to write and makes it very difficult or impossible to use some of the newer features of a database. It usually reduces performance as it can add extra complexity to the underlying sql. If your motivation is to avoid learning sql then just learn sql.

        The only place it could be useful is if you want your app to target a number of databases. However it's probably better just to write simple SQL that will work with many DBs.

Re: LINQ/Ambition for Perl?
by dragonchild (Archbishop) on Sep 28, 2007 at 22:15 UTC
    Not yet (that I'm aware of). I have been planning on using something LINQ-based as the query langauge for Presto, but I haven't had time to work on it in the past year. Soon, I hope.

    My criteria for good software:
    1. Does it work?
    2. Can someone else come in, make a change, and be reasonably certain no bugs were introduced?

Log In?
Username:
Password:

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

How do I use this?Last hourOther CB clients
Other Users?
Others cooling their heels in the Monastery: (4)
As of 2024-03-29 14:58 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found