Увійти Реєстрація
Блог Серії
Кар'єра
Вакансії Компанії
Навчання
Документація Співбесіди Тестування Відео
Екосистема
Пакети Ресурси Проєкти Інструменти Події
Інше
Про нас Реклама
Tips 02 березня 2026

Зупинка проблеми N+1 запитів

Сторінка завантажує 10 постів. База даних робить 101 запит.

1 запит для постів. 100 запитів для авторів. Класична проблема N+1.

Рішення: Eager Loading

Використання with() для завантаження зв'язків наперед. Один запит стає двома.

Порада: Laravel Debugbar показує всі запити. Спочатку встановити його.

Коли НЕ використовувати eager loading:

  • Насправді не потрібні дані зв'язків
  • При роботі з одним записом (немає циклу = немає N+1)
  • Зв'язок повертає величезні набори даних (може бути гірше за N+1)

Просунутий трюк:

Використовувати withCount() коли потрібна тільки кількість, а не повний зв'язок.

// ПОГАНО: 101 запит
$posts = Post::all();
foreach ($posts as $post) {
    echo $post->author->name; // Запит на кожен пост
}

// ДОБРЕ: 2 запити
$posts = Post::with('author')->get();
foreach ($posts as $post) {
    echo $post->author->name; // Без додаткових запитів
}

// Завантажити декілька зв'язків
$posts = Post::with(['author', 'comments', 'tags'])->get();

// Вкладені зв'язки
$posts = Post::with('comments.author')->get();

// Потрібна тільки кількість?
$posts = Post::withCount('comments')->get();
echo $posts[0]->comments_count; // Зв'язок не завантажений

Читати в документації

Коментарі

Увійдіть, щоб залишити коментар

Будьте першим, хто залишить коментар!

Інші поради

Tips 14 жовтня 2026

`prohibits` - взаємовиключна валідація

Користувач може платити карткою АБО PayPal. Не обома.

Писати кастомну логіку? Є вбудоване правило.

prohibits гарантує, що поле не може бути присутнім разом з іншим.

Коли корисно:

  • Взаємовиключні способи оплати
  • Або email, або телефон
  • Умовні обмеження полів

Схожі правила:

  • required_without — потрібно A, якщо B немає
  • required_with — потрібно A, якщо B є
  • prohibits — A забороняє B

Порада: комбінуйте з required_without для сценарію “або A, або B, але не обидва”.

public function rules()
{
  return [
    'card_number' => 'prohibits:paypal_email',
    'paypal_email' => 'prohibits:card_number',

    'email' => 'required_without:username|prohibits:username',
    'username' => 'required_without:email|prohibits:email',
  ];
}
Tips 12 жовтня 2026

`bail` - зупинити валідацію після першої помилки

У поля email 5 правил. Усі падають — користувач бачить 5 помилок.

Це плутає.

bail зупиняє валідацію поля на першій помилці.

Навіщо:

  • Кращий UX — по одній помилці
  • Продуктивність — не запускаємо дорогі перевірки
  • Чіткіші повідомлення

Як працює:

Додайте bail першим правилом для поля.

Порада: ставте перед дорогими правилами типу exists:, unique: або кастомними перевірками з API.

public function rules()
{
  return [
    'email' => 'bail|required|email|max:255|unique:users',
    'username' => [
      'bail',
      'required',
      'min:3',
      Rule::unique('users')->ignore($this->user),
      new CheckExternalAPI,
    ],
  ];
}
Tips 09 жовтня 2026

`prepareForValidation()` - чистимо дані до валідації

Телефон приходить як "(123) 456-7890", а в БД потрібен "1234567890".

Санітизація в контролері? Це вже запізно.

prepareForValidation() змінює дані запиту до запуску правил.

Коли корисно:

  • Нормалізація телефону
  • Прибирання пробілів
  • Конвертація типів
  • Додавання обчислюваних полів

Важливо:

Виконується до валідації — ідеально для нормалізації.

Порада: merge() додає/оновлює поля, replace() повністю замінює масив даних.

protected function prepareForValidation()
{
  $this->merge([
    'phone' => preg_replace('/[^0-9]/', '', $this->phone),
    'slug' => Str::slug($this->title),
    'price' => (float) $this->price,
    'name' => trim($this->name),
    'email' => strtolower(trim($this->email)),
  ]);
}
Tips 07 жовтня 2026

`exclude()` - прибираємо поля з валідованих даних

У формі є CSRF-токен та допоміжні поля. Ви не хочете, щоб вони потрапили у validated().

exclude_if, exclude_unless прибирають поля умовно.

Коли корисно:

  • Прибрати UI-only поля
  • Виключити поля залежно від ролі
  • Не логувати чутливі поля
  • Тримати валідовані дані “чистими”

Доступні правила:

  • exclude — завжди прибирає
  • exclude_if — прибирає, якщо умова істинна
  • exclude_unless — прибирає, якщо умова хибна
  • exclude_with — прибирає, якщо інше поле присутнє

Порада: краще за ручний unset() після валідації.

public function rules()
{
  return [
    'name' => 'required',
    'admin_notes' => 'exclude', // не потрапить у validated()
    'is_admin' => 'exclude_unless:user.role,admin',
    'card_number' => 'exclude_if:payment_method,cash',
    'paypal_email' => 'exclude_if:payment_method,card',
  ];
}
Tips 05 жовтня 2026

`after()` - хук валідації після проходження всіх правил

Треба перевірити комбінацію полів? Або пов’язані записи в БД?

Звичайні правила працюють незалежно. Хук after() запускається після того, як усі правила пройшли.

Коли корисно:

  • Валідація кількох полів разом
  • Перевірки в БД
  • Складна бізнес-логіка
  • Кастомні повідомлення помилок на основі кількох полів

Суть:

Callback отримує Validator. Помилки додаються вручну.

Порада: after() ідеальний для валідації, що залежить від кількох полів або запитів до БД.

public function withValidator($validator)
{
  $validator->after(function ($v) {
    if ($this->start_date > $this->end_date) {
      $v->errors()->add(
        'end_date',
        'Дата завершення має бути після початку.'
      );
    }

    $total = $this->quantity * $this->price;
    if ($total > 1000 && ! $this->has_approval) {
      $v->errors()->add(
        'has_approval',
        'Замовлення понад $1000 потребують підтвердження.'
      );
    }
  });
}
Завантаження...