mind3

я из мира MS SQL, поэтому возможны некоторые несоответствия:

SELECT rcp.*, cmp.*, tst.*
FROM recept AS rcp
  INNER JOIN recept_component AS rcp_cmp ON rcp.id = rcp_cmp.recept_id
  INNER JOIN component AS cmp ON cmp.id = rcp_cmp.parent_id
  INNER JOIN taste AS tst ON tst.recept_id = rcp.id

вместо звездочек указываете конкретные поля которые вас интересуют
т.о. будут выбраны ТОЛьКО рецепты длы которых существуют и вкусы и компоненты

Не знаю можно ли тут постить ссылки, но погуглите "tsql join" по картинкам и найдете все варианты join'ов с наглядным объяснением

Продавая рекламу на сайте много не заработать.

Необходимо создать нишевый блог, раскрутить и продавать товары / услуги / информацию в рамках партнерских отношения с экспертами в этой ниши.

Многие западные блоги по этой схеме зарабатывают порядка $100'000 в месяц.

Вот наглядное видео о первом таком эксперименте от Вишена Лакьяни и о том как он заработал $930'000 за 18 месяцев на блоге: https://www.youtube.com/watch?v=Ykcv2aSML5Y

Когда проникнитесь идеей, возьмите книгу с пошаговым планом по запуску Интернет-бизнеса с нуля: solodukha.com/thebook

Это бесплатно и там есть прям готовая стратегия по запуску подобных проектов.

Успехов!

Попробуйте сделать поле с UUID.
Вот документация
Оттуда:

A UUID is designed as a number that is globally unique in space and time. Two calls to UUID() are expected to generate two different values, even if these calls are performed on two separate computers that are not connected to each other.

Вам должно подойти.

UPD1. Как хранить:
Создаем поле типа BINARY( 16 ) (вместо int) и делаем его primary key.
Это получается потому-что мы из строки

110E8400-E29B-11D4-A716-446655440000

удаляем все тире и у нас получается

110E8400E29B11D4A716446655440000

Это 32 символа в шеснадцатеричной системе, если хранить в бинарной - получается 16. Преобразовать в бинарную можно с помощью такой конструкции:
UNHEX("110E8400E29B11D4A716446655440000")
Обратно:
HEX(field_binary)

С производительностью проблем никаких, т.к. храним число в бинарном виде.

Вот тут более подробно разобрано: stackoverflow

Бандлы - самодостаточные модули инкапсулирующие какие-то сервисы и прочую штуку. По сути это расширения для DependencyInjection, если очень грубо.

Модели - это те самые Entity грубо-говоря. Вообще есть такое понятие как Доменная-модель. Это просто структура данных, сущности которыми оперирует бизнес логика. Последняя должна быть инкапсулирована в сервисы (всякие UserManager, PostManager и т.д.). В Yii модели смешаны с сервисным слоем и по этому у вас получается путаница.

Что до кода... есть распространенный подход иметь свой AppBundle и фигачить все в нем. Есть так же рекомендуемый подход - не использовать бандлы вообще. То есть.... бандлы должны быть самодостаточны и их основное предназначение - реюз логики между проектами. Бизнес-логику приложения реюзать у вас не выйдет, поэтому рекомендуется просто писать код и регистрировать его в app/Resources/config/services.yml или что-то в этом духе, как именно решать вам. Профит в том что вы на замарачиваетесь всей этой фигней с бандлами и у вас возникает меньше вопросов по структуре. А если же вы захотели что-то вынести в бандл - например сервисы для авторизации которые реально можно реюзать, то вам никто не помешает это сделать. В итоге у вас будет структура проекта приблизительно такая:

| - app
| - var
| - src
  | - Controller
  | - Entity
  | - Bundle/
    | - MyAuthBundle/
| - web

ну как-то так. Как не странно такой подход не сильно распространен в Symfony-сообществе хотя его рекомендуют в недавно вышедшем бест практис буке и в принципе эта струтктура более чем логична.

Что до виджетов, в Symfony2 есть HMVC. То есть вы можете сделать эдакие под-запросы на другие контроллеры внутри вьюшек. Можно скажем все "виджеты" инкапсулировать как отдельный контроллер с методами и дергать их из вьюшек.

<div id="sidebar">
    {{ render(controller('AcmeArticleBundle:Article:recentArticles', {
        'max': 3
    })) }}
</div>

Это дает больше гибкости, внутри каждого контроллера можно дергать другие контроллеры. Можно прикрутить кеширование на уровне обработки запросов (кешировать скажем все подзапросы по каким-то критериям) и т.д.

Может стоит нормально миграции писать? doctrine:migration:diff дает вам основу для работы. Ее нужно проверить и поправить под ваши нужды.

Я думаю, что MC показывает не количество свободного места, а то, сколько места было свободно минус то, что вы удалили. Поэтому вывод df -h может быть показывает то же самое.
В том числе вы могли удалить файлы, которые в данный момент используются системой. Если удалить большой лог файл, который использует Apache реально место освободится только тогда, когда вы перезагрузите Apache.
Возможно картинки чем-либо использовались или по какой-то причине залипли хенлдеры.
Также можно попробовать сделать tune2fs -m 4 /dev/sda1 но не уверен, что это сработает на рабочем разделе.
Попробуйте перемонтировать систему mount -o remount,rw /
Также можете удалить какие-либо лог-файлы из /var/log с последующей перезагрузкой соотвествующего сервиса.

Потому что читаем секцию "Establishing connection" документации пакета.
В вашем случае соединение будет установлено не в момент вызова createConnection, а в момент выполнения первого запроса, следовательно 370мс это не "чистое" время запроса.
В документации есть пример с принудительным коннектом.

add_header Strict-Transport-Security 'max-age=604800';

А чего вы ожидали? )
Как только браузер зайдет на этот хост по https, он больше не будет обращаться на него по http из-за полученного заголовка Strict-Transport-Security (переводится как "всегда используй HTTPS для связи с этим сайтом").
Как его сбросить в браузере, кстати, хрен знает - чистка кеша не помогает.

1) все те же. Разделение приложения на два отдельных (можно сделать через одну точку входа и использовать мидлвар URL-map что бы разруливать разные приложения по урлам. Можно разделить на бандлы - FrontendBundle/BackendBundle. Этот вариант чуть менее гибок, так же как и в случае с модулями в Yii. Хотя жить можно. Лично я пробовал вариант с полным разделением лишь один раз, ибо логика бэкэнда и фронтэнда и настройки приложений слишком уж различались. Да и изначально разработчики Symfony планировали что люди будут так делать, но подход с бандлами стал популярнее.

Разве что могу сказать, что выносить общие настройки приложений, общие части и т.д. с Symfony чуть проще.

2) Бандлы должны быть самодостаточны. По сути это модули. Если вы не планируете реюзать код в других проектах, то смысла выносить этот код в отдельный бандл нету. В 99% случаев смысла разности бизнес-логику приложения по разным бандлам нет.

Обычно делают какой-то CoreBundle/SiteBundle/AppBundle или что-то в этом духе и там делают всю логику проекта. Если появляется какой-то функционал, который можно реюзать (например слой абстракции для работы с платежными системами, система уведомлений или чего еще), это дело можно вынести в отдельный бандл и в последствии реюзать.

Так же довольно распространенная практика хранить код просто в неймспейсе проекта, а в бандлах хранить только вещи специфичные для Symfony (регистрация сервисов, настройки валидаторов, мэппинг базы и т.д., то есть все то что нужно именно Symfony). Подобная структура проекта частенько мелькает когда рассказывают о DDD, да и на самом деле таким образом проще держать проект в чистоте. Если у вас еще и контроллеры как сервисы определены, то вообще красиво выходит. Но это все для ослабления связи кода вашего проекта и фреймворка.

3) Это неймспейс. Обычно вместо Acme пишут либо название проекта либо имя фирмы исполнителя/никнейм фрилансера...

Большинство людей смущает необходимость хранить код на один уровень ниже. Скажем у вас только один неймспейс, код весь в нем, какой смысл в папке src хранить одну единственную папку? Вот и придумали стандарт PSR-4, который позвляет указать префикс. Например что бы избавиться от папки Acme, все его содержимое можно перетащить на уровень выше (прямо в src), и в composer.json прописать

"autoload": {
    "psr-4": {"Acme\\": "src/"}
}

Это все чисто вопрос нэймспейсов и настройки автозагрузки.

Если для себя, можете посмотреть в сторону CygWin

Тут еще такой вопрос что у Вас считается показателем отказов. В GA, например, по умолчанию, это если посетитель посмотрел не более 1 страницы (то есть кто-то мог час висеть на этой странице, читать что-то, потом уйти - в GA это отказ). В Метрике это 15 секунд, если не ошибаюсь. Можно и свой настроить.
23% не плачевный показатель отказов, а вполне нормальный. Но Вы еще посмотрите показатель отказов не по контексту, а общий по сайту, если он не выбивается из общего - значит все ок.