作者newhandfun (新手方)
看板Soft_Job
标题Re: [请益] 这是个很低级的错误吗？
时间Wed May 15 18:51:12 2019
既然提到id这件事
没人带的本菜鸟就想借问一下相关的问题
可能也发生了很低能的错误
(PHP + MYSQL)
给大家笑笑
1.目前我手上的资料库大多数table都用mysql的auto increment int来当id。
然後
因为目前table间的relationships
都是用php去取
(laravel的ORM)
而不是用sql的foreign key
直接delete单一会让系统崩溃，网页500。
所以我在有可能要删除的table
都会加一个名为status的tinyinteger
来判断这笔资料是不是被删掉了
((想说日後可能可以做个资源回收桶之类的功能
目前公司没有人会直接删除资料
但如果之後有了
那我这种做法有什麽解套的方式吗？
==================
2.方才提到大部分是increment integer
事实上有一个table的id是char
而且更糟糕的是这个id还兼当名称使用
然後此id也被其他table用来建立关系
想请问各位大大
先前因为塞入的字串太大让这个id
溢位
导致使用php的ORM建立的relationships时
直接触发SQL Exception，让系统挂掉
最後直接在前後端都设定名称长度限制解决这个问题
除了这个情况之外
还有可能会遇到什麽问题?
是不是要想办法修改资料库的架构比较好
===================
3.最近公司想要做一个动态表单的功能
我发现MYSQL有json型态可以用
就大胆放心地把所有表单的内容全都塞到这个栏位中
测试下来没遇到什麽大问题
请问这个是合理的做法吗？
小的目前基本上是一人做前後端
毕业不满一年，所以还真很多东西不知道
拜托各位给个意见，面对日後越来越多人用我真心怕自己踩到什麽雷
-----
Sent from JPTT on my Asus ASUS_Z017DA.
--
※ 发信站: 批踢踢实业坊(ptt.cc), 来自: 223.136.119.119
※ 文章网址: https://webptt.com/cn.aspx?n=bbs/Soft_Job/M.1557917474.A.0F8.html
1F：推 stevekevin10: 1.这是设计问题，要马不要用ORM的关联不然就不要随 05/15 19:19
2F：→ stevekevin10: 意删资料，大型的系统建议都不要有FK 05/15 19:19
3F：→ stevekevin10: 2.建议pk就乖乖做pk的事情就好 05/15 19:20
4F：→ stevekevin10: 3.可能的问题在於你之後改表单json内容改变时，过去 05/15 19:21
5F：→ stevekevin10: 的资料跟新的资料用同一个逻辑层去跑可能会出错。 05/15 19:21
1.我该庆幸当初因为觉得fk在laravel不好管才不用吗哈哈
2.好的。之後另外写逻辑将其矫正过来
3.会用json的地方不多。且目前系统不打算让使用者更动旧的资料，所以还可以应付
谢谢您的建议
6F：推 ashlikewing: 没事不要用fk，用状态值记录删除是可以的，但是如果 05/15 19:36
7F：→ ashlikewing: 你的资料成长级数太快那最好评估一下这些留滞的资料 05/15 19:36
8F：→ ashlikewing: 比例有没有意义 ，表大是会影响效能的 05/15 19:36
效能问题之後可能会慢慢浮现。谢谢建议。
9F：推 localhost: 都用ajax最简单 05/15 19:38
10F：→ ashlikewing: 不确定MYSQL的json支不支援索引，如果你要拉里面的 05/15 19:39
11F：→ ashlikewing: 资料做join要小心 05/15 19:39
12F：推 zelda123: 1. Laravel 有支援 deleted_at 做 soft delete 05/15 22:15
目前预计整个系统仅有表单资料库与其格式的设定档的储存会是json,能不用我也不想再用，毕竟用起来没其他预设类别顺
13F：→ zelda123: 3. JSON 之後很难维护，不建议滥用 05/15 22:15
14F：推 pseudoman: 没事不用fk?资料库都不正规化吗@@ 05/15 22:49
15F：推 lemon651: 大型系统不用fk的话，那用关连式资料库的用意何在？ 05/15 23:52
16F：推 ashlikewing: 正规化和fk有什麽必要关系吗？没有fk就不能做了？ 05/16 00:30
18F：推 blackie1019: 大型资料库真的不要乱用与滥用FK，懂得就懂。不懂硬 05/16 01:12
19F：→ blackie1019: 要来学术派战文字的就对他笑笑就好 05/16 01:12
20F：推 yaya517: 看过很多大型CRM确实都没有在用FK的 05/16 07:15
21F：推 alan3100: soft delete是基本,join key是长字串在某些情况效能很差 05/16 07:23
好的。我会看看soft delete.
目前系统没啥用到join.日後有需求时会多注意
※ 编辑: newhandfun (223.136.119.119), 05/16/2019 08:31:00
※ 编辑: newhandfun (223.136.119.119), 05/16/2019 08:35:05
※ 编辑: newhandfun (223.136.119.119), 05/16/2019 08:37:57
※ 编辑: newhandfun (223.136.119.119), 05/16/2019 08:40:06
22F：→ silent5566: 大型系统不推荐设FK 表格间相关太多时会被FK制肘 05/16 10:46
23F：→ lwtech: 他挂掉的原因一定有Log,然後优化它 05/16 11:24
24F：→ lwtech: 通常都是人下错SQL,导致很慢,然後mySQL只能玩到GB级 05/16 11:27
谢谢您的数据。
之後如果有要储存大量资料，打算换成postgresSQL
※ 编辑: newhandfun (223.136.119.119), 05/16/2019 22:32:24
25F：→ lwtech: PSQL一样，高并发高可用高网路本来就是三个不一样的选择 05/16 23:26
26F：→ lwtech: 你要会db tunning 才重要，所以才会需要DBA 05/16 23:27
27F：推 Tony427: 正规化用久了，还会听过反正规化喔XD 05/28 17:57