За последние 24 часа нас посетил 18281 программист и 1644 робота. Сейчас ищут 1064 программиста ...

native PHP или Laravel для потенциально крупного проекта

Тема в разделе "Laravel", создана пользователем Rednaxela, 16 мар 2017.

  1. Rednaxela

    Rednaxela Новичок

    С нами с:
    16 мар 2017
    Сообщения:
    13
    Симпатии:
    0
    Товарищи! Возникла дилемма - на чем разработать проект на native PHP или Laravel
    Объем прокта следующий:
    1. примерно 20 - 25 страниц
    2. учетные записи пользователей до сотен тысяч
    3. у ползователей свои items до 5000 на пользователя
    4. внутренние сообщения между пользователями
    5 .личный кабинет со всеми вытекающими последствиями ..
    в планах расширять функционал постоянно
     
  2. denis01

    denis01 Суперстар
    Команда форума Модератор

    С нами с:
    9 дек 2014
    Сообщения:
    12.227
    Симпатии:
    1.714
    Адрес:
    Молдова, г.Кишинёв
    Мало данных, делай на Laravel, думаю что в проекте больше временинужно уделить архитектуре базы данных и запросам
     
  3. Rednaxela

    Rednaxela Новичок

    С нами с:
    16 мар 2017
    Сообщения:
    13
    Симпатии:
    0
    меня больше волнует вопрос приемистости -
    и наиболееважный вопрос СКОРОСТЬ выборки из БД , тк в лвравел запросы разработчик не контролирует
     
  4. denis01

    denis01 Суперстар
    Команда форума Модератор

    С нами с:
    9 дек 2014
    Сообщения:
    12.227
    Симпатии:
    1.714
    Адрес:
    Молдова, г.Кишинёв
    напиши, что это значит, по подробнее

    контролирует, просто по умолчанию есть несколько инструментов, не думаю что Query Builder сильно тормозит, вот ORM возможно не так быстро работает, но и его можно настроить, потому что надо от задачи выбирать инструмент.
     
    Rednaxela нравится это.
  5. Rednaxela

    Rednaxela Новичок

    С нами с:
    16 мар 2017
    Сообщения:
    13
    Симпатии:
    0
    приемистости значит что завтра когда разработчик передаст проект другому разраотчику то в чем ему будет проще разобраться - в ларавел коде или в чистом пхп.
    например как я вижу что лучше использоавть обычный пхп обычные sql запросы и только кое где подсасывать какие-то бибилиотечки... .
    вот именно ORM меня беспокоит . можно ли его например не использовать а вместо него прямые запросы или в этом случае вообще теряется весь смысл использования ларавел....

    другими словами на что я потрачу много времени работая на пхп, по сравнению если бы я использовал ларавел (с учетом того что в обоих случаях я буду писать прямые запросы в базу)
     
  6. denis01

    denis01 Суперстар
    Команда форума Модератор

    С нами с:
    9 дек 2014
    Сообщения:
    12.227
    Симпатии:
    1.714
    Адрес:
    Молдова, г.Кишинёв
    если он знает Lavarel думаю ему в нём будет проще

    В первую очередь всё надо тестировать, потому что обычно библиотеки очень хорошо написаны.

    Вот про это я и говорил, там где уместно используем ORM, где нет Query Builder, ну и задача может быть узкоспециализированной, что нужно часть написать и без этого.

    @Rednaxela всё сводиться к тому, что выбор должны делать специалисты которые уже имеют опыт, так больше шансов угадать
    --- Добавлено ---
    В lavarel много готовых решений, если их знать, то с ним быстрее. Но для начало напиши техническое задание на весь функционал, так будет проще выбирать что-то.
    За PHP дело за малым, залезть в базу и получить данные.
     
  7. Rednaxela

    Rednaxela Новичок

    С нами с:
    16 мар 2017
    Сообщения:
    13
    Симпатии:
    0
    Дело в том что проект уже реализован на Laravel так сказать прототип, но на пример на 1000 позиций запрос в базу идет несколько секунд 15-20 поэтому надо оптимизироавть код... кроме того верстка css не оптимизирована и не универсальна, ее тоже надо оптимизировать... разные разрабы говорят по разному... ктото говорит что ОРМ тормозит и он прав, кто то говорит о готовых библиотеках.

    вот для примера можете привести ну хотябы 3 -5 бибилиотек популярных на которых существенно экономится время?
    я как организатор и спонсор проекта хочу понять куда двигаться чтобы не платить по нескольку раз за разработку
     
  8. romach

    romach Старожил

    С нами с:
    26 окт 2013
    Сообщения:
    2.904
    Симпатии:
    719
    Всем известно, что до 200 000 записей в таблице надо использовать Laravel, а больше - исключительно писать запросы руками. Потому что данные не захотят собираться запросом, составленным бездушной машиной!

    p.s. тема доставила ))
    --- Добавлено ---
    @Rednaxela, расскажите горе-программистам про ->with(), пусть они откроют доку по Eloquent и прочитают. А ещё поставьте Debugbar и настучите по голове за каждый лишний запрос к базе. Гарантирую, время выборки начнет исчисляться миллисекундами )
     
    igordata и mahmuzar нравится это.
  9. Rednaxela

    Rednaxela Новичок

    С нами с:
    16 мар 2017
    Сообщения:
    13
    Симпатии:
    0
    ну а что теперь делать - переписывать запросы в ларавел или вообще весь проект под чистую?
     
  10. romach

    romach Старожил

    С нами с:
    26 окт 2013
    Сообщения:
    2.904
    Симпатии:
    719
    Поясню в чем проблема (не факт, конечно, но она довольно распространена у тех, кто не дочитал доки до конца.

    В моделях ORM прописываются связи, которые по умолчанию подгружаются в ленивом режиме. К примеру, есть у вас модель пользователя User и некие данные, которые они создают Items. Прописав связь и обратившись к свойству объекта $user->items вы инициируете запрос к БД, который подгрузит всё что нужно, в т.ч. и с заранее прописанными условиями. Всё хорошо ровно до тех пор, пока вам не понадобится выбрать 1000 записей и вместе с ними подтянуть все связи. На выходе вы получите 1001 запрос к БД (запрос выборки пользователя и по запросу на связь). Что бы этого избежать, нужно изначально указать о том что нехер лениться. ->with('items') уложит все в два запроса: select * from users и select from items where user_id in (...). В большинстве случаев этого механизма более чем достаточно.

    Другое дело, когда записей действительно много, пых выжрет всю доступную ему оперативку и возможно сдохнет от нехватки памяти. Вот тогда выборку лучше оформить в отдельный класс, куда передается request, на месте же валидируется и query builder`ом составляется нужный запрос (запросы). Оверхед на это минимальный, гораздо меньше, чем потратит БД на выборку, взамен же мы получаем прозрачный инструмент, который можно дергать отовсюду и так же централизованно изменять не боясь что-нибудь сломать или пропустить место в коде, где тоже делается подобная выборка, но результат-теперь-выглядит-немного-по-другому.
    --- Добавлено ---
    Для начала, я бы посоветовал вам взять вот эту штуку: https://github.com/fzaninotto/Faker и забить базу, создать сотню тысяч фэйковых пользователей, к каждому по 5000 items`ов. Потратьте на это день или два, но зато в итоге вы сразу увидите все узкие места, где сожрется оперативка, где нужно добавить индексов в БД, где достаточно ORM, в каком месте лучше самостоятельно составить запрос, а где для поиска заюзать какой-нибудь elastic. Это что бы не случилось "ой" после сдачи проекта. Ну а дальше уже смотреть по ситуации, если программисты таки осилят доку и сделают нормально - значит не стоит переживать, ну а если нет - тогда ищите другие варианты.
     
    denis01, mahmuzar, [vs] и ещё 1-му нравится это.
  11. [vs]

    [vs] Суперстар
    Команда форума Модератор

    С нами с:
    27 сен 2007
    Сообщения:
    10.557
    Симпатии:
    631
    @Rednaxela помимо работы с БД, фреймворки предлагают готовые решения для пострения api, контроля сессий, шаблонизации и т.д., в этом плане с точки зрения приемственности, framework лучше
     
    denis01 и mahmuzar нравится это.
  12. Rednaxela

    Rednaxela Новичок

    С нами с:
    16 мар 2017
    Сообщения:
    13
    Симпатии:
    0
    Взял, но что с ней делать не понимаю, я не php разработчик, но понимание обще как ве это работает есть. Что с ней делать? Как запустить?
    Куда на сервер что скопировать и что запустить ?
     
    #12 Rednaxela, 16 мар 2017
    Последнее редактирование: 16 мар 2017
  13. mahmuzar

    mahmuzar Старожил

    С нами с:
    6 апр 2012
    Сообщения:
    4.631
    Симпатии:
    425
    Адрес:
    РД, г. Махачкала.
    @Rednaxela. если мотнуть страницу вниз, там есть инструкция.
     
  14. romach

    romach Старожил

    С нами с:
    26 окт 2013
    Сообщения:
    2.904
    Симпатии:
    719
    Т.к. у вас проект на Laravel, то устанавливать ничего не нужно, Faker идет в комплекте.

    Это будет выглядеть примерно вот так. Создаете класс в app/Console
    PHP:
    1. <?php namespace App\Console;
    2.  
    3. use App\User;
    4. use App\Item;
    5. use Faker\Factory;
    6. use Illuminate\Console\Command;
    7. use Symfony\Component\Console\Helper\ProgressBar;
    8.  
    9. class FakerSeedCommand extends Command
    10. {
    11.     /**
    12.      * The console command name.
    13.      *
    14.      * @var string
    15.      */
    16.     protected $signature = 'faker:seed';
    17.  
    18.     /**
    19.      * The console command description.
    20.      *
    21.      * @var string
    22.      */
    23.     protected $description = '';
    24.  
    25.     public function handle()
    26.     {
    27.         $totalUsers = 100000;
    28.         $totalItems = 5000;
    29.         /* Прогресбар, что бы не скучать в ожидании */
    30.         $progress = new ProgressBar($this->getOutput(), $totalUsers);
    31.         $progress->setFormat('debug');
    32.         $progress->start();
    33.         /* Faker */
    34.         $faker = Factory::create('ru_RU');
    35.         /* Добавляем записи. По хорошему, такое количество записей лучше добавлять пакетом, гораздо быстрее и правильнее, но как для примера сойдет. */
    36.         for($userCounter = 0; $userCounter < $totalUsers; $userCounter++) {
    37.             $user = new User();
    38.             $user->name = $faker->name;
    39.             $user->email = $faker->email;
    40.             $user->password = bcrypt($faker->password());
    41.             $user->save();
    42.             for ($itemCounter = 0; $itemCounter < $totalItems; $itemCounter++) {
    43.                 $item = new Item;
    44.                 $item->title = $faker->title;
    45.                 $item->content = $faker->text();
    46.                 /* Если связи в моделях прописаны, то можно сразу так */
    47.                 $user->items()->save($item);
    48.             }
    49.             $progress->advance();
    50.         }
    51.         $progress->finish();
    52.     }
    53. }
    Далее, в app/Console/Kernel.php в $commands[] добавляете команду:
    Код (Text):
    1. \App\Console\FakerSeedCommand::class
    Запускаете её из консоли и идете пить чай )
    Код (Text):
    1. php artisan faker:seed
    [​IMG]

    Но это конечно же всё в общих чертах, вам нужно заполнить данными максимально приближенными к реальным, в примерно таком же количестве.
     
  15. denis01

    denis01 Суперстар
    Команда форума Модератор

    С нами с:
    9 дек 2014
    Сообщения:
    12.227
    Симпатии:
    1.714
    Адрес:
    Молдова, г.Кишинёв
    тогда подпишите договор и разработайте техническое задание с компанией которая сможет вам выплатить штраф если вы получите не тот результат о котором договаривались, третью компанию возьмите вас консультировать по разработке технического задания
     
  16. Chushkin

    Chushkin Активный пользователь

    С нами с:
    17 дек 2010
    Сообщения:
    1.062
    Симпатии:
    91
    Адрес:
    Мещёра, Центр, Болото N3
  17. Fell-x27

    Fell-x27 Суперстар
    Команда форума Модератор

    С нами с:
    25 июл 2013
    Сообщения:
    12.156
    Симпатии:
    1.770
    Адрес:
    :сердА
    Я бы еще, кроме прочего, поглядел на архитектуру БД, на то, какими запросами идет выборка и на то, как обстоят дела с индексами. 15-20 секунд это дюже дохрена даже для 1000 простых запросов к БД. А для ORM, мапящейся на таблицу "как есть", только такие и нужны.
     
  18. mkramer

    mkramer Суперстар
    Команда форума Модератор

    С нами с:
    20 июн 2012
    Сообщения:
    8.579
    Симпатии:
    1.759
    Можно на Laravel написать быструю программу. Можно без фреймворков написать тормоза. ORM да, аккуратно нужно использовать. С другой стороны, зачем грузить сразу 1000 строк чего бы то ни было? Обычно используется пагинация. Как уже написали, Laravel позволяет писать и без ORM. Если вы не разработчик, наймите разработчика.
     
    igordata и denis01 нравится это.
  19. Rednaxela

    Rednaxela Новичок

    С нами с:
    16 мар 2017
    Сообщения:
    13
    Симпатии:
    0
    Разработчика нанимали и не одного, но разработчики разные.
    Возвращаюсь к тому что если хочешь сделать что-то действительно хорошо - сделай сам или по крайней мере разберись так чтобы было все по полочкам, поэтому разбираюсь сам.

    Пагинация это конечно хорошо, но если у вас фильтры работают по миллиону записей (сразу по всему пулу) и вся пагинация пересчитывается при каждом клике мышки на фильтре- то скорость в этом случае имеет наивысший приоритет.
     
  20. denis01

    denis01 Суперстар
    Команда форума Модератор

    С нами с:
    9 дек 2014
    Сообщения:
    12.227
    Симпатии:
    1.714
    Адрес:
    Молдова, г.Кишинёв
    @Rednaxela было ли написано техническое задание с разжевыванием всех возможностей, которые должны быть? Нарисованные все страницы и т. д.?
     
  21. mkramer

    mkramer Суперстар
    Команда форума Модератор

    С нами с:
    20 июн 2012
    Сообщения:
    8.579
    Симпатии:
    1.759
    В случае абстрактного коня в вакууме ничего не могу сказать ни за ORM, ни против. На конкретной задачи будет видно. Знакомый, к примеру, очень крутой разраб на Yii2 (другой фреймворк) говорит, что он делает ActiveRecord ORM (а у Laravel тоже ActiveRecord) только для админки, а для фронтенда пишет Query Builder. У меня проекты не так масштабны, поэтому я в пользу удобства делаю ActiveRecord и там и там. Но частично пишу запросы руками. Плюс ключи. Плюс организация базы данных. Плюс, иногда, в случае, к примеру, с Entiti-Atribute-Value (которую надо использовать только там, где без неё не обойтись) есть смысл использовать совместно с базой какой-нибудь Sphinx, Elastic Search и другие подобные поисковики. Хотя, последняя версия MySQL позволяет обойтись, и использовать JSON-поля (очень мощная штука, сейчас на одном проекте попробовал, прямо удобно-удобно-удобно)
    --- Добавлено ---
    Query Builder, если что, это просто более удобный интерфейс для генерации самых обычных SQL запросов, весь SQL полностью под контролем программиста.
     
  22. Fell-x27

    Fell-x27 Суперстар
    Команда форума Модератор

    С нами с:
    25 июл 2013
    Сообщения:
    12.156
    Симпатии:
    1.770
    Адрес:
    :сердА
    1) чистые запросы
    2) правильные индексы
    3) кэширование результатов(если применимо)
    4) правильные, блин, индексы
    5) правильные индексы
    --- Добавлено ---
    Охренительнейшая тема, подтверждаю.
     
  23. acho

    acho Активный пользователь

    С нами с:
    28 дек 2016
    Сообщения:
    854
    Симпатии:
    210
    Адрес:
    Санкт-Петербург
    А в каких случаях вы используете?
    Кстати, mariaDB поддерживает json?
     
  24. Fell-x27

    Fell-x27 Суперстар
    Команда форума Модератор

    С нами с:
    25 июл 2013
    Сообщения:
    12.156
    Симпатии:
    1.770
    Адрес:
    :сердА
    Ну например, нужно у меня в одном проекте хранить абстрактные сущности. Количество и типы их свойств заранее не определены. Эти сущности генерирует редактор, который можно собрать как тебе угодно, чтобы он генерил что угодно. Внимание вопрос - как хранить результаты его работы? Правильно, в отдельной JSON-колонке. При этом каждая такая JSON-запись, если тип поля именно json, является "мини-бд", к которой можно делать запросы, не дергая сам объект целиком.
    --- Добавлено ---
    В этом плане, там, вроде, все по-другому работает.
     
    acho нравится это.