There is also the common development method where you don't bother with any SQL or relational DDL at all, i.e. you don't have a preexisting database you have to work with so you can just write your domain model in the ORM syntax and it will deploy and manage the DDL and SQL for the target platform.

There are ORMs like DBIx::Class in Perl, Hibernate in Java, SQLAlchemy in Python, etc. where you write up class files which have entities, their attributes and relationships to the other entities, i.e. the domain object model and the ORM gives you the syntax to clearly and granularly define how you want your domain model to map to the relational database and it will create the relational database based on your class definitions, you don't have to worry about the relational side much at all. More importantly you don't have to worry about any SQL when using such objects in your business logic, there is syntax provided by the ORM to allow you to define what should happen when, e.g. in one transaction or even nest transactions and you just deal with objects, the ORM nicely does the back-end hassle for you.

Now DBIx::Class is different in many ways to Hibernate and SQLAlchemy, it doesn't follow the full OOP way that the others do and has similar syntax to for example Ruby's ActiveRecord. In Hibernate and SQLAlchemy you define real OOP classes for each of you entities and they follow the standard OOP conventions of that language for defining attributes and methods that get entity relationships. Hibernate and SQLAlchemy give you annotations/decorations that you put on top of the class definition code to tell Hibernate and SQLAlchemy how to do the relational mapping. You typically never do any SQL at all you just work in OOP land in your business logic code and the backend ORM engine manages what needs to be done on the DBMS side.

I've mentioned possibly having this type of ORM capability for the future version of DBIx::Class, for example one could forgo the current syntax used to define your object-relational mapping and do this instead: write normal Moose class files and have them decorated/annotated with DBIx::Class syntax to define the mapping and also any specific options if you want to change default or add optional ORM behaviors.

Now I know there is some criticism of these OOP-centric ORMs, I'm not advocating them for everything just mentioning that they can be quite appropriate for certain projects and design strategies, especially if you want to always work in OOP and not worry about SQL much. DBIx::Class for example is in my mind much more flexible at doing very difficult database mappings and operations than the OOP-centric ones, but you then forgo working with Moose objects for you entities.

---

---

• Are you posting in the right place? Check out Where do I post X? to know for sure.
• Posts may use any of the Perl Monks Approved HTML tags. Currently these include the following:

  <code> <a> <b> <big> <blockquote> <br /> <dd> <dl> <dt> <em> <font> <h1> <h2> <h3> <h4> <h5> <h6> <hr /> <i> <li> <nbsp> <ol> <p> <small> <strike> <strong> <sub> <sup> <table> <td> <th> <tr> <tt> <u> <ul>

• Snippets of code should be wrapped in <code> tags not <pre> tags. In fact, <pre> tags should generally be avoided. If they must be used, extreme care should be taken to ensure that their contents do not have long lines (<70 chars), in order to prevent horizontal scrolling (and possible janitor intervention).
• Want more info? How to link or How to display code and escape characters are good places to start.