ты тут не умничай, а пальцем покажи (с)  IoCи тут всякие напридумывали.
Проблема третий сущностей в том, что их число растёт с комбинаторной сложностью.
Отделять интерфейсы и реализации, ради убрать циклические зависимости? Ну у нас не плюсы и не джава. Нахер страдать то.

Такой третьей сущностью, например, может быть фронтенд. Который знает что у юзеров есть коменты, в то время как юзеры на бекенде про это не знают и имеют предельно простой API.

В общем боль с циклическим зависимости, очень сильно преувеличина.
Да, надо стораться её избегать. Но если из правильного похода, получается страдания, то и пофиг на него

а я люблю форенкеи делать... и relationship использовать. И другую сиквульную магию. А писать много кода не люблю

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

А вот если есть API которое работает с модельками, а модельке требуется импорт апи — то вот это уже зло

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

Ну это же не правда.

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

В одном модуле тоже не получится.
Сначала ты определяешься class User и в нем ссылаешься на Comment, а Comment ты ссылаешься на User. В одном модуле ты не определишь. А вот через циклически импорты — можешь 😊

А то что база не ложиться на код.. Это да. Именно из этой идее вылезли объектные NoSQL в часности монга

Вообще SQL задумывалась в основном для расширенного поиска, а не для хранения. Просто сравните описание методов SELECT / JOIN / HEAVING и INSERT / UPDATE. Разница в десятки и может в сотни раз.

А нам пограмистам и говнокодерам, очень хочется работать с базой как мы это делаем в коде. ORM помогает в этом, но потом ты сидишь и разгребаешь все 100500 запросов и пытаешься переделать код чтобы был один запрос..

Не, прямо в теле класса.

class Foo:
    from app import db
    def method(self):
        self.db.commit()

В наследнике можно db замокать.

Хм, я даже на уровне базы данных не очень понимаю для чего нужно что бы таблица с юзерами "знала" про коменты, а таблица коментов "знала" про юзеров. По моему такое даже нельзя будет сделать, например в Постгресе.
Такое "знание" может возникнуть только на уровне бизнес-логики, но не на урове моделей.

Почему? Юзер --> oneToMany --> Comment. Комментарий оставляет пользоавтель, вот тебе и связь

Антон написал про связь, когда юзеры знают про коменты, и коменты знают про юзеры. В SQL базах такое потребует (для консистентности) создавать в обеих таблицах фориджены на "противоположную" таблицу.
Я что-то не представляю как такое можно сделать с помощью двух последовательных CREATE TABLE

oneToMany - это как раз однонаправленая связь

И в ней таблица юзеров ничего не знает про таблицу с коментами

дык через третью таблицу. в которой столбцы: id, user_id, comment_id

Через третью таблицу это мэни ту мэни.  Оне ту мэни можно и без третьей таблицы. В базах можно ещё одну таблицу самому в себя зациклить