Сообщений в теме: 6

[Analitic]

Вниманию разработчиков! На Saas в конце июня планируется переход на Postgresql. В связи с чем, рекомендуем использовать только функции из набора sql_select, sql_query, sql_fetch_assoc, sql_insert_id и т.п. описанные в файлах mysql_connect.php и sql_functions.php. При переходе в файле config.php будет изменен параметр db_engine. Стандартные функции сохранят свою работоспособность.

Также напоминаем, что К.б. будет постепенно подключать и остальные sql базы, вплоть до подключения движка nosql. Учитывая что базы имеют различный синтаксис, рекомендованный стиль обращения к базе:
1. использовать только стандартные функции Кб.
2. если возможно использовать sql_select, вместо sql_query, то использовать именно sql_select
3. использовать простые запросы, без использования конструкций типа join, union и т.п.

Пример выборки из двух таблиц:
не рекомендуемый стиль:
$result=sql_query("SELECT a.id, b.f441 as fio FROM f_data46 a LEFT JOIN f_data48 b ON b.id=a.f776 WHERE `status`=0");
$line = sql_fetch_assoc($result);

рекомендуемый стиль:
$result=data_select_field(46, '`id` , `f776`', '`status`=0');
$line = sql_fetch_assoc($result);
$result = data_select_field(48, '`f441`', '`id`=',$line['f776']);
$row = sql_fetch_assoc($result);
$line['fio'] = $row['f441'];

В этом случае LEFT JOIN разделяется на 2 простейших запроса, что позволяет ему выполняться на любой базе, а также предоставляет возможность практически неограниченно расширять базу данных, вплоть до того что разные таблицы могут быть расположены на разных серверах.

Ваши вопросы?

[wondertalik]

1. Будут ли оставаться сервера c mysql?
2. Второе возможно ли будет остаться на mysql, до момента готовности перейти на postgresql?
3. Использование стандартных функций(оберток, не всегда целесообразно), особенно это важно для вычислений при отображении поля, где важно оценивать реальную нагрузку на сервер и времени выполнения вычисления.
4. Вы предлагаете разбивать многотабличные запросы на несколько простых, с точки зрения масштабируемости это конечно да. Но опять же с точки зрения балансировки нагрузки между тем же вычислением на php и бд это не всегда верное решение и приведет к увеличению требования к выделенным возможностям саас аккаунтов, переходам на более высокие тарифные планы.

Я конечно понимаю причины перехода на объектно-реаляционную бд, но простите, оставьте выбор вашим клиентам. Я правильно понимаю, что db_engine будет содержать значения по типу "MySql" or "PostgreSql"?

Что скажите по поводу такого синтаксиса? То есть использования функций вида mysql_*?

$result = mysql_query($sqlQuery);
$select = mysql_fetch_assoc($result);

mysqli?

/* Select запросы возвращают результирующий набор */
if ($result = $mysqli->query("SELECT Name FROM City LIMIT 10")) {
    printf("Select вернул %d строк.\n", $result->num_rows);
    /* очищаем результирующий набор */
    $result->close();
}

Сообщение отредактировал wondertalik: 29 Май 2013 - 11:23

[Analitic]

wondertalik (29 Май 2013 - 11:18) писал:

1. Будут ли оставаться сервера c mysql?
2. Второе возможно ли будет остаться на mysql, до момента готовности перейти на postgresql?

Да, старые клиенты, при необходимости будут располагаться на серверах с Mysql. Новые будут создаваться на PostgreSql.

wondertalik (29 Май 2013 - 11:18) писал:

3. Использование стандартных функций(оберток, не всегда целесообразно), особенно это важно для вычислений при отображении поля, где важно оценивать реальную нагрузку на сервер и времени выполнения вычисления.

Да. Любая обертка предоставляет плюсы, и имеет минусы (как правило в производительности). Потеря производительности минимальна (замерьте сами), плюсы огромны (безопасность из коробки, независимость от базы).

wondertalik (29 Май 2013 - 11:18) писал:

4. Вы предлагаете разбивать многотабличные запросы на несколько простых, с точки зрения масштабируемости это конечно да. Но опять же с точки зрения балансировки нагрузки между тем же вычислением на php и бд это не всегда верное решение и приведет к увеличению требования к выделенным возможностям саас аккаунтов, переходам на более высокие тарифные планы.

Балансировать нагрузку от PHP вообще не проблема. Просто добавляем еще один сервер, направляем часть нагрузки на него используя балансировщик. При добавлении сервера, производительность возрастает вдвое. Это касается любого более менее крупного проекта. С базой все гораздо хуже. Отсюда и появляются решения типа nosql.

wondertalik (29 Май 2013 - 11:18) писал:

Я конечно понимаю причины перехода на объектно-реаляционную бд, но простите, оставьте выбор вашим клиентам. Я правильно понимаю, что db_engine будет содержать значения по типу "MySql" or "PostgreSql"?

Объектов тут нет, чисто процедурный стиль. Выбор оставляем: если вы уже пользуетесь MySql, и переход на PostgreSql для вас не возможен смотри пункт1.

wondertalik (29 Май 2013 - 11:18) писал:

Что скажите по поводу такого синтаксиса? То есть использования функций вида mysql_*?

Желательно переписать на

$result = sql_query($sqlQuery);
$select = sql_fetch_assoc($result);

mysqli?

/* Select запросы возвращают результирующий набор */
if ($result = sq_query("SELECT Name FROM City LIMIT 10")) {
	printf("Select вернул %d строк.\n", sql_num_rows($result));
}

// $result->close(); - очистка не используется, если необходимо можем добавить поддержку.

[Analitic]

wondertalik (29 Май 2013 - 11:18) писал:

Я правильно понимаю, что db_engine будет содержать значения по типу "MySql" or "PostgreSql"?

Параметр db_engine уже сейчас может содержать 'innodb' либо 'myisam', новое значение параметра скорее всего будет 'postgre'.

[wondertalik]

Analitic (29 Май 2013 - 11:52) писал:

// $result->close(); - очистка не используется, если необходимо можем добавить поддержку.

Было бы очень хорошо.

[Analitic]

wondertalik (29 Май 2013 - 12:28) писал:

Было бы очень хорошо.

В следующей ревизии появиться функция sql_free_result.

[wondertalik]

Analitic (29 Май 2013 - 13:13) писал:

В следующей ревизии появиться функция sql_free_result.

Данке