laravel中的命名公约规范及relation N+1问题

  User: model  ;  users: 表名; user_id 键值

relation: public function tasks(){return $this->belongsToMany(‘Task‘,‘task_id‘);}

  Task: model名; tasks:表名; task_id  键值

relation: public function ower(){return $this->belongsToMany(‘User‘,‘user_id‘);} //注意:默认情况下如果不指定键字段,则会使用owner_id作为键

$user = User::first();

$user->tasks()->attach(2); 将会对relation执行操作

Task::where(‘title‘,‘LIKE‘,"%$searchdata%")->get()   全文搜索

在laravel relation操作中,如果对有多条数据的行,执行relation关系表运算,则由于会多次查询数据库,将严重影响系统性能。比如,一个可行的方法是 eager oading.

比如上述关系中,如果有10个user,分别要显示

@foreach($tasks as $task)

<li><strong>{{$task->owner->name}}</strong> 有以下任务{{$task->title}}</li>

@endforeach

可以将PHP代码稍微改进一次性获取数据集后传入blade模版,

$tasks  = Task::with(‘owner‘)->get();  通过这一句话的修改,laravel访问数据库将减少为1次,而不是11次!!(N+1问题)

时间: 2024-10-29 21:53:54

laravel中的命名公约规范及relation N+1问题的相关文章

CSS那些事!这个篇幅是我特意开的,不是因为帮助小菜之类的,而是在多人的团队配合中各种命名冲突的规范让人蛋疼

CSS那些事!这个篇幅是我特意开的,不是因为帮助小菜之类的,而是在多人的团队配合中各种命名冲突的规范让人蛋疼. css这个东西只要不是新的离谱都会写,但是每个人的命名风格,方法,都不同 有人喜欢驼峰,有人觉得-不错,有的人觉得_很方便,最后有的英文命名,有的干脆拼音....囧 http://www.cnblogs.com/LoveOrHate/category/682181.html 然后没有统一的格式,造成的结果...我爆炸了... 当然经常和团队合作的也就不用看了 这些文章我是专门找啊找,找

iOS开发(OC)中的命名规范

开小差:最近发现自己有一个经验主义的毛病,不太容易接受新的知识,这对从事技术研发的人来说不太合理,需要改之. 正文:通过读写大量代码我有自己的一套编程思路和习惯,自认为自己的编码习惯还是不错的,代码结构也算清晰,因为我一直以来都是代码看的多写的多,但是总结的比较少,知识经常不成体系.以后多花点时间把自己的经验和学习知识加以总结一下吧,这样有利于去指导新人,也更有利于加深自己的知识认知.今天就从代码规范入手总结一下iOS开发中好的编码规范吧.我们在开发中看别人的代码的时候经常会去抱怨至少内心里骂娘

如何在 Laravel 中 “规范” 的开发验证码发送功能

什么是ThinkSNS ? ThinkSNS(简称TS),一款全平台综合性社交系统,为国内外大中小企业和创业者提供社会化软件研发及技术解决方案,目前最新版本为ThinkSNS+(简称TS+).ThinkSNS V4.ThinkSNS[简]. 需求场景 发送「验证码」或者「消息通知」,可发送到手机或邮箱中. 完成 首先,在Laravel中的规范就是使用Laravel的「消息通知」,这里基于场景为「验证码」.这个需求几乎所有软件系统都有使用到. 创建通知场景 第一步,使用php artisan ma

CSS命名规则规范整理

转载声明:原载:彬Go本文链接:http://blog.bingo929.com/css-coding-semantic-naming.html 在此,非常感谢该文章作者的分享,本文完全转载自上面链接,此处作为备份,方便查看使用. CSS命名规则规范整理 大家在写css的时候,经常会遇到关于命名的问题.页面上成百甚至上千的class或者id,我们就会越来越感到困扰. 所以,这样我们就很有必要整理自己的一套命名规范.这里我就说说我自己的命 大家在写css的时候,经常会遇到关于命名的问题.页面上成百

总结前端开发中的一些特殊规范

前端日子工作太忙没时间发随笔,现在来总结一些前端开发中的特殊规范(常规的规范就不赘述了),希望能让各位收益,也欢迎提出异议. 一. 文件系统 一个有条理的文件系统可以为后期的维护提供便利,起码寻找某个页面的某张图片时不用对着url地址顺藤摸瓜找半天,如果能做到不看url也能准确猜中某页面文件的所在地,那这个文件系统便是合格的. 先来看一个不合格的文件存放方式: 如上图,该目录下共有2个css文件夹.2个js文件夹以及3个存放图片的文件夹(“dyp2p”文件夹里也是放置图片的),同时还有许多人经常

Laravel中路由怎么写(二)

1.路由命名——给路由起个名字 1.1 基本使用 我们使用as关键字来为路由命名: Route::get('/hello/Laravel',['as'=>'academy',function(){ return 'Hello Laravel!'; }]); 路由命名可以让我们在使用route函数生成指向该路由的URL或者生成跳转到该路由的重定向链接时更加方便: Route::get('/testNamedRoute',function(){ return route('academy'); })

如何在Laravel中加密大文件?

Empcat的成功软件包应采用Laravel设计.用户可以上传任何大小的文件.出于安全原因,必须静态加密这些文件. Laravel提供加密,但是它们主要用于加密值.它使用加密的帮助程序方法很好地加密了小文件,例如图像,但是在此过程中,必须将文件的内容加载到内存中,这对于大文件是个问题. 我寻找了解决此问题的软件包或解决方案?找到了此Stack Overflow的答案?此PHP解决方案,它基本上是Stack Overflow中描述的解决方案的PHP. 我决定为Laravel创建一个扩展包,该扩展包

软件开发中的命名规则

对于一个成功的软件项目来说,大到解决方案小到一个属性的命名,不管是对软件的开发,还是对于后期的维护来说都是非常重要的.经过多年的摸索,我发现自己有一点命名恐惧症.为了方便以后的工作的顺利进行,特别对项目开发中的命名进行了一次总结,尽管有些地方不是很完整或者不周,但以后还会进行不断的补充与完善! 1. 解决方案命名:    对于解决方案来说,它的命名一般相对比较固定,多是系统英文全名的简写,如:SPMS,RMG,FinCap等: 2. 项目命名:    项目的命名要体现项目的功能,一般分为2/3/

前端基础01-布局中所遵循的规范或是通例

布局中所遵循的规范或是通例 一般是遵循从上到下,从左到右的一个顺序.就从页面的稳定性上来说,优先考虑使用标准流,其次才考虑浮动或是定位. 遵循标准流的元素中,又以宽高最稳定,先把大的框架实例化出来,再进行细节的布局.能用padding的优先考虑padding(内边距),其实才考虑margin(外边距).如果没有margin的边距合并或是共享的问题话,也是可以比较愉快的使用margin的. 我们网页的布局其实就像是在搭积木.将一块块的盒子组合在一块,使其呈现一个漂亮的页面效果.Html中任何一个元