Laravel без ярко выраженной миграции баз данных?

Question

Я программист на PHP уже 12 лет и много раз изобретал колесо много раз, создавая свои собственные рамки для нашего веб-приложения с закрытым исходным кодом, которое предлагается в качестве размещенного решения, используя одну и ту же общую базу данных для всех клиентов.

Теперь я тестирую Laravel 5 и заметил, что почти каждый пример использует миграции Eloquent и базы данных. Мне кажется, что такие вещи ориентированы на простые базы данных и людей, которым не нравится SQL или дизайн базы данных (но я могу ошибаться).

Наша база данных MySQL содержит более 100 таблиц, множество хранимых процедур и множество триггеров, которые я просто не могу представить в ORM. Мы используем Navicat для разработки баз данных и тестирования SQL-запросов. Для обновления базы данных до более новой версии приложения мы уже писали несколько хороших сценариев и даже визуальные инструменты.

Так что, в основном, мой вопрос заключается в том, что Laravel действительно предназначен для использования с Eloquent и миграциями или что я действительно пропускаю много функциональности без них.

Что вы рекомендуете?

Answer 1

Его ДО вас,

Laravel миграция направлена ​​на сохранение версии базы данных (при использовании контроллера версии) также красноречивый предназначен для простого отображения отношения между таблицами для сложных ситуаций, как кратному Присоединяйтесь и все его не рекомендуется из-за проблема с производительностью, то вы можете выбрать Query Builder это дает гораздо более высокую производительность, Вам необходимо написать обычный запрос в Laravel использовать \DB::statement();

Laravel идеально подходят для угловых Js, более Laravel просто обертка несколько хороших компонентов PHP, который способный обеспечить быстрые результаты.

надеюсь, что это помогает ..

Answer 2

Использование ORM упрощает вашу жизнь, как наиболее распространенный сценарий являются уже охвачены. Получение данных, управление отношениями и нетерпевая/ленивая загрузка - это легкий ветерок. Он также защищает вас от любых уязвимостей инъекций, которые вы могли бы создать при написании собственных жестко запрограммированных запросов. Конечно, не все сценарии могут обрабатываться ORM, следовательно, возможность писать RAW-запросы. Использование Laravel-х Query Builder вы могли бы сделать что-то вроде этого:

$results = DB::select(DB::raw("SELECT * FROM users WHERE username = :username"), ['username' => 'johndoe']);

Если вы хотите, чтобы выполнить такие вещи, как ALTER или SET «s, то вы можете использовать DB::Statement.

Так что просто отметьте, Eloquent является ORM Laravel, а Query Builder - это слой для безопасного построения ваших запросов.

Нужно ли использовать Eloquent для вас, я считаю, что они хорошо там работали с твердой ORM, но вы всегда можете реализовать другую ORM, такую ​​как Doctrine, Data Mapper и т. Д. Есть Laravel привязки для большинства из них.

Edit: Стоит отметить также, что Eloquent модель предоставляет некоторые полезные дополнительные, которая также упрощает вещи, как JSON преобразования __toString, защищенные атрибуты, дату отливки и т.д. При получении нескольких моделей они будут храниться в Collection, a Arrayable, который обеспечивает еще больше методов для счастливых времен.Проверьте это: http://laravel.com/docs/5.1/eloquent-collections

Answer 3

Вы можете запускать простые SQL-запросы в Laravel, если хотите, но в большинстве примеров используется Eloquent.

Я делаю проект с более чем 100 таблицами, и в большинстве случаев можно использовать Eloquent вместо того, чтобы ставить необработанные SQL-запросы каждый раз, но это скорее мои предпочтения.

Однако вы упомянули, что у вас есть много хранимых процедур и триггеров в базе данных. Честно говоря, вы должны переосмыслить это, потому что теперь вы можете использовать большую бизнес-логику в базе данных, а ваша логика - как в базе данных, так и в приложении.

Я видел пару месяцев назад такую ​​базу данных в MsSQL, и это было ужасно - никто не знал, что происходит, и когда вы хотите перенести эту базу данных в MySQL и приложение Laravel, это была большая проблема, потому что было слишком много логики в база данных (я не принимал участие в этом проекте, только взглянул на нее)