laravel migration係咪唔應該係production用?

3ldk

其他language的ORM, 一般都係寫好Model, 然後ORM會有function根據MODEL create db
例如:
https://hackersandslackers.com/m ... h-flask-sqlalchemy/

可能因為php的特性, php做唔到依種功能, 所以寫PHP, 唔配合DDL無辦法做開發


最近學習laravel, 竟然發現php都做到類似其他language的ORM功能

但係laravel做得比較奇怪, 一開始create一個唔完善的, 然後後面加好多個file去完善, 仲要每個table獨立一組file, 一個中小project隨時3-40個table, 每個table改兩三次, 隨時整超過100個migration file出黎

正常其他ORM/DDL, 都只會改最初既source, 好似laravel咁將同一個table既Definition分散係咁多個file入面, 唔明有咩好處

網上一般講法係話可以控制DB既版本, 但係, 如果DB改左, program部份一樣要改新版先可以配合到, 所以將一般既ORM Model/DDL放入git, 一樣可以控制版本, 所以控制版本唔係幾講得通

而且用左migration, 效果低好多. 正常table加一個col, 只要打開Model/DDL, 係相關位置copy一行, 改個名就得. 但laravel要打command add一個加col的php, 再係入面的up同down加入相關function, 相差既時間唔只一兩倍

最後就係production交貨, 傳統上交Model/DDL算合理, 如果無寫docs, 淨係依兩樣都可以當作一定程度既docs, 但係睇migration file就會好難睇

所以migration係咪預你只在development果陣用, 交貨時係咪應該重新寫個DDL用黎裝機?

二師兄

個人認為 migration 係一樣須要有但唔係必用O既野, 要真係用好花時間.

hihihi123hk

其他language的ORM, 一般都係寫好Model, 然後ORM會有function根據MODEL create db
例如:


可能因為php的特 ...
3ldk 發表於 2019-9-12 15:55

要實踐一啲好嘅 Practice 一定要花啲力氣

跟足 Laravel 咁做可以做到
* Single Source of Truth
* Reproducible

更改 DB Schema 永遠由 Coding 控制（Single Source of Truth)，唔會可以允許人手衝入去 phpMyAdmin 改

改 DB Schema 嘅 Code 有 Version Control, DB Schema 變成一個  Derived state , 就算用 Git Checkout 番去某個古老 Commit 都一定 Derived 到當日個 DB Schema

用得 Lavaral 嗰套方案就唔好再再人手撩 DB，唔係嘅話只會仲亂咗

最簡單一個諗法，假設你有 5 個場

Dev, Staging, UAT, Pre-production, Production

如果用人手改嘅方法，每個場都改一次？

當然你得一個場，同時得你一個人/幾個人做 Development，可以唔洗理咁多呢啲「為咗解決 CoWorking 而產生嘅問題」嘅 Software Engineering Practice

人手衝入去改一定係最快

真係需要理解到呢個設計個價值，可能係你需要每一個 Feature 都有各自一個場（成套獨立 Deployment)，而每個 Feature 都有人各自開發緊，同時 4-5 個 Feature 並行，做好就無痛 Merge 埋一齊上 UAT

via HKEPC IR Extreme 4.2.1 - iOS(4.0.1)