вот кто реально пидар так это сайты с документацией которые удаляют страницы и не оставляют редиректы

есть такое

Есть такое

@ilmirus можно в лс переслать голосовое на анализ японского языка?

Странная ошибка. Не реально впервые слышу о таком. Впрочем я мало пользуюсь проводником на виндовых виртуалках (разве что в окнах открытия\сохранкния системных). А вообще ZFS рулит. Снапшотик снял и готово.

Есть спецы по БД?
Как правильнее всего организовывать доп. информацию для объекта в таблице?

Есть вот объект boobs.
В таблице нужна разнообразная доп. информация для каждого объекта.
Например: datetime создания объекта, всякие доп. флажки (избранное, архивировано).

Как это правильнее всего организовывать в SQL/NoSQL?

Вижу два пути:

1) Заводить эти поля прямо в таблице сущностей. Но тогда, теоретически, таблица может разрастись вширь очень сильно.

2) Доп. таблица, где будет соотношение boobs_id ко всякой инфе. Здесь выходит, что для получения инфы придётся делать лишние запросы, что тоже не хорошо.

доп информация может создаваться on-fly?

Да. И обновляться, и добавляться.

раньше в реляционных бд делали EAV-model  (entity-attribute-value)

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

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

Спасибо

А гугл тебе на что?

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

Ладно, животрепещущий вопрос - почему Скатах, а не лучшая девочка фейта?

А какая субд?

Пока всё делается на firebase firestore.
У них там NoSQL на коллекциях документов.

Но не исключено, что чуть позже буду перевозить на свой хост с SQLite/PostgreSQL.

В PG лучше все упихнуть в jsonb, так обычно удобнее работать. У меня был доклад про использование json в реляционных базах, можешь поискать.
В firebase все еще очевиднее

>В firebase все еще очевиднее

Честно, пока не особо очевидно.
Вот и пытаюсь найти примеры.

А то уже сейчас, на раннем этапе разработки всплывают проблемы с этим.

А что за проблемы?

Банально вот менеджмент всей этой доп. инфы.

Вчера добавилось одно новое поле, сегодня ещё одно, завтра какое-то полностью изменится.

А по этим полям нужно и искать уметь, и хендлить их отсутствие, и, по хорошему, уметь мигрировать на новую версию этих полей.

А firestore половину из этого не умеет.
Банально — нельзя проверить существует ли поле у документа. Можно работать только если оно есть.