молодой человек, почитайте Фаулера, дядюшку Боба прежде чем рассуждать об архитектуре. начать можно с книги «Архитектура корпоративных программных приложений» — вполне доступно для начинающих.
вначале нужно построить хорошую архитектуру, которая позволит легко изменять код без больших последствий для функциональности системы (топикстартер сам пишет о том, что была проблема с добавлением новых фич — обычно причина именно в неудачной архитектуре. то же самое будет через несколько лет с этой). затем, если есть такая необходимость, оптимизировать, там, где это действительно нужно. подход «сразу запихать всю бизнес-логику в sql» можно считать случаем преждевременной оптимизации, он не позволит использовать TDD и тестировать код — что скажется на читабельности, возможности повторного использования, поддерживаемости кода.
для оптимизации и масштабируемости давно уже есть свои наработанные методики — кэширование, шардинг, репликация, микросервисы, load balancer, что там ещё? не нужно для этого уродовать архитектуру системы.
отвечая на ваш вопрос, «какой большой проект вы знаете??». Symfony по умолчанию использует Doctrine. Symfony используют, например:
Spotify
Blablacar
Vogue France
Porn hub — «1 billion of traffic per week. Symfony is used to support more than 700 million requests for the same time.»
Trivago — «More than 120 million visitors»
Dailymotion
National Geographic
Про «ваш интернет магазин??» вы верно заметили. к нашему проекту в области е-коммерции подключено 10 000 мерчантов, в числе мерчантов и партнёров MediaMarkt, Tesla, Ford, Microsoft. на проекте использовалась Doctrine, теперь TypeORM (перешли с php на nodejs — работает быстрее, при разработке языка учли многие детские болезни php). так вот, в прошлую чёрную пятницу сайты многих крупных мерчантов просто лежали. наш даже не шелохнулся. для этого потребовалось сделать только то, что я написал выше — мы просто задеплоили несколько новых контейнеров.
хотя, если очень хочется всё оптимизировать с начала проекта — ну пишите сразу на ассемблере, чё.
кстати, судя по доступной информации, у авторов поста всего-то 10 000 посетителей в день, ну в апреле количество выросло примерно до 60 000 — это что, хайлоад? Alexa, SimilarWeb, etc подтверждают эти цифры. если у них в БД 23 млн пользователей, из них 10 000 активных, и они со своей базы пользователей даже не могут оплатить хостинг, то проблема, скорее, в монетизации. $1000 в год — да блин, посчитайте же зарплату ОДНОГО программиста за год и сравните. может, станет понятно, что пора бы начать зарабатывать, а не пытаться экономить на спичках.
автор, проработавший с базами более 30 лет, несомненно обеспечил себе беззаботную старость в компании.
но нормальная архитектура большого и долгосрочного проекта должна зависеть от абстракций, а не от деталей, поэтому решения о выборе СУБД принимают в последнюю очередь. для этого и существуют ORM — чтобы не зависеть от СУБД. хранимки, в том количестве, в котором вы их используете — это вынос бизнес логики в БД и мёртвая привязка к деталям.
при нынешней стоимости аренды серверов, для бизнеса было бы лучше сделать всё так, чтобы при повышении нагрузки просто задеплоить ещё один контейнер, вместо того, чтобы находить/обучать людей, готовых писать бизнес-логику прямо в SQL.
поищите на хабре «itinvest форекс», там подробно всё расписано. торгуя суммой $100, у вас и плечо будет соответствующее, и результат вполне закономерный. возможностей заработать на фондовом рынке в сотни раз больше.
Оптимисты им возражают: если бы рынок был случаен, котировки не гуляли бы в окрестности 1, а ушли в бесконечность. Значит рынок неслучаен и на нём можно зарабатывать.
бросаем кубик. выпадает число от одного до шести. по аналогии с рынком, если бы величина была случайная — она не гуляла бы в этих окрестностях, а ушла в бесконечность, получается так?
хотя можно сказать, что рынок и идёт в бесконечность, вместе с инфляцией и НТР, только о-о-очень медленно, но S&P и ММБВ недавно на исторические хаи вышли.
на мой обывательский взгляд, будущее случайно, если будущие события не предопределены прошлыми, а прошлое лишь может влиять на шансы (вероятности) их появления. на случайных процессах можно зарабатывать — например, игра в блэк-джек остаётся случайным процессом, тем не менее, считая карты, можно повышать вероятность выигрыша.
на рынке (хоть он и случаен) тоже можно зарабатывать — например, правильно прогнозируя действия крупных игроков. это дивидендный трейдинг, сделки m&a, скальпинг. и находя ситуации, в которых вероятность получения прибыли значительно превышает вероятность получения убытка.
вначале нужно построить хорошую архитектуру, которая позволит легко изменять код без больших последствий для функциональности системы (топикстартер сам пишет о том, что была проблема с добавлением новых фич — обычно причина именно в неудачной архитектуре. то же самое будет через несколько лет с этой). затем, если есть такая необходимость, оптимизировать, там, где это действительно нужно. подход «сразу запихать всю бизнес-логику в sql» можно считать случаем преждевременной оптимизации, он не позволит использовать TDD и тестировать код — что скажется на читабельности, возможности повторного использования, поддерживаемости кода.
для оптимизации и масштабируемости давно уже есть свои наработанные методики — кэширование, шардинг, репликация, микросервисы, load balancer, что там ещё? не нужно для этого уродовать архитектуру системы.
отвечая на ваш вопрос, «какой большой проект вы знаете??». Symfony по умолчанию использует Doctrine. Symfony используют, например:
Spotify
Blablacar
Vogue France
Porn hub — «1 billion of traffic per week. Symfony is used to support more than 700 million requests for the same time.»
Trivago — «More than 120 million visitors»
Dailymotion
National Geographic
Про «ваш интернет магазин??» вы верно заметили. к нашему проекту в области е-коммерции подключено 10 000 мерчантов, в числе мерчантов и партнёров MediaMarkt, Tesla, Ford, Microsoft. на проекте использовалась Doctrine, теперь TypeORM (перешли с php на nodejs — работает быстрее, при разработке языка учли многие детские болезни php). так вот, в прошлую чёрную пятницу сайты многих крупных мерчантов просто лежали. наш даже не шелохнулся. для этого потребовалось сделать только то, что я написал выше — мы просто задеплоили несколько новых контейнеров.
хотя, если очень хочется всё оптимизировать с начала проекта — ну пишите сразу на ассемблере, чё.
кстати, судя по доступной информации, у авторов поста всего-то 10 000 посетителей в день, ну в апреле количество выросло примерно до 60 000 — это что, хайлоад? Alexa, SimilarWeb, etc подтверждают эти цифры. если у них в БД 23 млн пользователей, из них 10 000 активных, и они со своей базы пользователей даже не могут оплатить хостинг, то проблема, скорее, в монетизации. $1000 в год — да блин, посчитайте же зарплату ОДНОГО программиста за год и сравните. может, станет понятно, что пора бы начать зарабатывать, а не пытаться экономить на спичках.
но нормальная архитектура большого и долгосрочного проекта должна зависеть от абстракций, а не от деталей, поэтому решения о выборе СУБД принимают в последнюю очередь. для этого и существуют ORM — чтобы не зависеть от СУБД. хранимки, в том количестве, в котором вы их используете — это вынос бизнес логики в БД и мёртвая привязка к деталям.
при нынешней стоимости аренды серверов, для бизнеса было бы лучше сделать всё так, чтобы при повышении нагрузки просто задеплоить ещё один контейнер, вместо того, чтобы находить/обучать людей, готовых писать бизнес-логику прямо в SQL.
бросаем кубик. выпадает число от одного до шести. по аналогии с рынком, если бы величина была случайная — она не гуляла бы в этих окрестностях, а ушла в бесконечность, получается так?
хотя можно сказать, что рынок и идёт в бесконечность, вместе с инфляцией и НТР, только о-о-очень медленно, но S&P и ММБВ недавно на исторические хаи вышли.
на мой обывательский взгляд, будущее случайно, если будущие события не предопределены прошлыми, а прошлое лишь может влиять на шансы (вероятности) их появления. на случайных процессах можно зарабатывать — например, игра в блэк-джек остаётся случайным процессом, тем не менее, считая карты, можно повышать вероятность выигрыша.
на рынке (хоть он и случаен) тоже можно зарабатывать — например, правильно прогнозируя действия крупных игроков. это дивидендный трейдинг, сделки m&a, скальпинг. и находя ситуации, в которых вероятность получения прибыли значительно превышает вероятность получения убытка.