Schema::create Vs Sql - laravel

I am new with Laravel and started my personal project.
Laravel provide migrations for creating schema for our databases. I have difficulties on implementation choice. The ideas I have are:
Create database schema using Illuminate\Support\Facades\Facade\Schema provided by Laravel, for example:
Schema::create('users', function (Blueprint $table) {
$table->increments('id');
$table->string('username',300)->unique();
$table->string('email',300)->unique();
$table->string('password',100);
})
Create schema using ERD Designer like Mysql Workbench, export the diagram to sql and finally execute the sql in Laravel using DB::statement
I'm trying to google which method is better, but no answer satisfy me.
Which methods is the better or commonly used in industry? If you have any other suggestion I'm happy to know it.

Laravel Schema is an abstraction and, for the most, database indipendent, that is, if there is already a grammar in the laravel source or in an external library you can use the same migrations with different Database Engines with minor issues.
If you use Raw SQL you could, in case, depend on the actual Database Engine you use.
Laravel ships with these grammars: MySQL, PostgreSQL, SQLite and SQLServer.
If you use the build-in Schema you can use the same migrations in any of the databe engines above without worry too much about the actual SQL implementation.
Consider that many developers have a local dev environment with a simple database engine like SQLite, and sometimes when they start a project they don't even know the database engine that will be used in production. Think about the case you want to change hosting provider or you have a demo project on a cheap provider and the production elsewhere.

Related

Developer sandboxes for Oracle database

We are developing a large data migration from Oracle DB (12c) to another system with SSIS. The developers are using a production copy database but the problem is that, due to the complexity of the data transformation, we have to do things in stages by preprocessing data into intermediate helper tables which are then used further downstream. The problem is that all developers are using the same database and screw each other up by running things simultaneously. Does Oracle DB offer anything in terms of developer sandboxing? We could build a mechanism to handle this (e.g. have dev ID in the helper tables, then query views that map to the dev), but I'd much rather use built-in functionality. Could I use Oracle Multitenant for this?
We ended up producing a master subset database of select schemas/tables through some fairly elaborate PL/SQL, then made several copies of this master schema so each dev has his/her own sandbox (as Alex suggested). We could have used Oracle Data Masking and Subsetting but it's too expensive. Another option for creating the subset database wouldn have been to use Jailer. I should note that we didn't have a need to mask any sensitive data.
Note. I would think this a fairly common problem so if new tools and solutions arise, please post them here as answers.

Laravel Migrations - keep them forever? What is best practice?

I have been working with Laravel for about a couple of months now - loving it. Have a question about the workflow that is recommended for managing changes to the database.
I have a test database that I used to develop my app, and when I was reasonably happy, I created a production database by copying the structure in phpMyAdmin. I had built the initial database on phpMyAdmin, as I was not familiar with the Laravel Migrations.
Now I am at a point where I better understand the power of Laravel Migrations, and would like to use them going forward to update the test database and move those changes to the production.
What is the course of action for me? Can I delete everything in the app/database/migrations dir and start from scratch? Will there be issues down the line calling php artisan migrate in my test and production environment?
Thanks in advance for the responses!
Short answer: no problems. If you just add/alter/remove tables/columns in the up() and down() methods.
Longer answer: still no problem. As long as you don't drop a table that is not created in an up() method.
But let's say you get to work with another developer, that person also wants to develop on a local DB. But you don't have the migration for it - so the new dev needs to run the initial structure from test DB, and then apply the new migrations.
In that case I would start with 1 big migration where you create all the initial tables, and in the down() the drops of those tables, so the new dev can just run the migrate and start coding.
edit: and after that migration for the initial structure, just add new ones while developing ;)

Laravel Migration Advantages

I am new to using Laravel, and I'm currently learning about Laravel's database migration and seeding features.
It's working with the command prompt, but I can migrate and seed in phpMyAdmin as well. What are the advantages and disadvantages of migrating and seeding within Laravel as opposed to phpMyAdmin?
From Laravel docs on Migrations & Seeding:
Migrations are a type of version control for your database. They allow a team to modify the database schema and stay up to date on the current schema state.
A simple search for why database migration also gives me some pretty decent results. One of the easiest to understand is a page by FlywayDB (I have no idea who they are until I search this term up):
Database migrations are a great way to regain control of this mess. They allow you to:
Recreate a database from scratch
Make it clear at all times what state a database is in
Migrate in a deterministic way from your current version of the database to a newer one
The illustration they made perhaps explain it more clearly, so you may want to check it out.

What is being used for migrations with martini?

I'm trying to learn martini, coming from Rails. What's being used for database migrations in the martini world?
There is no such thing in martini. It is just a helper for writing web services. If you want database migrations, or a database at all, use third-party packages.
An example tool stack would be:
goose for creating migrations
gorp for a database object layer
This or a completely different setup, e.g. using Go's standard database package, can be used with martini.

Migrations from database

I have created the schema through MySQL Workbench and synchronized it with the database.
All the tables are there in database. Now when I use the
php artisan migrate
command, is there an option to take the fields director from the database instead of specifying the fields name.
Also could you please suggest any other tools on github.
Laravel Migrations Generator will help us generate migration source code from existed database in Laravel 4.
so if you already have your sql schema, created in mysql workbench, then you'd need to put that schema into laravel migrations using the schema builder.
there are tools that make this part easier:
http://www.laravelsd.com/ - kinda like mysql workbench, with an export possibility to laravel migration code
https://github.com/XCMer/larry-four-generator writes existing databases to laravel migration code
Another option is to use our tool Skipper (https://www.skipper18.com) We introduced Laravel support a month ago and now, in a beta phase, it is free for Laraver users.
Skipper allows you to import your MySQL Workbench project directly (or it is possible to import existing database too) and then export migrations and object files from Skipper to your Laravel project.
The benefit of this solution is that you can maintain your ORM schema directly in Skipper and continuously update model object files and create new migrations automatically from the application without the necessity to write any code manually.
If you want to try it, you can download it here https://www.skipper18.com/en/download, and in the initial application license screen select "Laravel Beta license".

Resources