# aptitude search ulog
p fprobe-ulog — export captured traffic to remote NetFlow Collector (ULOG version)
p ulog-acctd — Accounting daemon for Linux 2.4+ netfilter
p ulogd — The Netfilter Userspace Logging Daemon p ulogd-mysql — MySQL extension to ulogd
p ulogd-pcap — pcap extension to ulogd
p ulogd-pgsql — PostgreSQL extension to ulogd
p ulogd-sqlite3 — SQLite 3 extension to ulogd
При аплоаде больших файлов на фронтед (nginx) сервер, файл потом копируется на бэкенд (apache + php) сервера, происходит это по продолжительности дольше чем таймаут nginxa, в итоге получаем ошибку. Как актуально побороть этот недостаток? Решение не искал — лениво подхожу к делу, еще руки не добрались. Заранее спасибо.
Пример из MySQL 5.0 Reference Manual. CONVERT:
INSERT INTO utf8table (utf8column)
SELECT CONVERT(latin1field USING utf8) FROM latin1table; CAST:
INSERT INTO utf8table (utf8column)
SELECT CAST(latin1field AS CHAR CHARACTER SET utf8) FROM latin1table;
Всетаки надежность и производительность становится модным. Упрощение структур данных, масштабируемости и скорости разработки за счет фреймворков, и решений представления и обмена данных близкому по смыслу к рассуждению человека плачевны. Все сказывается на производительности и надежности, а конкретно на авторитете программистов - теперь ненужно знать азов языка программирования. Каркасы написаны - строй что хочешь. Лень двигатель прогресса, но и незабудьте и о регрессе. В университете заставляли писать программный код, который реализован был уже давным давно в стандартных библиотеках и функциях, писала вся группа, но при этом подходы решений были разные.
P.S. Никого не решил задеть, помните о спирали жизни. Скорее это напутствие молодым ребятам, не бойтесь становится инженерами. Комментарий вышел ужасный и трудный. :) Текст вылился, жалко удалять.
Вы ребята забываете о трейсе, забываете о технических комментариях.
Отрывки кода в один условный оператор, не имеют не какой ценности - дайте исходники в зал.
P.S. Иногда сам пишу для себя, в таком стиле при разработке - как в примере 2-а, т.к. за целый день успеть все сделать не успеваю. Но только для себя, а все остальное - вытекающее причины не завершения кода.
Далее можно перейти к денормализации БД за счет избыточности названий объектов и их свойств : (Наш космос: id, x, y, object_name) -< (Свойства объектов: id, name[, type,] value).
Денормализация за счет использования XML (PostgresSQL хвалят) и JSON:
(Наш космос: id, x, y, object_name, name[, type,] xml_or_json_value).
Нужно учесть функциональность ПО а именно, к каким полям будут выполняться запросы, т.к. в случае с использованием XML или JSON, нужно индексировать большое количество данных и осуществлять медленный поиск (xml_or_json_value LIKE '%значение%').
P.S. Есть множество решений построения архитектуры БД. Для достижения высокой производительности и максимальной зажатости данных, нужно рассматривать впервую очередь поведения самого ПО, на вооружение можно взять примеры UML-диаграмм. И не забываем про постреляционные БД.
# aptitude search ulog
p fprobe-ulog — export captured traffic to remote NetFlow Collector (ULOG version)
p ulog-acctd — Accounting daemon for Linux 2.4+ netfilter
p ulogd — The Netfilter Userspace Logging Daemon
p ulogd-mysql — MySQL extension to ulogd
p ulogd-pcap — pcap extension to ulogd
p ulogd-pgsql — PostgreSQL extension to ulogd
p ulogd-sqlite3 — SQLite 3 extension to ulogd
CONVERT:
INSERT INTO utf8table (utf8column)
SELECT CONVERT(latin1field USING utf8) FROM latin1table;
CAST:
INSERT INTO utf8table (utf8column)
SELECT CAST(latin1field AS CHAR CHARACTER SET utf8) FROM latin1table;
Via: http://dev.mysql.com/doc/refman/5.0/en/c…
P.S. Никого не решил задеть, помните о спирали жизни. Скорее это напутствие молодым ребятам, не бойтесь становится инженерами. Комментарий вышел ужасный и трудный. :) Текст вылился, жалко удалять.
Отрывки кода в один условный оператор, не имеют не какой ценности - дайте исходники в зал.
P.S. Иногда сам пишу для себя, в таком стиле при разработке - как в примере 2-а, т.к. за целый день успеть все сделать не успеваю. Но только для себя, а все остальное - вытекающее причины не завершения кода.
Далее можно перейти к денормализации БД за счет избыточности названий объектов и их свойств : (Наш космос: id, x, y, object_name) -< (Свойства объектов: id, name[, type,] value).
Денормализация за счет использования XML (PostgresSQL хвалят) и JSON:
(Наш космос: id, x, y, object_name, name[, type,] xml_or_json_value).
Нужно учесть функциональность ПО а именно, к каким полям будут выполняться запросы, т.к. в случае с использованием XML или JSON, нужно индексировать большое количество данных и осуществлять медленный поиск (xml_or_json_value LIKE '%значение%').
P.S. Есть множество решений построения архитектуры БД. Для достижения высокой производительности и максимальной зажатости данных, нужно рассматривать впервую очередь поведения самого ПО, на вооружение можно взять примеры UML-диаграмм. И не забываем про постреляционные БД.
P.S.: Интересно, какую фразу скажет мистер Брин, в первые секунды старта?