index0h

LIKE - дико медленная операция, ее стоит использовать в исключительно редких случаях и то, для маленьких таблиц.

Ваш вариант MANY_TO_MANY ниже - на порядки лучше.

Вам посоветовали херню))

Вопрос производительности при таких условиях решается с помощью кэширования. На подготовленых запросах вы ничего не сэкономите. Это примерно как прикладывать подорожник на открытый перелом ноги.

'ниважна,

join

Можно запихнуть все это дело в транзакцию, так индексы пересчитаются 1 раз.

Правда я бы рекомендовал пакетную вставку в цыкле. В смысле набить запрос на N вставок одним insert, выполнить, далее еще раз наполнить и выполнить и т.д.

А если у каждого пользователя свои посты? Все посты пихать в одну коллекцию или в один массив?

Почему же? Посты в одной коллекции - это вполне ок. Юзвери в другой коллекции это тоже ок.

Если нужно реализовать что-то более менее нормальное, приходится писать костыль на костыле.

Не пишите костыль на костыле, сначала спроектируйте БД так, что бы избежать этого.

Вставлять документ в коллекцию можно только в конец.

И в чем проблема (я вам по секрету: так происходит практически в каждой СУБД)? Какая вам разница, где оно будет вставляться? Делайте выборку с сортировкой.

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

RTFM

написать костыль со skip, limit.

Какой нехороший человек вам такую дичь сказал? Если у вас записей 10кк, у вас просто оперативки не хватит делать подобные выборки без skip/limit.

Если бы можно было всё вставлять в начало коллекции, было бы намного проще.

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

Подскажите, пожалуйста, кто знает лучшую альтернативу.

Еще раз, вы придумали проблему и пытаетесь ее героически решить, но проблема заключается в том, что вы не правильно используете средства предлагаемые mongo, и другая БД вам ни как не поможет

Почитайте сначала про реляционные СУБД, как они устроены.
Конкретно под ваш случай:

CREATE TABLE IF NOT EXISTS `formulaResult` (
  `formulaId` INT UNSIGNED NOT NULL AUTO_INCREMENT,
  `result`    TINYINT      NOT NULL,
  PRIMARY KEY (`formulaId`)
)
  ENGINE = InnoDB;

https://ru.wikipedia.org/wiki/E.164

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

Вы пытаетесь отстрелить себе яйца, причем разрывными патронами((

1. explode - для работы с "прогнозируемыми" строками вполне норм, у вас же файлы, могут быть вообще бинарные, например картинки. В случае попадания на delimiter посреди файла - получите кучу мусора. "explode" в смысле "взрыв" - это очень подходящее слово.

2. В БД хранить файлы - не хорошо, вы будете ушатывать БД просто так. Самое интересное - как вы бэкапы планируете делать)) Объемы будут расти очень быстро.

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

4. Отдача файлов, вот тут тоже веселье: допустим получив мега строку вы разделите ее на куски и вытащите таки свой заветный файл, потом будете отдавать его через echo, это будет на порядок дольше, чем через web сервер на прямую.

5. Память на php: что будет, если ваша мега строка занимает 500мб? PHP с настройками по умолчанию сдохнет, даже не дочитав его.

В общем: для хранения файлов используйте БД специально спроектированную для хранения файлов. Это файловая система. Если очень хочется шардирования для снижения нагрузки - можете посмотреть в сторону решений на базе mogilefs.
В MySQL при этом стоит хранить только нужную дополнительную информацию о файле, например: путь, md5, некий идентификатор,...
Сам файл лучше при сохранении приводить к такому виду:
1. Берем md5 хэш от файла md5_file, допустим он у нас получился 01230000000000000000000000000000
2. Перемещаем его в каталог: {UPLOAD_ROOT}/01/23/0000000000000000000000000000. Тут смысл в том, что при большом количестве файлов в одном каталоге будут проблемы с файловой системой по части производительности. В принципе можно оставить оригинальное расширение, тогда шаг 4 не нужен.
3. В БД храним md5 хэш, путь к файлу и MIME-тип, можно еще и оригинальное имя.
4. При запросе на вашу страницу - отдаем через x-accel-redirect, или x-sendfile

IS NOT

Под чаты php - не лучший выбор, смотрите в сторону nodejs.
Конкретно историю пишите в redis, а далее отдельным вызовом - в БД (если бизнес задачи этого требуют).
Ушатывать БД только потому, что можете - это плохая идея.

Если не заморачиваться на безопасности

У вас нет такого права, примите за исходную. Пользователь всегда врет, это закон.

Какую СУБД посоветуете(чтобы было проще с портированием и масштабированием данных) ?

БД для портирования... хм... а зачем?
На счет масштабирования - тут все завист от структуры ваших данных. Для данных в виде документов посмотрите в сторону mongodb, она из коробки умеет в шардирование. Для табличных - mysql/postgresql, тут масштабирование выбирается по тому, как используются данные: если в основном на чтение и редко на запись схема master-slave в помощь, иногда отдельные БД выносятся на отдельное железо.
В случае

Записей в таблицах может быть от сотен до сотен тысяч

я очень сомневаюсь, что вам потребуется заморачиваться с масштабированием.

Вы кстати не обратили внимание на очень важные метрики:
- отказоустойчивость
- сложность восстановления после сбоев

Каким фреймворком посоветуете заинтересоваться?

Зависит от задач, но как фреймворк общего направления рекомендую Symfony.

есть ли какое либо другое решение простое в использовании но не менее эффективное и производительное?

для базы данных с веб интерфейсом

Вы задачу не озвучили, какое может быть решение?)) БД с web интерфейсом - это практически любой не статический сайт, только помимо этого там еще и бизнес логика присутствует.

owncloud

Со временем любая технология устареет, это факт. Но PHP с MySQL сейчас бодры и полны сил, выйдет PHP7 - первый будет еще и с допингом)).

в скором времени вообще будут "удалены"

Откуда удалены, если не секрет?

Читайте на тему: Строковые функции MySQL