Для случая, если в проекте используется много SQL-запросов, имеет смысл вынести их в отдельный модуль(и), в котором организовать их храненение в виде хеша, ключи которого будут указывать назначение конкретного запроса. Эдакая разновидность документации непосредственно с использованием кода. Само же хранение всех SQL-запросов в одном месте упрощает их использование.
Пример:
SQLQueries.pm - каталог запросов.
test.pl - основная программа.
Пример:
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;
Это очень наивный подход.
ОтветитьУдалитьЛучше использовать любой доступный на CPAN ORM-фреймворк (например, DBIx::Class, DBIx::Skinny и т.д.) или, если полноценный ORM не нужен, можно взять генератор SQL (SQL::Abstract, SQL::Maker).
Скорее наивный пример, так как в некоторых случаях (SQL запросах), в угоду читабельности (или еще по каким-либо другим причинам), разумнее хранить их в чистом виде, а это зависит от сложности самих запросов в частности.
УдалитьЧто же касается относительно простых запросов, то да, приведённые Вами инструменты вполне для этого подходят.