Предыдущая часть. Мы написали код, теперь время создать таблицы в нашей базе данных. Что бы сделать это — сначала на «активировать» наши модули в нашем Django-проекте. Мы сделаем это, добавив приложение books в список установленных приложений в файле настроек. Откройте файл settings.py в редакторе и найдите опцию INSTALLED_APPS. Она указывает Django, какие приложения активны в данном проекте.… Читать далее »
Предыдущая часть. В качестве примере в этой и следующих главах — мы будем использовать модель данных книга/автор/издатель (book/author/publisher). Мы используем её, так как связи между книгой, автором и издателем хорошо всем известны, и это достаточно распространённая модель, используемая в учебниках по SQL. Мы предлагаем следующие понятия, поля и связи: У автора есть имя, фамилия и… Читать далее »
Предыдущая часть. Как мы уже обсуждали ранее в этой главе, «M» в MVT означает «Model«. Модель в Django — это описание данных в вашей базе данных, представленная в виде кода на Python. Это ваш уровень данных — эквивалент SQL запроса CREATE TABLE, но записанный в Python вместо SQL и включает в себя больше, чем просто описание… Читать далее »
Предыдущая часть. Теперь, когда мы разобрались с моделью MVC, давайте разберёмся с уровнем баз данных в Django. Для начала, нам потребуется выполнить некоторую начальную настройку — мы должны сказать Django, где находится сервер баз данных и как к нему подключиться. Мы предполагаем, что у вас уже установлен и настроен сервер баз данных. Если вы используете SQLite —… Читать далее »
Оглавление Глава 3 Введение В Главе 1 мы рассмотрели основы построения динамических веб-сайтов с помощью Django: настройка представлений и URLconfs. Как мы поясняли, представления отвечают за обработку неких логических построений, и возвращают ответ в виде объекта HttpResponse. В наших примерах этими логическими построениями было вычисление даты и времени. В современных веб-приложениях подобные построения как правило включают в… Читать далее »
Иногда необходимо сохранить результаты запроса во внешний файл. Это можно сделать, добавив INTO OUTFILE к запросу SELECT. Подробнее тут>>>. Например: MariaDB [rtfm_db1]> SELECT option_name FROM db1_options WHERE option_name LIKE ‘_transient_timeout%’ INTO OUTFILE ‘/tmp/transient_timeout.txt’; Query OK, 20 rows affected (0.09 sec)
Что бы вести лог всех обрабатываемых запросов к базам — можно включить ведение general_log. Бывает полезно, что бы отследить какие-то запросы от скриптов. Проверить включен ли он можно так: MariaDB [(none)]> SHOW VARIABLES LIKE ‘general_log’; +—————+——-+ | Variable_name | Value | +—————+——-+ | general_log | OFF | +—————+——-+
Среди прочих данных tuning-primer сообщает что: QUERY CACHE Query cache is supported but not enabled Perhaps you should set the query_cache_size query_cache — это область памяти, выделяемая MySQL при старте, в которой хранятся запросы и их результаты типа SELECT. При получении нового запроса SELECT — MySQL сначала проверяет нет ли такого же запроса в этом кеше и,… Читать далее »
Параметр key_buffer_size задаёт размер памяти, выделяемый под хранение индексных блоков для таблиц типа MyISAM, которые могут быть считаны из памяти, вместо того, что бы обращаться к диску для чтения. key_buffer_size — один из наиболее важных параметров в настройке производительности MySQL. Данный буфер является общим для всех пользовательских процессов. Что бы узнать, необходимо ли изменять текущее значение key_buffer_size —… Читать далее »
Продолжение серии MySQL/MariaDB: тюнинг производительности. Размер innodb_buffer_pool_size Один из самых спорных вопросов, это «Какое значение указывать в innodb_buffer_pool_size«. Хорошая статья на эту тему есть тут>>>. innodb_buffer_pool_size определяет размер памяти, называемой buffer pool, которая будет использоваться для хранения данных и индексов таблиц с типом InnoDB.