为什么 php 的框架(Laravel、ThinkPHP)都不是在模型处统一定义数据库字段？
gamexg · 2016-04-10 11:06:09 +08:00 · 5259 次点击这是一个创建于 3150 天前的主题，其中的信息可能已经有所发展或是发生改变。
原来用 python+django ，现在正在学习 php+Laravel 。
一个地方想不明白， Laravel 为什么不像 django 一样统一在模型处定义数据库结构，而自动生成迁移脚本？
目前 Laravel 需要手写迁移及撤销迁移的变更。多次迁移后，想知道当前数据库结构只能查看多次的迁移记录或者去数据库查看当前的数据库结构了。如果将字段定义放到模型里面能清楚知道当前代码需要的数据库结构了，迁移及撤销迁移脚本是能自动生成的。
目前外键关系即需要在迁移脚本里面指定，还需要在模型里面指定，而且模型里面还需要指定两次，很奇怪的做法...
ThinkPHP 和 Laravel 都是一样的做法，在模型里面定义字段是不是有什么坑？如果没有坑的话 Laravel 有没有计划将字段定义移动到模型里面？是不是已经有开源插件实现了自动生成迁移了？
第 1 条附言 · 2016-04-10 16:07:04 +08:00
主要是觉得麻烦，一个外键变更需要分别在迁移、撤销迁移、两个模型处做 4 次修改...
想问一下是不是已经有现存的插件可以解决这个问题。
Laravel 在哪里提 issue ？很奇怪 github 未提供 issue 功能...
想问一下是不是已经有现存的插件可以解决这个问题。
Laravel 在哪里提 issue ？很奇怪 github 未提供 issue 功能...
第 2 条附言 · 2016-04-10 17:58:54 +08:00
好吧，我说一下希望达到的效果：
1.再增加一个新的模型类型，这个新的模型定义里面需要写上这个模型包含的字段(数据库结构)，每个字段的类型，是否建立索引等内容。
增加一个命令，运行后会自动的根据新的模型生成原来的模型(包括外键之类的东西)及迁移脚本。
生成原来的模型没什么麻烦。
主要是生成迁移脚本麻烦些，如果不考虑导入之前的迁移脚本，那么可以完全仿 django 来实现，保存每次的变更历史，然后每次生成迁移脚本时读取之前的变更历史来获得之前的数据库结构，和当前的数据库模型作比较即可获得模型的变更，根据变更生成迁移脚本即可。
当然实际上肯定会碰到一些坑。而且 Laravel 本身迁移功能已经实现了多种数据库的底层支持，应该不用再去适配各种数据库了。
1.再增加一个新的模型类型，这个新的模型定义里面需要写上这个模型包含的字段(数据库结构)，每个字段的类型，是否建立索引等内容。
增加一个命令，运行后会自动的根据新的模型生成原来的模型(包括外键之类的东西)及迁移脚本。
生成原来的模型没什么麻烦。
主要是生成迁移脚本麻烦些，如果不考虑导入之前的迁移脚本，那么可以完全仿 django 来实现，保存每次的变更历史，然后每次生成迁移脚本时读取之前的变更历史来获得之前的数据库结构，和当前的数据库模型作比较即可获得模型的变更，根据变更生成迁移脚本即可。
当然实际上肯定会碰到一些坑。而且 Laravel 本身迁移功能已经实现了多种数据库的底层支持，应该不用再去适配各种数据库了。
 |
1
chareice 2016-04-10 11:11:38 +08:00
Laravel 实现的是 Active record pattern 。
|
 |
2
gamexg OP >一个地方想不明白， Laravel 为什么不像 django 一样统一在模型处定义数据库结构，而自动生成迁移脚本？
更正 一个地方想不明白， Laravel 为什么不像 django 一样统一在模型处定义数据库结构，自动生成迁移脚本？ @chareice 我之前说的不太明白。主要意思是为什么是手工写迁移、撤销迁移代码，手工写外键查询方法(而且两个相关表都需要分别写一个方法)，运行时生成当前模型，代码里面没有当前数据库结构，想看当前的数据库结构只能去数据库查看。 而不是手工定义模型字段，自动生成迁移、外键查询方法，代码内可以统一的管理当前的数据库结构呢？至少我感觉统一管理模型字段更好些。 |
 |
3
tabris17 2016-04-10 11:48:07 +08:00
反正我设计系统都是数据库结构驱动的，先设计表结构在写模型，反过来不习惯
|
 |
4
whatisnew 2016-04-10 11:56:42 +08:00
migration 是个优点，多个平台的时候，数据库结构发生变化时， git pull 然后 auto migration 就好了，秒杀鸡
|
|
5
whatisnew 2016-04-10 11:57:05 +08:00
错了。。。是多人开发时
|
 |
6
chloerei 2016-04-10 12:05:56 +08:00
自动生成迁移是怎么处理数据迁移的？
|
 |
7
overtrue 2016-04-10 12:20:01 +08:00
php 语法的原因，如果说在模型里定义了字段属性，那么 ORM 的一些特性就无法实现了，比如 getXXXAttribute/setXXXAttribute ，文档译作“属性读取器与修改器”，还有一些其它特性都是依赖于 php 的魔术方法实现的。所以这应该是语言层面决定的吧。
|
 |
9
realpg 2016-04-10 12:24:48 +08:00
什么都得像 django ？或者说什么框架都得像你觉得好的语言框架？不是人参攻击，我觉得是病得治
|
|
10
gamexg OP @whatisnew 数据库结构直接保存到模型里面， pull 后不需要 auto migration ，检出代码后直接看模型代码，里面就是代码当前版本的数据库结构。不需要手写迁移脚本，修改模型后直接执行 manage.py makemigrations app 会自动根据模型字段的变化自动生成迁移脚本。提交代码时同时将迁移脚本一起提交，部署时和现在一样执行迁移脚本即可完成数据迁移。
@chareice django 模型里面包含了字段定义，修改了字段定义后执行 manage.py makemigrations app 会自动生成迁移脚本。没看代码，猜测是比较将当前模型字段和迁移脚本比较，找出变更后根据变更生成迁移脚本。提交代码时同时将模型字段和迁移脚本一起提交，实际部署时和 Laravel 一样需要执行迁移命令。 主要好处是打开模型代码就能看到代码当前版本的数据库结构，而不需要在开发环境下执行数据库迁移，然后再到数据库查看当前代码的数据库结构。 而且外键关联也可以根据模型字段自动生成，不需要在迁移里面写一份，在模型里面再写一份。 我主要是想问一下是不是已经有第三方实现了？ 还没开始写项目，看 Laravel 文档就觉得麻烦，一个外键变更分别需要在迁移、撤销迁移、两个模型处做 4 次修改... |
|
11
gamexg OP |
 |
12
audi 2016-04-10 12:58:53 +08:00 via iPhone
你可以看看 symfony 嘛
|
|
14
chareice 2016-04-10 13:03:31 +08:00
@gamexg 在 Rails 中有一个 schema.rb 文件，会自动记录当前数据库版本和结构， Laravel 好像并没有这个，所以在 Laravel 中要观察数据库的结构，还是得到数据库里看。。
|
 |
15
darasion 2016-04-10 13:45:29 +08:00
然并卵。
很多实际需求的变化和扭曲使得你根本用不到如此多高大上的特性。 |
 |
16
Magician 2016-04-10 15:42:35 +08:00 via iPhone
Laravel 怪我咯。
|
 |
17
msg7086 2016-04-10 16:22:40 +08:00
如果两个 PHP 系统要访问同一个数据库或者数据表怎么办？你迁移到底跑哪边的。
PS: 你要 DRY 你得试试原厂 Ruby on Rails 。别家怎么说都是移植，把一个框架从高灵活性语言移植到低灵活性语言，总会丢掉一些灵活性的。 |
|
18
realpg 2016-04-10 16:50:52 +08:00
|
 |
19
wanghanlin 2016-04-10 16:50:57 +08:00  1
Laravel 提 issue 去 laravel/framework ，不在 laravel/laravel
|
|
20
gamexg OP @msg7086 多个 php 系统之类的不是主要问题，这种情况关闭一个系统相关表的迁移即可。
迁移功能是本来就有的，我只是希望能自动生成迁移脚本。 刚刚看了一下 Ruby on Rails ，每次迁移会将数据库最新结构保存到 db/schema.rb ，能清楚知道当前版本代码的数据库结构。而 Laravel 想知道当前代码的数据库结构需要应用所有迁移后再到数据库查看结构，感觉好坑啊... 我新学 Laravel ，来这里问这个问题是想看看是不是已经有解决方案了。 |
 |
21
xujif 2016-04-10 17:09:28 +08:00
|
|
22
wanghanlin 2016-04-10 17:14:05 +08:00
@gamexg 不是所有数据库都有对应模型的，也不是所有模型都有一个数据库， Laravel 可以处理多个模型对应同一个表。
|
|
23
xujif 2016-04-10 17:15:06 +08:00
@gamexg 另外 laravel 没有约定模型目录，只要符合 autoload 就可以使用模型，原则上 laravel 并不知道你有多少模型，放在哪里，所以没有第三方的库帮你生成模型文件。
php 是不能申明成员类型，所以 eloquent 不知道 relation 类型，也不能自动帮你生成外键。 |
 |
24
xuwenmang 2016-04-10 17:24:03 +08:00
Migrations 用 Schema 类来定义、管理数据表的版本。
Eloquent ORM 使用类来操作表，传说中的增删改查。 两个不一样的事儿，搞在一起干嘛？ |
|
25
gamexg OP @realpg 共用的表当然只有一个所有者开启迁移(也就一个选项的事)，手写迁移脚本的时候也不会在多个项目里面都写迁移脚本啊。数据结构也一样，原来就也需要每个项目里面都写模型的外键关联，原来多个项目共享模型的外键关联现在一样共享。
|
|
26
gamexg OP |
|
27
xujif 2016-04-10 17:46:26 +08:00
@gamexg php 应该没办法做到 code first ，或者说 laravel 没办法做到（因为没有约定 model 目录）,忍吧。
不过 migration 确实不是用来做这个的。 migration 的好处是强制程序员声明数据库更改，可以回溯数据库修改。协作开发的时候如果涉及数据库修改会很方便，出错了也可以回滚。 |
|
28
realpg 2016-04-10 17:49:05 +08:00 1
@gamexg
建议去大厂核心数据看看。非要说 PHP 的话，有代表性的比如鹅厂的 BQQ 相关，数据库结构，设计，查询审计都是 DBA 的活，程序层可以访问完整结构去查询，但是每个查询都要审计。 很多业务，数据库是亘古不变就存在的，而 webapp 则是满地跑。 我并不支持 php 的这种类 ror 设计，我觉得 django 这种方便，但是什么都要设计成这种就有点强制洗脑了。 |
 |
29
ichou 2016-04-10 18:47:29 +08:00
也许你可以试一下 mongodb ，这样你就没有 migration 的困扰了 😂😂😂
|
 |
31
mcfog 2016-04-10 21:51:40 +08:00
竟然没人提 doctrine 😂
|
 |
32
Chrics 2016-04-10 22:26:17 +08:00
因为自由
|
 |
33
neoblackcap 2016-04-10 23:13:00 +08:00
@chloerei 明明你这么熟 RoR 你就不要这样子嘛，楼主的意思就是生成 migration 文件的意思，这个迁移文件当然只是一个手脚架，不含数据迁移的过程嘛。
|
|
34
msg7086 2016-04-11 01:12:35 +08:00
|
|
35
xujif 2016-04-11 11:19:30 +08:00
@ty0716 这个初衷就是开发自建本地数据库，而不是大家连一个公共数据库。测试的时候重新 migration and seed 如果直接修改本地数据库，提交测试上去,如果数据库不一致，则测试必然失败，不允许发布。
|
|
38
neoblackcap 2016-04-11 13:19:40 +08:00
@msg7086 但题主明显就不是想要手写的 mirgation 嘛，仅机器生成的又不可能做到数据迁移嘛。
|
Select Language