Товарищи! Возникла дилемма - на чем разработать проект на native PHP или Laravel Объем прокта следующий: 1. примерно 20 - 25 страниц 2. учетные записи пользователей до сотен тысяч 3. у ползователей свои items до 5000 на пользователя 4. внутренние сообщения между пользователями 5 .личный кабинет со всеми вытекающими последствиями .. в планах расширять функционал постоянно
Мало данных, делай на Laravel, думаю что в проекте больше временинужно уделить архитектуре базы данных и запросам
меня больше волнует вопрос приемистости - и наиболееважный вопрос СКОРОСТЬ выборки из БД , тк в лвравел запросы разработчик не контролирует
напиши, что это значит, по подробнее контролирует, просто по умолчанию есть несколько инструментов, не думаю что Query Builder сильно тормозит, вот ORM возможно не так быстро работает, но и его можно настроить, потому что надо от задачи выбирать инструмент.
приемистости значит что завтра когда разработчик передаст проект другому разраотчику то в чем ему будет проще разобраться - в ларавел коде или в чистом пхп. например как я вижу что лучше использоавть обычный пхп обычные sql запросы и только кое где подсасывать какие-то бибилиотечки... . вот именно ORM меня беспокоит . можно ли его например не использовать а вместо него прямые запросы или в этом случае вообще теряется весь смысл использования ларавел.... другими словами на что я потрачу много времени работая на пхп, по сравнению если бы я использовал ларавел (с учетом того что в обоих случаях я буду писать прямые запросы в базу)
если он знает Lavarel думаю ему в нём будет проще В первую очередь всё надо тестировать, потому что обычно библиотеки очень хорошо написаны. Вот про это я и говорил, там где уместно используем ORM, где нет Query Builder, ну и задача может быть узкоспециализированной, что нужно часть написать и без этого. @Rednaxela всё сводиться к тому, что выбор должны делать специалисты которые уже имеют опыт, так больше шансов угадать --- Добавлено --- В lavarel много готовых решений, если их знать, то с ним быстрее. Но для начало напиши техническое задание на весь функционал, так будет проще выбирать что-то. За PHP дело за малым, залезть в базу и получить данные.
Дело в том что проект уже реализован на Laravel так сказать прототип, но на пример на 1000 позиций запрос в базу идет несколько секунд 15-20 поэтому надо оптимизироавть код... кроме того верстка css не оптимизирована и не универсальна, ее тоже надо оптимизировать... разные разрабы говорят по разному... ктото говорит что ОРМ тормозит и он прав, кто то говорит о готовых библиотеках. вот для примера можете привести ну хотябы 3 -5 бибилиотек популярных на которых существенно экономится время? я как организатор и спонсор проекта хочу понять куда двигаться чтобы не платить по нескольку раз за разработку
Всем известно, что до 200 000 записей в таблице надо использовать Laravel, а больше - исключительно писать запросы руками. Потому что данные не захотят собираться запросом, составленным бездушной машиной! p.s. тема доставила )) --- Добавлено --- @Rednaxela, расскажите горе-программистам про ->with(), пусть они откроют доку по Eloquent и прочитают. А ещё поставьте Debugbar и настучите по голове за каждый лишний запрос к базе. Гарантирую, время выборки начнет исчисляться миллисекундами )
Поясню в чем проблема (не факт, конечно, но она довольно распространена у тех, кто не дочитал доки до конца. В моделях 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. Это что бы не случилось "ой" после сдачи проекта. Ну а дальше уже смотреть по ситуации, если программисты таки осилят доку и сделают нормально - значит не стоит переживать, ну а если нет - тогда ищите другие варианты.
@Rednaxela помимо работы с БД, фреймворки предлагают готовые решения для пострения api, контроля сессий, шаблонизации и т.д., в этом плане с точки зрения приемственности, framework лучше
Взял, но что с ней делать не понимаю, я не php разработчик, но понимание обще как ве это работает есть. Что с ней делать? Как запустить? Куда на сервер что скопировать и что запустить ?
Т.к. у вас проект на Laravel, то устанавливать ничего не нужно, Faker идет в комплекте. Это будет выглядеть примерно вот так. Создаете класс в app/Console PHP: <?php namespace App\Console; use App\User; use App\Item; use Faker\Factory; use Illuminate\Console\Command; use Symfony\Component\Console\Helper\ProgressBar; class FakerSeedCommand extends Command { /** * The console command name. * * @var string */ protected $signature = 'faker:seed'; /** * The console command description. * * @var string */ protected $description = ''; public function handle() { $totalUsers = 100000; $totalItems = 5000; /* Прогресбар, что бы не скучать в ожидании */ $progress = new ProgressBar($this->getOutput(), $totalUsers); $progress->setFormat('debug'); $progress->start(); /* Faker */ $faker = Factory::create('ru_RU'); /* Добавляем записи. По хорошему, такое количество записей лучше добавлять пакетом, гораздо быстрее и правильнее, но как для примера сойдет. */ for($userCounter = 0; $userCounter < $totalUsers; $userCounter++) { $user = new User(); $user->name = $faker->name; $user->email = $faker->email; $user->password = bcrypt($faker->password()); $user->save(); for ($itemCounter = 0; $itemCounter < $totalItems; $itemCounter++) { $item = new Item; $item->title = $faker->title; $item->content = $faker->text(); /* Если связи в моделях прописаны, то можно сразу так */ $user->items()->save($item); } $progress->advance(); } $progress->finish(); } } Далее, в app/Console/Kernel.php в $commands[] добавляете команду: Код (Text): \App\Console\FakerSeedCommand::class Запускаете её из консоли и идете пить чай ) Код (Text): php artisan faker:seed Но это конечно же всё в общих чертах, вам нужно заполнить данными максимально приближенными к реальным, в примерно таком же количестве.
тогда подпишите договор и разработайте техническое задание с компанией которая сможет вам выплатить штраф если вы получите не тот результат о котором договаривались, третью компанию возьмите вас консультировать по разработке технического задания
Я бы еще, кроме прочего, поглядел на архитектуру БД, на то, какими запросами идет выборка и на то, как обстоят дела с индексами. 15-20 секунд это дюже дохрена даже для 1000 простых запросов к БД. А для ORM, мапящейся на таблицу "как есть", только такие и нужны.
Можно на Laravel написать быструю программу. Можно без фреймворков написать тормоза. ORM да, аккуратно нужно использовать. С другой стороны, зачем грузить сразу 1000 строк чего бы то ни было? Обычно используется пагинация. Как уже написали, Laravel позволяет писать и без ORM. Если вы не разработчик, наймите разработчика.
Разработчика нанимали и не одного, но разработчики разные. Возвращаюсь к тому что если хочешь сделать что-то действительно хорошо - сделай сам или по крайней мере разберись так чтобы было все по полочкам, поэтому разбираюсь сам. Пагинация это конечно хорошо, но если у вас фильтры работают по миллиону записей (сразу по всему пулу) и вся пагинация пересчитывается при каждом клике мышки на фильтре- то скорость в этом случае имеет наивысший приоритет.
@Rednaxela было ли написано техническое задание с разжевыванием всех возможностей, которые должны быть? Нарисованные все страницы и т. д.?
В случае абстрактного коня в вакууме ничего не могу сказать ни за ORM, ни против. На конкретной задачи будет видно. Знакомый, к примеру, очень крутой разраб на Yii2 (другой фреймворк) говорит, что он делает ActiveRecord ORM (а у Laravel тоже ActiveRecord) только для админки, а для фронтенда пишет Query Builder. У меня проекты не так масштабны, поэтому я в пользу удобства делаю ActiveRecord и там и там. Но частично пишу запросы руками. Плюс ключи. Плюс организация базы данных. Плюс, иногда, в случае, к примеру, с Entiti-Atribute-Value (которую надо использовать только там, где без неё не обойтись) есть смысл использовать совместно с базой какой-нибудь Sphinx, Elastic Search и другие подобные поисковики. Хотя, последняя версия MySQL позволяет обойтись, и использовать JSON-поля (очень мощная штука, сейчас на одном проекте попробовал, прямо удобно-удобно-удобно) --- Добавлено --- Query Builder, если что, это просто более удобный интерфейс для генерации самых обычных SQL запросов, весь SQL полностью под контролем программиста.
1) чистые запросы 2) правильные индексы 3) кэширование результатов(если применимо) 4) правильные, блин, индексы 5) правильные индексы --- Добавлено --- Охренительнейшая тема, подтверждаю.
Ну например, нужно у меня в одном проекте хранить абстрактные сущности. Количество и типы их свойств заранее не определены. Эти сущности генерирует редактор, который можно собрать как тебе угодно, чтобы он генерил что угодно. Внимание вопрос - как хранить результаты его работы? Правильно, в отдельной JSON-колонке. При этом каждая такая JSON-запись, если тип поля именно json, является "мини-бд", к которой можно делать запросы, не дергая сам объект целиком. --- Добавлено --- В этом плане, там, вроде, все по-другому работает.