Как правильно организовать и защитить таблицу в которой будет хранится balance пользователя?

Так о том и речь - выбираете сами состав полей. Подписываете то, что для вас критично. Я не очень понимаю, где много-то) Вы подписываете текущее состояние баланса и всё, если для вас критичен именно баланс. Ещё какие-то данные - на ваше усмотрение. Баланс с ключом можно подсолить перед хешированием для надежности.

Как правильно организовать и защитить таблицу в которой будет хранится balance пользователя?

Секретный ключ в бд не хранится, в бд хранится sha1 или md5 значимых данных, сконкатенированных с секретным ключом. Набор значимых данных вы определяете самостоятельно исходя из здравого смысла. Если вам важно, чтобы не накрутили баланс - подписываете баланс. Нужно еще что-то - добавляете эти данные к подписи.

Как правильно организовать и защитить таблицу в которой будет хранится balance пользователя?

Мне показалось, что у вас транзакции отдельно, а баланс - отдельно, в разных таблицах. И грубо говоря две процедуры - списание и пополнение (вставка транзакции + апдейт баланса). Я имела в виду, что у таблицы балансов можно сделать отдельное поле, скажем, signaure и подписывать текущее состояние баланса (остаток на счете) секретным ключом после проведения каждого списания и пополнения. А до проведения списания/пополнения - проверять эту подпись. Если подпись не сходится - транзакция не проводится.

Хочу, чтобы в модуле виделись глобальные переменные скрипта, возможно ли?

Рада, что решили проблему. Кстати, для сокращения кода настройки сайта в кэш можно записывать под ключом $ENV{DOCUMENT_ROOT}.

sub SiteSetting {
my $key = shift || return();
my $site_id = $ENV{DOCUMENT_ROOT};

if ( exists $SETTING{$site_id}->{$key}  ) {  
return $SETTING{$site_id}->{$key};  
} else {
my $sql = sql("SELECT key,value FROM setting WHERE key='$key';");
     if ($$sql[0] eq $key) {
        $SETTING{$site_id}->{$key} = $$sql[1];
        return $SETTING{$site_id}->{$key};
} else {  return;  }
}
}

Таким образом к тому же не потрутся настройки остальных сайтов. Собственно, $ENV{DOCUMENT_ROOT} здесь как раз используется в качестве идентификатора сайта для кеширования, о котором я писала выше.

Хочу, чтобы в модуле виделись глобальные переменные скрипта, возможно ли?

Странная у вас ситуация с организационной точки зрения. У вас shared хостинг? Если всё так как вы описали, у вас 2 выхода — передавать в каждую функцию либо записывать в %ENV. Но так делать не надо, потому что это через одно место.

Вообще кэширование переменных на время жизни воркера в mod_perl — сомнительная фича, скорее похожая на багу, что и демонстрирует ваша ситуация. Поэтому если на сайте нет особой нагрузки, можно обнулять кэш при каждом клике (т.е. кеширование будет только в рамках одного клика), либо (что лучше всего) перенести сайт на VPS и делать там что угодно с кэшированием, не опасаясь зачерпнуть каких-то левых данных.

Объясните НДС

Про НДС нужно помнить только в контексте той системы налогообложения, которая применяется у вас. Вас прежде всего должно интересовать уменьшение налоговой базы. Последний раз изучала вопрос года два назад, но не думаю, что все сильно поменялось. Если у вас объект налогообложения «доходы минус расходы», то НДС, уплаченный поставщикам, просто списывается на расходы, уменьшая налогооблагаемую базу.

Установка сервера SVN

Это просто хороший тон и избавляет от случайностей, которые могут закончиться печально. Можно поменять веб-сервер и забыть прописать ограничение в конфиге, да еще много чего. Если svn дает такую возможность, почему бы не воспользоваться? Не вижу смысла вставлять костыли там, где можно обойтись без них.

Какую книгу про Linux почитать?

Я к вам не придираюсь, но все же Эви Немет — женщина, поэтому ее фамилия не склоняется :)