просто скажи

в чем профит твоего подхода

мне нравится смотреть 100% покрытие в маленьких бандлах

эм...

а 100% покрытие в маленьких папках?)

гитлаб так не показывает

он только общую цифру выдает

а гитлаб умеет показывать покрытие?

ну и у меня задел на то, что если что-то еще понадобится, то я соберу это из существующих кусков

вот скажу тебе... я помню тот восторг который у меня был когда я 5 лет назад впервые попробовал FosUserBundle

это ж как охеренно подумал я

ой фу)

сделал один раз бандл и реюзаешь его

через неделю работы с FosUser мы поняли что это неподдерживаемое говно

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

через месяц мы поняли что наш тоже говно и подумали "наверное мы криво написали"

хватило нас на 2 года

сейчас мы на своих проектах не юзае никаких бандлов которые тянут в себе сущности

у меня бандлы не такие

мои бандлы строго под ключ

разделил я их только для себя

но у тебя тот же User из UserBundle юзается где-то еще?

кроме эстетического удовольствия профита нет)

например в NewsBundle запомнить автора

в рамках компании только

например в NewsBundle запомнить автора

такого нет

я к тому что бандлы между собой зависимостей не должны иметь. А у тебя прямая зависимость от UserBunde

не люблю ORM

окей

DAO юзаешь?

на другом проекте

....

мы обсуждаем конкретный проект

1

ну в этом нет

где у тебя 16 репозиториев

и даже пофигу есть там база данных или нет, юзаешь ты ORM или DAO

вопрос простой

у тебя другие части проекта хоть что-то знают помимо userId о юзере?

нет

пишу sql под ключ

под конкреную нужду

процедуры что-ли?

не не не

всякие типа getTitleAndSomeParameter

тогда у тебя таблица, которая принадлежит юзерам, делится с другими

я про связанность данных говорю

денормализацию делаешь или нет?

неа

не делаю

ну тогда в этом разделении никакого смысла

у тебя на уровне базы данных связанность

а потому разделять код тоже смысла нет

а вот если бы ты сказал "делаю" я бы сказал "а ну тогда все логично"

так мне не нужна денормализация

в проекте все атомарно +-

и разделение тебе тоже не нужно)

и причем тут атомарно?

мы вопрос связанности обсуждаем

не знаю как это описать

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

да я уже понял что все твое разделение ради удобст с код коверадж

> они провязаны между собой только общим ID

апи занимается тем, что на полученный id тянет из разных мест данные и склеивает в один ответ

так

у тебя есть хоть одна выборка

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

ERROR: S client not available

например.... тебе надо список чего-то и имена юзеров которые привязаны к этому добру

SELECT u.name, p.name FROM products p INNER JOIN users u ON u.id=p.user_id;

что-то типа такого

нету такого

совсем совсем?

совсем совсем)

а юзера зачем?

только в рамках части системы

только в рамках части системы

так

так это значит "есть")

есть песенка интересная на эту тему

https://www.youtube.com/watch?v=pSOBeD1GC_Y

This all is true from a certain point of view

так это значит "есть")

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

снаружи uuid, а внутри просто на int завязано

потому что uuid тяжелый

то есть есть два компонента, и есть выборка которая одновременно использует данные и оттуда и оттуда?

нет такой выборки)

как все сложно

окей

почему тогда ты базу данных не разделишь?

ибо если так - это должно быть легко

просто берешь и режешь базу

и ничего не надо менять

потому что у нас 2 больших железных сервера

под бд

ну а будет 6 дешевых)

раньше все было на DO

под 10$k тратили

суммарно на все

сократили до ~2.5k перейдя на голое железо

так-то да