重复使用的 key 就用一个变数存起来吧.重复使用$k 的方式可避免手残输入了神奇的文字.

回覆量可以刷.很难分辨有效量
收藏量大致上准.
浏览量受到机器人影响.大致也准.

我个人的图片网站有做的:
个人图台使用的是参观者都给予惟一 hash.都入后就将该用户 hash 整合在一起.
记录每一张图片在画面上"完整呈现"时的秒数.

分析:
被收藏的图片完整呈现多久被搜藏.延伸题目:马上搜藏跟看很久才收藏的意义.
观看多久算是用户挂网.并排除.
收藏后再次被使用率.
用户回文是否灌水.用户是否有效.
发文者特性比例分析.
回文者特性比例分析.
搜藏者特性比例分析.

此图台利益与使用者利益交叉点.也就是这网站要赚钱又让用户不讨厌或是更喜欢的方法.
如何吸引用户将本网站推荐给他人.

基本上这本来就是一个很复杂的题目.
只能尽可能的收集用户的行为.
在去分析这真的是否有趣.
排序意义不大.

CTRL,WSAD....左邊定位完成...
上下左右....右邊定位完成.....
...........好像暗示了什麼.......

安装 proccess lasso
https://bitsum.com/

安装过程有中文可选.
安装过程选开机自动启动.不要手动.

装好之后开启.有个主控画面.有点像你的图片这样的资源管理介面.
上排选单 点 选项->预设 IO 优先顺序. 出现对话框.
对话框 的 程序名称 填入 "*" . 右边的优先顺序 选 "高于标准(高)" 然后点 "加入选单".

解释:
预设每 2 秒就对所有的执行中程式设定优先顺序.
可设定 CPU 和 IO.
记忆体优先顺序不懂别改.
然后防毒软体或是全家桶是有设计自己的优先权不可被改变的.
所以你只要将所有的程式 IO 优先权比防毒软体 /全家桶还高.就不会卡了....

备注
"加入选单" 这个列表. 假设如下
1 abc.exe 低于标准(低)
2 aabc.exe 高于标准(高)
然后你有一个 aaabc.exe
然后他开始套用.因为第一个规则已经符合.所以会被设定为 低于标准

规则列表 是 任意其中一串名称 符合 就套用.支持"*"任意字 .默认你输入的字串两边都有"*"
所以第一个规则是 "*" 的话 后面的规则都将失效.直接套第一个规则.

所以像是 HomeGroupListener 和 HomeGroupProvider 这样的服务.应该在列表前面用 "极低" .
后面才是 "*" 高于标准(高).

"极高"不要随便用.因为会互相咬死.

要是没有防毒软体或全家桶.其实全部都是 "低于标准(低)" 或是 "极低" 是比较不卡的.

任意直线距离,大部分常规资料库都一样快阿.
还以为是在问以道路为准的.

如果是在一个路网内.依照交通和道路状况.计算出两点之间最短交通路径.这个才是比较需要考虑图论资料库或是有特殊要化的.

补充 JPEG 格式
https://zh.wikipedia.org/zh-cn/JPEG
YUV
https://zh.wikipedia.org/zh-cn/YUV

建议参数是
Q75~85.
YUV420(颜色解析度较低.预设值) 或是 YUV444(颜色解析度跟 Y 一样)
float(慢速编码但品质优). 如果 CPU 不够力用 int(预设的整数编码)
YYYYUUUUVVVV.(每层的黑白灰优先).

如果是 JPG 就可以用贱招.
首先你只要存原始尺寸图片.但一定要是 JPG 渐进式格式.存档品质不要超过 85 比较好.这个 php 本身就有支援.
然后重点.输出的时候用串流输出. 意思就是 php 读取图片用串流(BYTE)的.不要解读图片
然后 php 控制输出也是串流的.但输出多少要自己控制.
例如你只要 4 分之 1 的大小=长宽减半的大小.
你就先取得整个档案的大小.计算 4 分之一的档案长度.
然后串流输出的时候.到达 4 分之 1 的输出后.直接截断.关闭串流.
用户端需要稍微用 html 控制一下.直接指定显示的长宽.
因为实际上你输出的还是原始尺寸.
而对方收到的图片清晰度却没有达到全部.但一定超过 4 分之一的需求.
所以看不出有问题.但计算消耗只有第一次的存档.输出频宽消耗也只有 4 分之 1.
验证方法是随便产出一些 渐进式品质 75~85 的 JPG 图片.直接用档案切割软体或是 16 进制的编辑软体截断档案.
然后将截断的前面用看图软体打开.
用 4 分之一大小看基本上没问题.但用原始尺寸看就可以看到破损.
有研究 JPEG 格式就知道.渐进式的话.他有一个一个的段落.每个段落都会让图片慢慢清晰.而且后面的不存在也没关系.只是解码会终止.但可以正常显示前面.
如果有搭配 imagemagick 或类似的软体存档.可以给他更多参数.

例如黑白灰(YUV 的亮度 Y)正确性比彩色(UV 部分)重要.下参数让 Y 全部在前然后才是 UV.
他就会变成 YYYYUUUUVVVV(第一层.最模糊) YYYYUUUUVVVV (第 2 层某一块.是第 1 层的局部补正) YYYYUUUUVVVV (第 2 层某一块.是第一层的局部补正) YYYYUUUUVVVV (第 3 层某一块.是第 2 层的局部补正) YYYYUUUUVVVV (第 3 层某一块.是第 2 层的局部补正) .....直到最后一层.

如过颜色比较重要那就下参数让 YUV 混合.就变成 YUVYUVYUVYUV(第 1 层) YUVYUVYUVYUVYUVYUVYUVYUV(第 2 层)....以此类推.

每一层有几块是编码器决定的.而且还分算数二进算法或是金字塔算法.所以不好计算你要的尺寸要切到哪一层.干脆直接截断.
金字塔算法是预设的因为效率更高但较复杂难预测. 算数二进比较简单.可预测但档案较大.

以上就是不换设备但有高解析度到低解析度需求的解决方案.
缺点是用户很喜欢你的图片存下来看原图他会翻白眼.因为截断的瑕疵就会露出来.
这里的补充解法是. 图片旁边写 JS 下载语法.
参考范例(繁)
http://www.ladesign.tw/paper/info/jquery_html2canvas_download
他是按照标签产图.你就选图片的那个标签名称就可以.他会产生"用户看见"的大小的图片.
等于是用户浏览器自己重新编码一个图片了.大小比用户看见的小一些(我也不懂原因哈哈哈).
但是不会有破图瑕疵.

以上是我的自建图床解.

gentoo:每周升级最新版路过.....
当然玩绷的次数也不少就是了.

7H.没午休

脾气变差了,懒得解释了.
听到"有空修电脑 /电视 /写个简单的网页 /app/软体吗" 想弄死那人.连听他解释都懒.

那个题目本身就有问题,何不问问某情况下,你会用什么方法解决,
所以出题的也许只是学院派?
打野出身没什么,学院派只会讲的比会写得多很多.
建议找个想法先做小产品或是小 DEMO.
拿这些(半)成品去面试投履历可能比较有机会,

像我都不问新同事这些的,
我都先问有那些(半)成品,先看看然后直接问他某部分的实作,
尤其是该部分我推测有很多种实作方法的.还会问他为何不用 XX 作法,
然后根据对方实作的选择跟理由评估这个新人到底是能信任的同事还是不能期待的.

最讨厌一直问排序法的,一堆现成的库 /包 /框架不问有没有听过,找过,用过,在那里问学院问题,听到火大.

资工的自学叛逆分子留.

@ryd994
恩恩,理想上就是上头给一个不再大更动的规格书,或是自己写一份规格书,上头确认后,技术人员开始实作.

但这几年的工作经验,全都是技术 /文书人员工作量超载的情况,
然后部分厂商就算拿到规格书,也会有规格外的要求在期中会议或内测过程被提出修改,
我在会议上一边录音一边草草的记下要修改的内容,回去忙着写 code,没什么时间写规格书给自己看.
而且先写规格书没用,我上头没有懂技术的,
上头只想看漂漂亮亮的图表,而我又不是职业前端,做图表很丑,所以常常就是看成果 @o@.
而期末需要缴交的架构图,xmind 画一份各类用户逻辑图(但我不说没人看得出那是 xmind 了,手工大改非自动拉线),资料库软体拉出资料库结构与关联图,就当作有写了.
不得不说我的文档有瑕疵,但重点是过去跟我合作的其他人是否能从我的文档了解整个案子的目标与意图.并且成功实作或是接手.
接口名称在白板讨论 /xmind 的中文意图讨论没有问题后就会标上.所以也算是先文档后实作了.

这里要小小抱怨一下,技术人员不够用的时候,不懂资讯的文书人员没办法帮技术人员写文档或产架构图,而技术人员会在做两次跟做一次的选择中优先选做一次(再次被殴)然后有剩下时间才写文档.

我第一篇回文就有说明每个人的经历不同会有很多不同的结论.我觉得这篇大家的答案都没有什么错.我在这里用其他人的角度再次检查自己过去几年的行为是否是当时我能做的最好选择.

所以我标记自己(被殴)(奔逃)原因就是我没办法全按照标准来作业,但我能做到当时时间与实作的极限平衡就这样了.

放轻松~~慢慢思考~~感觉大家有点急躁~~

外键连发两篇 XDDD 另一篇传送们
https://www.v2ex.com/t/322370#reply111

我觉得一起看超有意思 XDDDDD

再补充一个,
我有用过外键关联但可以 null 的设定,其实子表该值不存在也是可以动的.
从这个现象我特意去验证了外键关联到底是否有省下空间,答案是没有.
所以主表 /子表的外键关联栏位值在两边都存在,所以非数字栏位做外键关联根本空间吃超多.

所以对我来说外键对于减少资料错误率没有想的那么好,但设定与验证时间确实比较多,
但我系统架构文件也很懒得写,直接叫出资料库建模软体的架构生成图含注解就当有写了(被殴
所以设定与验证=写说明文件(奔逃

@ryd994 @ralphxlx @ljk @jjx @nandaye

补充一个我没放弃外键的原因.而且是因为这事情导致我过去 7 年的工作始终做好外键的原因...

7 年前我第一个算稳定的纯软开发工作.专案管理员(PM)给了我一个网站跟资料库.说明整体目标与目标用户之后.让我试着融入工作团队（ 40 人左右）工作.

但显然我很失败.PM 说我可以询问任何人.但每个人身上几乎都超过 4 个案子.所以其实大家都很忙.
而且以前没有这样的团队经验.不知道如何开口.所以我只好拿着 PM 给我的东西研究...

拿着资复制出来的料库一打开.....超过 40 个表.只有用户表跟权限表有关联外键.其他的表都没有.
这里简单说一下.这是一个特有(保育)生物的调查与纪录网站.涵盖了 GIS/动植物 /生态环境 /人...我的意思是.他比一般商业网站还复杂很多.应该比进销存还复杂一点吧.

重点是...没有说明 没有说明 没有任何说明 ....重点要说 3 次.

所以我告诉 PM 这样我没办法.太难了.做过这个案子的只剩两个人.一个前端一个全端.可是他们也很忙.
PM 说那我就去当驻点吧.

然后我就当了 4 个月的驻点.然后就换工作了...直接变成该案的老板的助理.然后重新设计者个系统(与厂商平行作业)

总之.这 4 个月充满痛苦的经验.让我一摸到资料库软体或是一听到系统建模.
我的手就无法阻止的点上了外键设定.还有每个表每个栏位写满了注解.因为很多软体可以从外键设定生出清楚的架构图.
而且对后面来的同事,或是到校合作教学生,我都会说"把外键做上去,每一栏都写中文注解".

资料库性能问题,我们可以业务与资料库主机分离,可以换 SSD,可以用 RAMDISK,可以主从模式,
但只有"没有关联没有注解没有说明档"修复的代价最痛.

一次受害终身受用.共勉.

@ralphxlx
你注意看这串讨论大多数人,不在资料库内设定外键关联.也省去连带变动 /连带删除设定,然后就直接 JOIN 直接查.

这样直到性能有问题.变成直接将要关联的 N 个表作一个初步过滤后.直接读到 N 个变数中.
(这时候资料库出输出已经完工.以下与资料库几乎无关)
然后用程式码写关联,或是放入自订类,或是放入泛形容器(模板).
然后再把关联后的查询在程式码中做.
然后输出结果,或是依照结果存入修改到资料库内的每个变动 N 表.

以上完全没做外键.
所以做外健目标是什么?我认为是强关系约束 /连带变动 /连带删除.

但在资料库设计初期.可能你还没做完关联设定.上头就传了讯息要你改一下新设计.搞不好连整个表都要重新设计.这时候资料库建模者就会满肚子表.甚至就不想设外键等设定了.

设计中期.开始要丢测试数据了.结果关联子表没资料不行.所以写入程式码就要补上先写入子表后写入主表等复杂语句.还会遇到一个问题.整个写入是有问题的.你要保留已经写入的子表资料还是删除?
一个一个删除.你要写的语句就不会少.不然就加上交易(Begin Transaction).出问题就 Rollback.没问题就 Commit.语句是变少了.但交易的性能下降你要先了解.

设计后期或业务更动时.更可怕了.你可能要先复制一个测试用库最好保留全部资料.然后开始加入新表.设定外键等.然后删改旧表..并跑完所有业务流程模拟与性能测试(简单说就是搜集过去用户输入大约 N 万笔.从 WEB 端丢入动态网页开始跑.看跑多久.跟旧的比差多少.个别增删查改耗时统计).
然后才写成 SQL 档去更新主资料库架构(同时更新业务逻辑代码).

到这里.我们看看.外键给了我们什么?一点点的好处
跟一堆麻烦.还有性能下降.还有水平扩展困难.
外键有帮我们省下空间吗?没有.

所以大部分工作一段时间的资料库工作者.不会使用外键.而是在业务逻辑代码中处理资料库.

我没有放弃外键.我很喜欢建模初期就设定上去.因为可以很清楚的从关连线了解资料库架构.
而正式上机使用时.除非已经遇到性能或其他问题.我不会主动去掉外键.

或是.一开始了解用户需求后.发现太多标准资料库不好做的设计(例如 POE 的技能网系统).就直接用 图论 /json 资料库 设计.
例如 arangoDB.

没抛弃过,但如果不用外键甚至不用拆表我就满足了性能,体积,设计复杂度.我何必用外键?
应该说,我何必用传统标准资料库?

例如 TokuDB,这是 Mysql 体系可选用的一个核心.本身是列式仓储.具有资料本身就是索引,结构本身就是有压缩的树状仓储.用了它,很多拆表的意义就没了.没有拆表何来外键?

例如 XML/json 文档式资料库.保持了包含关系也不需要序列号,每份文档的位置都已经代表他自己.或是每个 KEY 跟 VALUE 在资料库底层都已经有他自己的唯一值了.
而且文档资料库还解决了相同目标栏位不同内容物的问题,

标准资料库如果相同栏位要放不同子表的内容,设计上你会想死.
如果唯一键不是数字,又要给该表一个序列号,这样有比较省吗?各方面大都没有.

将标准资料库 /nosql 资料库一起比较关联查询,为什么这样说?因为就是有需求阿,尤其初期就没考虑到的东西突然发现要查他们关联后的条件查询结果.尤其是其中有些表没有序列号了,关联的值就是用文字.

那时候都有性能一样低下的问题.....一样低下的结果,那又何必分有拆表没拆表?有序列号没序列号?

用过更好的解决办法,你还会回头用标准资料库或是放弃更好的非标准资料库吗?

以上工作实务经验,依照每个人经验不同应该会有不同的解答,以上纯分享.

我觉得会搜寻的比会算法的更重要.
不会搜寻.整个自己搞.最高水平就是自身状况了.
会搜寻.你会得到这个世界前 10 优解.