Антон Середний

Её можно применить там где не нужны транзакции, либо простые "транзакции" (микросервисы, веб).

Табличные БД не оптимальны, их приходится использовать т.к. новые инстументы не достаточно развиты, с другой стороны некоторые новые инстументы предлагают продвинутые подходы.

Высокопроизводительные распределенные интернет-приложения. Конкретные примеры: amazon.com, netflix.com, ebay.com. NoSQL движение возникло как ответ на проблемы масштабируемости. Реляционные базы ориентируются на требования ACID и как следствие имеют проблемы с горизонтальным масштабированием. Для таких баз необходимо реализовывать шардинг на уровне приложения. Но тогда будет необходимо отказаться от ACID, объединения таблиц и контроля целостности. В таком случае реляционная база теряет все козыри перед NoSQL. Но оставляет на плечах разработчика заботу о шардинге.

Интернет забит вопросами о том как жить без транзакций в NoSQL. Но бизнес-процессы в реальной жизни не являются транзакционными. Вы не можете человека, который покушал в вашем ресторане, а теперь отказывается платить по счетам заставить сделать роллбек вашей еды. Фактически посетитель вам бросил эксепшен. И даже если вам удастся извлечь еду из вашего посетителя, то маловероятно, что она будет готова к последующему употреблению. Но можно взыскать с него все затраты через суд и придти таким образом в согласованное состояние. Любому бизнесмену это очевидно. Но программисту нет. Он хочет транзакционно. Но пишет систему для автоматизации бизнес-процессов. Парадокс.

Была у меня задача где монга с шардингом подошла идеально - сбор и архивирование логов действий пользователей. Были десятки миллионов действий в день. Тут понадобилась и гибкая структура и легкий шардинг на запись. Шардили коллекции по дате записи. TTL не использовали.

Я расскажу Вам про личный опыт, без претензий на истину в последней инстанции...

Для чего идеальна MongoDb? Примеры приложений, где монга будет лучше mysql?

Для человека который привык работать с реляционными БД, смириться с логикой и вообще с подобными БД - довольно сложно. Для тех, кто работает с реляционными БД профессионально - сделать это ещё сложнее...

Если сравнивать с реляционными БД и с оглядкой на конкретно MySQL - монга идеально вписывается там, где структура данных заранее неизвестна. Тут я хотел привести пример, но не смог придумать ни одного дельного примера, после того как начал плотно работать с PostgreSQL... Давайте попробую из практики. Мы один раз применяли монгу в проекте где есть десятки и сотни тысяч товарных позиций и у каждой из них свой уникальный набор различных свойств. На основе уже имеющихся свойств, "соседних" товаров, контентщику предлагался наиболее вероятный набор параметров, которые нужно заполнить, но в любой момент он мог удалить или добавить любое поле и/или множество значений одного из них, например, "Цвет: черный, серый, фиолетовый". Всё это дело попадало под разные динамические фильтры и далее по цепочке... В то время, насколько я помню ещё не было поддержки JSONB-формата у PostgreSQL, по этому мы остановились на MongoDB. Ну и конечно же, желание "воткнуть ультра новую и модную БД в проект" сыграло свою роль...

Что в монге определённо не нравится (и это не моя "идея", об этом пишут даже в учебниках под монге) - это тотальная денормализация данных. Которая в некоторых случаях может сыграть злую шутку. Например, все комментарии "поста" обычно хранятся прямо в самой сущности поста. Это очень удобно и довольно быстро работает, но... иногда это приводит к полному коллапсу. Особенно, когда у Вас перекрестная ссылочность.

Безусловно, не редко можно встретить проекты в которых даже в реляционных БД не прописаны, например, внешние ключи и контроля целостности данных как такового нет, но обычно это происходит по следующим причинам:
1. Очень низкая квалификация администратора БД проекта
2. В попытке выжать из базы больше производительности, не найдя других методов оптимизации
3. Данных настолько много, что БД/ключи - начинают "сыпаться", не редко это связано с п.1

Так же, последние тесты показывают, что PostgreSQL почти не уступает MongoDB даже в её родной среде (на уровне данных в формате JSON). А в некоторых аспектах даже превосходит её... Подробности Вы можете увидеть на некоторых конференциях по Postgres (да, на конференциях по MongoDB, Вы вряд ли увидите, как кто-то будет рассказывать, что [их любимая] монга "хуже" некоторых других движков...). Кстати, поддержку формата JSON стандартизировали (наконец-то) на уровне SQL-стандарта (если я не ошибаюсь) и в самом ближайшем будущем, думаю стоит ожидать полноценную поддержку оного в SQL-базах, в т.ч. поддержку в бинарном виде с возможностью индексации данных (кстати, некоторые SQL-базы уже такое умеют).

Моё понимание, ответа на вопрос, "когда действительно стоит использовать MogoDB?" звучит примерно так: Исключительно в тех случаях, когда Вы понимаете, что она станет действительно хорошим решением для поставленной задачи и сейчас и в будущем. В моей практике, таких проектов можно было бы насчитать ничтожно мало, а точнее около нуля, особенно с учётом развития некоторых современных SQL-БД и вообще направления "JSON в SQL" в целом. Но, безусловно такие проекты могут быть и есть (в данном случае, не у меня). Но, тут стоит обратить внимание на крайне важный факт - когда всплывает такой проект, что бы адекватно оценить наиболее оптимальную БД под него - нужно знать как минимум пару-тройку SQL-БД, со всеми их особенностями, достоинствами и недостатками... причем не просто "знать", а хорошо знать, "изнутри". А так же знать все характерные черты монги, а так же её особенности, достоинства и т.д. То есть, если Вы задаётесь вопросом, "а хорошо ли впишется монга в проект N?" и не можете найти на него однозначного ответа, вероятнее всего, что в долгосрочной перспективе, в "проект N" она впишется плохо.

P.S. В заключение, хочу ещё раз напомнить, что "JSON в SQL" - активно развивается... Со всеми вытекающими.

{11,30}

$teacherID = чему-то там равен, неважно...

$itemsByTeacherID = [];
foreach ($days as $day) {
  foreach ($day['day_items'] as $item) {
    if ($item['teacher'] === $teacherID) {
      $itemsByTeacherID[$day['day']][] = $item;
    }
  }
}

<video></video>

RewriteRule ^about\.asp(.*)?$ company.asp [R=301,L]

Имеется getter:

public function getName() {
    return $this->name;
  }

Я бы сделал $name => protected, вместо public.

радио, прежде всего слушать радиопрограммы или аудио подкасты, пока тошнить не начнет
словарь - только английский толковый, никаких переводов на русский

начинайте с простого материала, хоть даже с детских передач и мультиков, чтобы набрать минимальный разговорный, а потом только аудио, видео перебивает слишком большим количеством визуальной информации, и ушам не нужно напрягаться, чтобы понять на слух

аудирование - самый сложный навык, поэтому ему учатся с рождения, потом учатся говорить, а уже только потом читать и писать

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

следующий шаг - заучивание готовых фраз и выражений вслух и наизусть: это нужно для приучения вашего артикуляционного аппарата автоматически произносить то, что нужно и как нужно, точно так же как это происходит на родном языке, тут только многократные тренировки и повторения, как в музыке и спорте, чем больше вы заучите таким образом, тем легче вам будет в разговоре

осилите преподавателя-носителя языка хоть по скайпу - это будет идеально, но это должен быть именно преподаватель, который умеет преподавать english as a second language - ESL

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

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

не слушайте никого, кто будет говорить, что вам сначала нужно выучить грамматику
сначала надо освоить разговорный английский, хоть на уровне 5-летнего ребенка, а потом вы сами сможете понимать, что и как вам учить

Если чисто по коду, сам гит у меня лежит в корневой папке WordPress. `.gitignore` файл выглядит примерно вот так:

# PHPStorm
.idea

# WordPress
*.log
/wp-*.php
/index.php
/xmlrpc.php
/license.txt
/readme.html
/sitemap.xml
/sitemap.xml.gz

/backup*

wp-admin/
wp-includes/

wp-content/*
!wp-content/themes/
wp-content/themes/*

!wp-content/plugins/
wp-content/plugins/*

!wp-content/themes/ei/
!wp-content/themes/ei-child/

!wp-content/plugins/realty-export

# Frontend tools
wp-content/themes/ei-child/node_modules/

т.е. Вы по умолчанию игнорируете все кроме того, что нужно. По мере разработке можете добавлять или убирать папки.

По бэкапам.
Бекап делаю через плагин BackUpWordPress (очень удобная вещь, можно делать бекапы всего сайта и базы по расписанию, Вам на почту приходит письмо с ссылкой на скачивание бекапа), экспорт базы на другой сервер делаю с помощью WP Migrate DB (он не просто заменяет пути в базе но и правит под них сериаллизованые массивы, таким образом некоторые настройки не слетают). Знаю что можно все делать через wp-cli, но он далеко не на каждом сервере стоит, и так уже привычнее. Мне обычно чтобы слить клиентский сайт для работы на локалке даже фтп не нужен, только доступ в админку.

При работе с сервером заливаю файлы прогой WinSCP, она может как FTP так и SFTP, так же умеет синхронизировать папки (заливать только то, что изменилось), на крупных проектах настраиваю синхронизацию в PHPStorm.