В 2018 мигрировать на yii2 для сколько-нибудь серьезного приложения странно, минимум на yii3.
А так выглядит, что люди, которые умеют пользоваться только молотком, на все смотрят как на гвозди.
Как по мне, SQL vs ORM некорректное сравнение у своего основания.
sql — это язык, ORM — это оверхэд над sql, как большинство языков это оверхэд над процессором.
Задача ORM — абстрагироваться от базы данных. Каждый объект ОRM служит определенной цели в бизнес-логике. Мы перестаем думать о базе данных в принципе, а начинаем мыслить объектом и целью для которой он создан.
Так, например, мы знаем, что пользователь может иметь несколько адресов для доставки товара, может указать предпочитаемый цвет дилдо, иметь адрес банка, который в свою очередь может у нескольких пользователей, а сам банк может иметь несколько почтовых индексов. Соответственно мы создаем таблицы для данных, а ответственность за целостность данных и выборку мы возлагаем на ORM.
Так что бы получить всех пользователей которые привязаны к одному банку мы сделаем, что-то вроде: $banks = $user->getBanks()->getUsers();
Получить адреса банка пользователя: $banksAddr = $user->getBanks()->getAddrs();
Теперь мы хотим, чтобы пользователь мог, что-то заказать с сайта, если у него указан хотя бы один банк:
if($user->hasBanks()){}
Так же, в каждый момент времени мы должны быть уверены, что кто-то не допишет sql, который уберет нам половину данных или наоборот запишет в базу потеряв в половину.
Или кто-то добавил обязательное поле в таблицу, чтобы все запросы работали корректно, нам нужно поправить 1 entity class и все запросы продолжат работать.
Всю ответственность за целостность данных берет на себя берет ORM.
Так в пример с книгами это было бы
class Book
{
/**
* @ORM\ManyToMany(targetEntity="Author", inversedBy="books", fetch="EXTRA_LAZY")
* @ORM\JoinTable(name="books_author")
*/
private $authors;
}
class Author
{
/**
* @ORM\ManyToMany(targetEntity="Book", mappedBy="authors")
*/
private $books;
}
Теперь мы можем получить для книги всех ее авторов, а для автора — книги
У стандартных методов типа findAll и т.д., похоже, нет способа указать, что мне надо только такие-то поля и сразу приджойнить такие-то таблицы.
Результат findAll — не отдаст вам автором и собственно не должен, вы же книги хотите получить. Но при этом доктрина в любой момент времени знает, где этих авторов взять, если спросить у нее.
Если нужно получить получить информацию одним запросом, то используем EntityRepository.
class BooksRepository extends EntityRepository
{
public function getBooksWithAuthors ()
{
$result = $this->createQueryBuilder('u')
->select('u, a')
->leftJoin('u.authors', 'a')
->getQuery()
->getResult();
return $result;
}
}
Уточню, что authors — ManyToMany связь для Books и entity класс для книг создан правильно, а не так как в примере.
class BooksController
{
$doctrine = $this->getDoctrine();
$books = $doctrine->getRepository(Books::class)->getBooksWithAuthors();
}
И получаем все в одном запросе. Книги с их авторами.
Пожалуйста, нет, не надо так
А так выглядит, что люди, которые умеют пользоваться только молотком, на все смотрят как на гвозди.
Сказали люди и поставили Битрикс
Спасибо!
sql — это язык, ORM — это оверхэд над sql, как большинство языков это оверхэд над процессором.
Задача ORM — абстрагироваться от базы данных. Каждый объект ОRM служит определенной цели в бизнес-логике. Мы перестаем думать о базе данных в принципе, а начинаем мыслить объектом и целью для которой он создан.
Так, например, мы знаем, что пользователь может иметь несколько адресов для доставки товара, может указать предпочитаемый цвет дилдо, иметь адрес банка, который в свою очередь может у нескольких пользователей, а сам банк может иметь несколько почтовых индексов. Соответственно мы создаем таблицы для данных, а ответственность за целостность данных и выборку мы возлагаем на ORM.
Так что бы получить всех пользователей которые привязаны к одному банку мы сделаем, что-то вроде: $banks = $user->getBanks()->getUsers();
Получить адреса банка пользователя: $banksAddr = $user->getBanks()->getAddrs();
Теперь мы хотим, чтобы пользователь мог, что-то заказать с сайта, если у него указан хотя бы один банк:
Так же, в каждый момент времени мы должны быть уверены, что кто-то не допишет sql, который уберет нам половину данных или наоборот запишет в базу потеряв в половину.
Или кто-то добавил обязательное поле в таблицу, чтобы все запросы работали корректно, нам нужно поправить 1 entity class и все запросы продолжат работать.
Всю ответственность за целостность данных берет на себя берет ORM.
Так в пример с книгами это было бы
Теперь мы можем получить для книги всех ее авторов, а для автора — книги
А чтобы сохранить книгу мы должны обязательно иметь связь хотя бы с одним автором.
Вот так, например
Результат findAll — не отдаст вам автором и собственно не должен, вы же книги хотите получить. Но при этом доктрина в любой момент времени знает, где этих авторов взять, если спросить у нее.
Если нужно получить получить информацию одним запросом, то используем EntityRepository.
Уточню, что authors — ManyToMany связь для Books и entity класс для книг создан правильно, а не так как в примере.
И получаем все в одном запросе. Книги с их авторами.
Я бы посмотрел.
Есть РЖД в портфеле?
Вселенная Стивена Хокинга
Кратчайшая история времени
И можно еще посмотреть, тоже ок
Во Вселенную со Стивеном Хокингом
Космос: Пространство и время
Сквозь червоточину с Морганом Фрименом
Всё — яд, всё — лекарство; то и другое определяет доза (с)
Ну, точно, а у него тьфутьфу жена умерда, давайте наполмним ему об этом.
Профессиональные качества — это профессиональные, а личные — это личные.