эээх, сам спросил сам ответил)
Итак, на что собственно нужно обратить внимание:
MySQL
- поменять date_format(now() '%d.%m.%Y'); to_char( now(), 'DD.MM.YYYY' );
- если нужно использовать unix_timestamp() (я ее использую для передаче dateDiff функции в PHP), то пишем:
CREATE OR REPLACE FUNCTION unix_timestamp(timestamp without time zone)
RETURNS integer AS
$BODY$
SELECT date_part('epoch', $1::timestamp)::INTEGER AS RESULT
$BODY$
LANGUAGE sql VOLATILE
COST 100;
- убрать все хаки производительности в запросах. Без глубочайшего знания PosgreSQL это все бесполезно. Сколько я ни экспериментировал, оптимизатор postgre оказывался умнее, хотя с MySQl у меня таких проблем нет.
- убрать всевозможные указания на использования индексов итд
- изучить типы данных postgre, ибо таблицы все придется переносить очень внимательно. Тот же some_id int(10) unsigned not null auto_increment превращается в some_id serial
- ну и листать на досуге документацию, ибо MySQL по сравнению с Posgre есть жуть недоразвитая.
PHP
- тут надо бы написать свою обертку вокруг pg_prepare и прочих функций, я себе сделал наподобие той, что у меня была для MySQL, но пока еще не все нюансы вылизал.
- Учесть, что prepared запросы postgre хранит на соединение, это нужно учитывать, иначе pg_prepare кидает ошибку. Я себе сваял нечто, вроде:
private static function getPrepared()
{
$result=pg_query(self::$pgConn, 'SELECT name FROM pg_prepared_statements');
while ($data=pg_fetch_object($result))
{
self::$prepareds[(string)$data->name]=1;
}
}
PostgreSQL
- сразу как только загрузите бд 1с, лучше выполнить analyze по всем таблицам
- затюнить бд, методом правки конфига
- Если будете использовать View на таблицы 1с (я их создаю пачками, ибо работать с document132._field1439_rref Нет никакого желания), то создавайте их в отдельной схеме и дропайте ее перед внесением серьезных изменений в конфигурацию (и не забываем про бекапы). При внесении серьезных изменений, скажем добавление реквизита, 1с попытается дропнуть таблицу (да-да, они не знают что такое alter), но при наличии на этой таблице зависимостей, выдаст критическую ошибку. При такой ошибке ни в коем случае нельзя закрывать конфигуратор, можно просто убрать зависимости и нажать обновить еще разок. Если закрыли конфигуратор то вам предстоит весьма увлекательный квест (хотя вариантов решения проблемы есть 2.5).
- Аналогично нужно помнить о триггерах и собственных индексах на таблицах, они не помешают 1с дропнуть таблицу, но сами естественно умрут вместе с ней.
1с
У 1с начиная с версии 8.2.какойтотам есть механизм подключения к внешним источникам данных. В 8.3 с ними даже можно работать на запись и модификацию довольно нативно, а так же использовать функции. Огромный плюс в том, что подцепив таблицу с нужным перечнем полей, можно использовать все это дело как реквизит во всех элементах конфигурации, а так же использовать в запросах. Единственный баг, который я наблюдаю и у 8.2 и у 8.3: соединение с бд то есть постоянное, то выдает окно подключения, то подвисает на нем. Решение:
//mydb - имя источника данных заданное в 1с
Параметры = ВнешниеИсточникиДанных.mydb.ПолучитьОбщиеПараметрыСоединения();
Параметры.АутентификацияСтандартная = Истина;
Параметры.ИмяПользователя = "user";
Параметры.Пароль = "password";
Параметры.СтрокаСоединения = "DRIVER={PostgreSQL Unicode(x64)};SERVER=127.0.0.1;port=5432;UID=user;PWD=password;DATABASE=somedb";
Параметры.СУБД = "PostgreSQL";
ВнешниеИсточникиДанных.mydb.УстановитьОбщиеПараметрыСоединения(Параметры);
ВнешниеИсточникиДанных.mydb.УстановитьПараметрыСоединенияПользователя(ИмяПользователя(), Параметры);
ВнешниеИсточникиДанных.mydb.УстановитьПараметрыСоединенияСеанса(Параметры);
ВнешниеИсточникиДанных.mydb.УстановитьСоединение();
Ну вот вроде все, что пока вспомнил 8)
Простой
