Сергей Протько

Почитайте чего на тему разделения ответственности

Так же если вы считаете что "страничка медленно загружается" - надо профилировать.

1. На уровне браузера - просто в дебагере посмотрите что именно медленно грузится. Возможно медленно скачиваются сами картинки.
2. На уровне страницы - возможно сервер далеко расположен. А может страничка медленно генерится.
3. На уровне PHP - есть отдельные профайлеры, начать можно тупо с логирования времени выполнения отдельных кусков кода. Заканчиваем специализированными инструментами вроде blackfire.io.

yuml.me можно пробовать тамошним DSL-ем строить модель данных в UML.

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

скажите, это у вас в требованиях где-то есть или вы сами решили учитывать комплектующие из которых состоит системный блок?

комплектующие словом можно так же добавить как продукты в каталог. И просто делать many-to-many связь между комплектующими и системным блоком.

https://wiki.postgresql.org/wiki/Microsoft_SQL_Ser...

Опыт был перевода с Oracle на psql но там все было относительно просто.

Насколько я могу судить "первопроходцами" решения проблема мэппинга данных из базы на объекты... стали те у кого эта проблема возникла впервые. А именно у чуваков из Oracle, которые предложили одну из первых ORM - TOPLink. Сначала для Smalltalk в начале 90-х и потом для Java.

Использую MVC

Ну ок, и причем тут это?

координаты в токене

используете JWT?

если не совпали, то перезаписывать координаты в токене..

А смысл тогда вообще связывать координаты и токен? Не проще ли обновлять периодически координаты для сессии?

Словом если у вас это нужно для геотрекинга - то просто отделите токен от геолокации пользователя и используйте отдельный метод api для апдейта оных.

UPDATE blabla SET column4 = column1 - column2 WHERE column3...

1) я бы помимо ID хранил еще порядковый номер, который бы четко задавал последовательность изображений. В таком случае мы можем хранить рэйнджи не просмотренных изображений. Ну и так как у нас может быть произведен переход только к соседнему изображению - это легко устроить.

2) без разницы. Лучше по дефолту брать sql и nosql для кеширования и агрегации данных в случае необходимости.

трудно юзать orm (както попроще sql сделать)

вы сами ответили на свой вопрос, только выделите это в какой-то отдельный DAO что бы снизить связанность и повысить поддерживаемость.

Право существовать имеет но.... а смысл?

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

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

сгенерить.

https://github.com/Codearte/jfairy

Да, это более чем нормальный сценарий. Скажем хранить все в postgresql и делать агрегации данных для ускорение выборок в какой нибудь elasticsearch или монгу.

А если вы еще и CQRS будете практиковать, то вообще ништяк. Тогда команды у нас будут работать только с postgresql и инициировать обновление агрегаций а запросы - с эластикой.

так... давайте разберемся. У пользователей тоже могут быть теги? Или теги только у задач?

А так два варианта:
- нормализовать все, теги в отдельной таблице, связать через связи. Гибко и чуть сложнее.
- хранить теги в массиве у тасков, postgresql же. Это просто, быстро и сложности будут только для оргенизации автокомплита и выборки списка существующих тегов. При таком раскладе первый вариант эффктивнее.

Храним данные в MySQL (а лучше PostgreSQL, ибо на этом можно было бы и закончить), делаем агрегацию данных в mongodb/couchdb, для выборок юзаем монгу, для записи - mysql + опять же запускаем агрегацию данных.

Монга начинает грустить когда вы пытаетесь делать там джойны. А если вы захотите сделать монгу основным хранилищем то вам захочется сделать и джойны... такие дела. Как кеширующий слой - найс. Как основная база - надо сильно хорошо подумать а стоит ли.

Зависит от ORM. Оверхэд по производительности конечно будет, особенно если брать штукти типа Doctrine с гидрациями и т.д. Но тот профит в плане времени разработки и качества продукта которые они дают слихвой окупают все издержки. Если проект становится популярным и +30% это лишняя стойка серверов, то есть платить за сервера уже становится дороже чем за разработчика, тут уже имеет смысл рефакторить и оптимизировать узкие места. Но преждевременные оптимизации - зло.

Что до SQL и возможностей СУБД - Doctrine и многие другие позволяют вам использовать как нативные запросы (+ свои гидрации) так и добавлять какие-то свои функции для *QL. Так же многие вещи можно порядочно ускорить (в доктрине самым узким местом является unit-of-work а точнее вычисление дифа данных которые там крутятся. По умолчанию там все сравнивается в лоб, типа дерти чекинг, но можно установить свою реализацию для своих сущностей если вы этого захотите).

Doctrine ORM имеет мощный встроенный билдер запросов с привязкой к объектам. Генерация схемы и миграций по метаданным, короче... удобнее штуки я не встречал и врят-ли на данный момент что-то удобнее есть (на втором месте пожалуй Propel).

sql parameters binding

и в вашем случае думаю стоит посмотреть в сторону ORM какого...