четверг, 24 сентября 2015 г.

Каталог SQL-запросов

Для случая, если в проекте используется много SQL-запросов, имеет смысл вынести их в отдельный модуль(и), в котором организовать их храненение в виде хеша, ключи которого будут указывать назначение конкретного запроса. Эдакая разновидность документации непосредственно с использованием кода. Само же хранение всех SQL-запросов в одном месте упрощает их использование.

Пример:

SQLQueries.pm - каталог запросов.
package SQLQueries;

use strict;
use warnings;

use base 'Exporter';

our @EXPORT_OK = qw/$sql_hash/;

our $sql_hash = {
    get_doctors => qq{
        select * from doctor limit ?
    },
    get_doctors_count => qq{
        select count(*) from doctor
    }, 
    update_cool_doctor => qq{
        update doctor set name = 'Ivan' where is_cool = ?
    } 
};

1;

test.pl - основная программа.
use strict;
use warnings;

use Data::Dumper;
use DBIx::Connector;
use SQLQueries qw($sql_hash);

my $conn = DBIx::Connector->new('dbi:Pg:dbname=doctors', 'doctor', '', {
    RaiseError => 1,
    AutoCommit => 1
});

my $rows = $conn->run(sub {
    $_->selectall_arrayref( $sql_hash->{ get_doctors }, { Slice => {} }, 1 );
});

print Dumper $rows;

2 комментария:

  1. Это очень наивный подход.
    Лучше использовать любой доступный на CPAN ORM-фреймворк (например, DBIx::Class, DBIx::Skinny и т.д.) или, если полноценный ORM не нужен, можно взять генератор SQL (SQL::Abstract, SQL::Maker).

    ОтветитьУдалить
    Ответы
    1. Скорее наивный пример, так как в некоторых случаях (SQL запросах), в угоду читабельности (или еще по каким-либо другим причинам), разумнее хранить их в чистом виде, а это зависит от сложности самих запросов в частности.

      Что же касается относительно простых запросов, то да, приведённые Вами инструменты вполне для этого подходят.

      Удалить