nepster09: я им не пользовался особо, только давным давно. Не вижу в нем смысла если есть эластика, которая чуть больше умеет и у нее намного больше сообщество. Попробуйте на сфинксе запилить кластеризацию серверную меток на карте. А потом погуглите готовое решение для эластики и вы найдете такое.
nepster09: последовательности вместо убогих автоинкрементов позволяют мне убрать тонны кастылей в коде (связанные с тем что я не знаю ID записи до вставки), нормальные транзакции, проще детектить факапы миграций (я все же в команде работаю) а так же возможность обернуть практически все в транзакцию и безопасно накатить. Ну и да, всякие репликации стриминг реплики для бэкапов и т..д. Все остальные плюсы вроде postgis и т.д. весьма спорны, так как можно подключить сверху какую-нибудь эластику, но иногда удобно.
Иван Антонов: я это прекрасно понимаю, потому и рекомендую для работы с базой и организации сущностей не пилить свой велосипед а воспользоваться доктриной, которая все это умеет.
В целом нет разницы, в контексте задачи это может быть излишним усложнением. Просто наследование надо применять осторожнее.
nepster09: нет транзакций нет проблем. Монгу чаще всего используют для агрегации данных из реляционной базы для ускорения выборок. Для логов скажем нынче удобнее юзать эластику... да и для агрегаций данных тоже. Если честно я даже не знаю зачем сейчас может понадобиться монга. Разве что только как документно-ориентированная база, хотя опять же есть CouchDB.
Использовать монгу как основную базу данных я считаю не особо хорошей идеей. Но у всего есть исключения конечно же.
Иван Антонов: для всех полей объект. То есть смысл в том, что бы объеденить поля, общие по назначению в объект. Скажем у нас есть дополнительная информация, и создаем мы объект AdditionalInformation или что-то в этом духе. Скажем мне нравится когда у пользователя его публичный профиль обернут в объект PublicProfile или UserProfile. Так обновление профиля у меня будет реализовано методом setProfile, а вся логика по валидации и прочее выносятся из сущности.
при определенных допущениях можно, я использую. Но у меня страница состоит из блоков и мне просто так удобнее хранить страницы. В целом же если у меня возникнет задача введения пользователей (у меня пока только один админ) то тогда я лучше все эти вещи буду хранить в реляционке и буду делать один запрос к структуре. Ну или буду хранить все в jsonb, всеравно postgresql если что буду использовать.
Иван Антонов: почитайте про объекты значения. В целом усложнять специально систему не стоит. Совершенный код всеравно не достижим, так что не стоит даже загоняться. Главное понимать что такое технический долг и понимать когда и сколько можно "отдолжить".
Владислав Танков: конечно это так, и так было всегда. Вы работаете со своим спектром задач, и вам это знать надо. PHP-нику это знать надо но в реальности от с этим может и не столкнуться за десяток лет. Знать как работают индексы в базе полезно конечно, но все же в PHP, который умирает (имеется в виду что демоны на пыхе штука все еще весьма редкая), у которого по дефолту у большинства лимит оперативки в 32-64 мегабайта на запрос (а это значит что у нас в принципе коллекции будут ограничены каким-нибудь десятком тысяч элементов), процент задач где вы будете думать над выбором, каким-то алгоритмом, который раскроет ваше знание структур данных, весьма и весьма мал.
Это просто специфика. И это я пока говорю о тех PHP-никах которые делают какие-то более-менее крутые штуки, с фреймворками и т.д. А их пожалуй меньше 20% от общей массы вэб-мастеров с вордпрессами и т.д.
Мне вот, я считаю, повезло с задачами. Но могу сказать по своему опыту, найти толкового PHP-ника весьма и весьма сложно. Найти толкового .NET-чика чуть проще, но их меньше выходит.
Иван Антонов: отдельным полем если статусы ограничены. Если статусы должны работать по типу категорий (например админ может ввести новый статус для заказа, что бы адаптировать все под свой флоу работы) - то тогда схема приведенная вами вполне себе валидна.
Digital Brain: нет конечно, если вас устраивает ваш стэк и разницы не много - то да, смысла перелазить нет. Я потому не собираюсь пока слазить с ангуляра ибо меня он всем устраивает.
Angular2 будет модульным, так что вы можете спокойно использовать из него только то что нужно вам. Монолитность 1-ого ангуляра это его серьезный минус.
Владислав Танков: ближе к мидлу - это где-то между джуниором и мидлом. В целом статистика показывает что даже синьер по-ха-пэ (как они себя величают в резюме) с приличным опытом работы не всегда знают как работает хэш-мэпа, и не такой большой процент может слегкостью сказать что такое логарифмическая сложность. Оно и понятно, в WEB в контексте PHP это не настолько распространенные штуки. Скажем среди .NET-чиков это уже более распрастранено.
