Учебная группа разработчиков и общий чат. Бесплатно, Skype.
Контакты
Местоположение
Россия, Волгоградская обл., Волгоград

Достижения

Все достижения (48)

Наибольший вклад в теги

Все теги (228)

Лучшие ответы пользователя

Все ответы (777)
  • Для чего идеальна MongoDb? Примеры приложений, где монга будет лучше mysql?

    Wolfnsex
    @Wolfnsex
    Если не хочешь быть первым - не вставай в очередь!
    Я расскажу Вам про личный опыт, без претензий на истину в последней инстанции...

    Для чего идеальна MongoDb? Примеры приложений, где монга будет лучше mysql?
    Для человека который привык работать с реляционными БД, смириться с логикой и вообще с подобными БД - довольно сложно. Для тех, кто работает с реляционными БД профессионально - сделать это ещё сложнее...

    Если сравнивать с реляционными БД и с оглядкой на конкретно MySQL - монга идеально вписывается там, где структура данных заранее неизвестна. Тут я хотел привести пример, но не смог придумать ни одного дельного примера, после того как начал плотно работать с PostgreSQL... Давайте попробую из практики. Мы один раз применяли монгу в проекте где есть десятки и сотни тысяч товарных позиций и у каждой из них свой уникальный набор различных свойств. На основе уже имеющихся свойств, "соседних" товаров, контентщику предлагался наиболее вероятный набор параметров, которые нужно заполнить, но в любой момент он мог удалить или добавить любое поле и/или множество значений одного из них, например, "Цвет: черный, серый, фиолетовый". Всё это дело попадало под разные динамические фильтры и далее по цепочке... В то время, насколько я помню ещё не было поддержки JSONB-формата у PostgreSQL, по этому мы остановились на MongoDB. Ну и конечно же, желание "воткнуть ультра новую и модную БД в проект" сыграло свою роль...

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

    Безусловно, не редко можно встретить проекты в которых даже в реляционных БД не прописаны, например, внешние ключи и контроля целостности данных как такового нет, но обычно это происходит по следующим причинам:
    1. Очень низкая квалификация администратора БД проекта
    2. В попытке выжать из базы больше производительности, не найдя других методов оптимизации
    3. Данных настолько много, что БД/ключи - начинают "сыпаться", не редко это связано с п.1

    Так же, последние тесты показывают, что PostgreSQL почти не уступает MongoDB даже в её родной среде (на уровне данных в формате JSON). А в некоторых аспектах даже превосходит её... Подробности Вы можете увидеть на некоторых конференциях по Postgres (да, на конференциях по MongoDB, Вы вряд ли увидите, как кто-то будет рассказывать, что [их любимая] монга "хуже" некоторых других движков...). Кстати, поддержку формата JSON стандартизировали (наконец-то) на уровне SQL-стандарта (если я не ошибаюсь) и в самом ближайшем будущем, думаю стоит ожидать полноценную поддержку оного в SQL-базах, в т.ч. поддержку в бинарном виде с возможностью индексации данных (кстати, некоторые SQL-базы уже такое умеют).

    Моё понимание, ответа на вопрос, "когда действительно стоит использовать MogoDB?" звучит примерно так: Исключительно в тех случаях, когда Вы понимаете, что она станет действительно хорошим решением для поставленной задачи и сейчас и в будущем. В моей практике, таких проектов можно было бы насчитать ничтожно мало, а точнее около нуля, особенно с учётом развития некоторых современных SQL-БД и вообще направления "JSON в SQL" в целом. Но, безусловно такие проекты могут быть и есть (в данном случае, не у меня). Но, тут стоит обратить внимание на крайне важный факт - когда всплывает такой проект, что бы адекватно оценить наиболее оптимальную БД под него - нужно знать как минимум пару-тройку SQL-БД, со всеми их особенностями, достоинствами и недостатками... причем не просто "знать", а хорошо знать, "изнутри". А так же знать все характерные черты монги, а так же её особенности, достоинства и т.д. То есть, если Вы задаётесь вопросом, "а хорошо ли впишется монга в проект N?" и не можете найти на него однозначного ответа, вероятнее всего, что в долгосрочной перспективе, в "проект N" она впишется плохо.

    P.S. В заключение, хочу ещё раз напомнить, что "JSON в SQL" - активно развивается... Со всеми вытекающими.
    Ответ написан
  • Почему люди не используют готовые cms, но ищут тех, кто будет писать с нуля?

    Wolfnsex
    @Wolfnsex Куратор тега PHP
    Если не хочешь быть первым - не вставай в очередь!
    Возникает вопрос, почему тогда работодатели нанимают за высокую плату много программистов что бы они копались в коде а не тех кто будет делать тот же продукт прибегаю к помощи к cms?

    На это есть много причин, в том числе:
    а) CMS (большинство) гораздо медленнее большинства фреймворков, обычно в 10-50 раз
    б) CMS - не редко так же построены на фреймворках, например Drupal 8 - построен на Symfony. Получается, что CMS это уже продукт. Делать продукт из продукта (или продукт поверх продукта) в этой цепочке - не очень разумно. Это всё равно, что пытаться сделать гоночный болид из жигулей 6-ой модели, вместо того, что бы спроектировать и создать его заново.
    в) CMS предназначены для быстрой разработки сайтов. Скорость разработки достигается за счёт ущерба качеству буквально всего. В среднем CMS генерирует 100-1000 SQL-запросов на создание страницы, аналогичный проект на фреймворке тратит на это 5-20 запросов (примерно). У нас например, есть проект сделанный на фреймворке - база технических изделий, среднее кол-во запросов на страницу - до 20шт. и с учётом объёмов данных (деталей там несколько тысяч, а их параметров - несколько десятков тысяч) - это всё довольно неплохо нагружает сервер. Аналогичный проект на CMS потребовал бы просто аховых затрат на хостинг и генерировал бы по 500-700 запросов на страницу (мы проверяли).
    г) Из CMS гораздо сложнее сделать именно то, что хочется, а не то, "что получилось".
    д) CMS налагает свои правила на работу, а ФВ обычно ограничиваются некоторыми рекомендациями (в большинстве случаев).
    е) и так далее...

    Так происходит по тому, что CMS созданы для решения шаблонных задач, а проекты на ФВ пишутся обычно, для решения вполне конкретных задач.

    P.S. Очень крупные проекты, типа FaceBook, VK и пр. пишутся даже не на CMS, а на чистом PHP например. Т.к. CMS в таких проектах - так же даёт избыточную нагрузку, с учётом масштабов этих самых проектов.

    P.P.S. Недавно настраивал небольшой корпоративный сервер, там 4-х ядреный процессор, 8Gb RAM и обычно HDD 7200/rpm. "Голая" Joomla 3.6 с демо данными, генерировал страницу за 250-400мс., чуть более крупный по масштабам проект, сделанный на ФВ, так же с авторизацией и пр. плюшками, генерировал страницу (сложнее) за 20-50мс.
    Ответ написан
  • PHP фреймворк для начинающего разработчика?

    Wolfnsex
    @Wolfnsex Куратор тега PHP
    Если не хочешь быть первым - не вставай в очередь!
    Фреймворков в целом, которые достигли должного уровня популярности и народного признания - не так уж много (если говорить о PHP-фреймворках).

    Для начинающего, с целью понять сущность MVC, "пощупать" некоторые аспекты фреймворка, такие например, как загрузка библиотек и пр. подобности, я бы порекомендовал Вам CodeIgniter. Отличная документация, довольно много людей, кто сможет Вам ответить на возникающие вопросы, есть документация на русском. А так же, минимальное количество "лишнего" из коробки, например, шаблонизаторов (которые Вы можете самостоятельно подключить, если очень хочется).

    После этого фреймворка, промежуточным, можно было бы считать Kohana, но, он что-то то "умирает", то снова "воскресает"... С документацией на него, по моему, всё так же плохо (читай "не очень хорошо") как и всегда... но, по нему есть несколько неплохих видео-уроков.

    Суда же можно отнести Yii, на мой взгляд, он застрял где-то между "большими" и "маленькими" фреймворками. Маленьким его уже не назовёшь, по ряду признаков, а до большого и целостного - он ещё не дотягивает. Но, он довольно популярен на просторах бывшего СССР (по понятным для многих причинам), в виду чего имеет довольно большое русскоговорящее сообщество и целую толпу ярых фанатов.

    Далее, в обязательном порядке будет идти Laravel - превосходная документация, примеры и фантастическое количество видео-уроков (если хорошо понимаете английский). Отличный фреймворк собранный на базе Symfony. Относится уже к "большим".

    Ну а когда станете совсем матёрым программистом, и "лишний" код будет писать уже не в моготу, когда изучите все основные аспекты разработки, в том числе "сервис контейнеры", "внедрение зависимостей", будете понимать основные сетевые протоколы на низком уровне... а качество и разделяемость кода - будет одним из приоритетных условий - рекомендую обязательно ознакомиться с Symfony. Уроков по нему, довольно небольшое количество, вменяемого материала на русском языке - практически нет вообще... Но, достаточно легко изучается когда есть хороший багаж знаний и опыт работы с другими фреймворками.

    P.S. Я понимаю, что Вы спрашивали "какой фреймворк учить первым?", а не какие они бывают вообще. Но, дабы предостеречь Вам от вопросов типа "какой фреймворк учить вторым?" или "почему Symfony в роли первого фреймворка так тяжело изучать?" и массы прочих подобных - озвучил одни из самых популярных фреймворков в мире веб-разработок в ракурсе PHP.
    Ответ написан
  • Как устроиться на работу бывшему ИП?

    Wolfnsex
    @Wolfnsex
    Если не хочешь быть первым - не вставай в очередь!
    Я просто оставлю это здесь...
    ffwXS-dFleY.jpg
    Ответ написан
  • Какой PHP фреймворк посоветуете для быстрой разработки проекта?

    Wolfnsex
    @Wolfnsex Куратор тега PHP
    Если не хочешь быть первым - не вставай в очередь!
    - Представление о MVC имею. Раньше писал пару проектов на CodeIgniter, но на нём на мой взгляд мало что есть из коробки, и много времени уходит на разработку.
    С тех пор изобрели Composer, при должном желании прикручивается он и к CI в том числе :)

    - Нужен современный не заброшенный фреймворк, с достаточным количеством документации. Не обязательно на русском, но будет плюсом.
    На русском - CodeIgniter, на не русском - Laravel, Symfony и другие.

    - Хотелось бы большое количество подключаемого функционала из коробки, для экономии времени разработки. Например уже написанная логика авторизации, регистрации, восстановления пароля и разграничения по уровням доступа. Понимаю что всё равно придется немного допиливать под свои нужды, но времени это сэкономило бы кучу.
    Composer - решает 99% проблем, практически в любом фреймворке.

    - Возможность работы с различными БД из коробки
    Пока фреймворков без этой штуки не видел, но есть... Вы не поверите, Composer, что бы сменить/поставить "другой" ORM, если Вам "текущий" чем-то не подошел.

    - Поддержка кэширования из коробки. И желательно что бы была поддержка некешируемых областей при генерации страницы, а сам кэш был управляемым.
    То о чем Вы говорите, это: Varnish, Nginx+SSI и т.д. кэширование "из коробки" есть в Symfony (т.к. если его отключить, страницы может генерироваться феерически долго)

    - Не тяжелый фреймворк, в котором оптимизирован код, и который не жрёт огромное количество ресурсов на сервере. Если будет поддержка PHP7 - тоже плюс.
    По моему, любой современный фреймворк, если уже даже "Битрикс" небеизвестный до этого до этого дошел... некоторые фреймворки вообще скоро будут требовать PHP7, а не только "поддерживать".

    - Проект будет ориентировочно крутиться на nginx+php5-fpm. Думаю практически все фреймворки смогут работать в этой среде, но вдруг...
    Я пока таких "вдруг" не встречал. Если у админа голова и руки на месте - то никаких "вдруг" быть не должно. А вообще, у PHP версии 5.х, есть как минимум 3 основных "ветки", это <5.3, >=5.3 или 5.4+ и т.д., ещё кое-какие отличия были в 5.5 и 5.6, но не такие "разительные", подробности можно почитать в истории версий PHP. По этому, нужно конкретнее указывать версию, например, Laravel требует 5.6+

    - Возможность масштабирования. В принципе не обязательно, но возможно однажды будет масштабироваться проект.
    Это не возможность фреймворка - а навык программиста/админа.

    - Всякие плюшки из коробки типа каптчи, обработки и обрезки изображений и прочие приятности будут огромным плюсом и будут иметь «больший вес» при выборе, т.к. важна простота и скорость разработки.

    1. Yii2
    2. CMS + готовые модули CMS
    3. Вы не забыли, что есть... composer?!

    P.S. Простота и скорость разработки зависит исключительно от уровня Вашего понимания процесса и прочих личностных навыков. В эти же навыки, как один из первичных, входит умение "правильно выбирать фреймворк под конкретную задачу".

    Большое спасибо за время уделенное прочтению моего вопроса, и огромное спасибо за Ваши ответы.
    Не за что! Кнопка "Мне нравиться" - сразу под сообщением :D
    Ответ написан

Лучшие вопросы пользователя

Все вопросы (32)