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

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

Вот и спроектируйте адекватную, нормализованную схему.
Создайте индексы для ожидаемых очень частых запросов, если нужно.
Далее это в 99.99% случаев будет просто работать.

есть таблица "Рецепт" и есть таблица "Ингредиенты", каждый рецепт может иметь > 1 ингредиента и получается связь многое ко многим, соотв. нужна промежуточная таблица RecipeIngredient. И получается ингриденты то только привязанные к рецептам, тоесть их держать в отдельной таблице нет необходимости

Есть вариант держать массив айди ингредиентов в рецепте и их кол-во

> и получается связь многое ко многим, соотв. нужна промежуточная таблица RecipeIngredient

Да.

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

Нет. Даже если у самих ингредиентов нет никаких свойств, кроме названия.

> Есть вариант держать массив айди ингредиентов в рецепте и их кол-во

Что не является реляционной моделью. Т.е. "сразу нет",
Просто же. ;)

т.е. необходимость иметь отдельную таблицу есть!)

Вспоминаю себя во время первого проектирования бд, так сложно понять, что реляционная модель это не объектно ориентированная модель 😄

и что все оптимизации объектно ориентированной к реляционной модели не подходят))

100000000 рецептов, ингредиентов приблизительно пусть будет на рецепт в среднем 10  => 100000000 * 10 = 1000000000 - и получаем две таблицы, которые надо сджоинить, а если бы мы хранили в массиве, нужно было бы лишь одну таблицу дёргать грубо говоря

вы очень плохо поняли реляционную модель 😄

у вас айди, вам не нужно О(n) для поиска айди, у вас грубо говоря O(1)

Да, получаете две, и это прекрасно (т.е. для подавляющего большинства типичных запросов это лучше, чем массив).

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

Хотя бы что-то такое почитайте пожалуйста 🙏 https://habr.com/ru/post/250177/

спасибо, я не с того начал

а как работать с Каунтерами, тоесть допустим я поставил лайк, тож не сразу в бд лезть и делать Апдейт, а как то через кэш?

а, и ещё, как хранить время? можно в миллисекундах или нужно в DateTime или в timestamp?

Тогда уж грубо O(log n).

Какая реализация реляции индексно по id обращается O(1) без поиска в индексе?
Цены бы не было такой реализации, тогда бы поик по графу, сложенному в одну таблицу не деградировал так сильно от многократных селф-джойнов и обьема данных, никакие nosql не давали бы профита.

это к базе данных отношения не имеет, и опять оптимизация на ровном месте, может уже перестанете оптимизировать? 😄