Для случая, если в проекте используется много 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 запросах), в угоду читабельности (или еще по каким-либо другим причинам), разумнее хранить их в чистом виде, а это зависит от сложности самих запросов в частности.
УдалитьЧто же касается относительно простых запросов, то да, приведённые Вами инструменты вполне для этого подходят.