Re: [请益] 这是个很低级的错误吗?

楼主: newhandfun (新手方)   2019-05-15 18:51:12
既然提到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型态可以用
就大胆放心地把所有表单的内容全都塞到这个字段中
测试下来没遇到什么大问题
请问这个是合理的做法吗?
小的目前基本上是一人做前后端
毕业不满一年,所以还真很多东西不知道
拜托各位给个意见,面对日后越来越多人用我真心怕自己踩到什么雷
作者: stevekevin10 (hippo泡)   2019-05-15 19:19:00
1.这是设计问题,要马不要用ORM的关联不然就不要随意删资料,大型的系统建议都不要有FK2.建议pk就乖乖做pk的事情就好3.可能的问题在于你之后改表单json内容改变时,过去的资料跟新的资料用同一个逻辑层去跑可能会出错。
作者: ashlikewing   2019-05-15 19:36:00
没事不要用fk,用状态值记录删除是可以的,但是如果你的资料成长级数太快那最好评估一下这些留滞的资料比例有没有意义 ,表大是会影响效能的
作者: localhost (127.0.0.1)   2019-05-15 19:38:00
都用ajax最简单
作者: ashlikewing   2019-05-15 19:39:00
不确定MYSQL的json支不支援索引,如果你要拉里面的资料做join要小心
作者: zelda123 (丸子)   2019-05-15 22:15:00
1. Laravel 有支援 deleted_at 做 soft delete3. JSON 之后很难维护,不建议滥用
作者: pseudoman (剑无锋)   2019-05-15 22:49:00
没事不用fk?数据库都不正规化吗@@
作者: lemon651 (小明)   2019-05-15 23:52:00
大型系统不用fk的话,那用关连式数据库的用意何在?
作者: ashlikewing   2019-05-16 00:30:00
正规化和fk有什么必要关系吗?没有fk就不能做了?这篇文章 http://bit.ly/2Ypz2o2 参考一下
作者: blackie1019 (blackie)   2019-05-16 01:12:00
大型数据库真的不要乱用与滥用FK,懂得就懂。不懂硬要来学术派战文字的就对他笑笑就好
作者: yaya517 (Abby)   2019-05-16 07:15:00
看过很多大型CRM确实都没有在用FK的
作者: alan3100 (BOSS)   2019-05-16 07:23:00
soft delete是基本,join key是长字串在某些情况效能很差
作者: silent5566 (沉默五六)   2019-05-16 10:46:00
大型系统不推荐设FK 表格间相关太多时会被FK制肘
作者: lwtech   2019-05-16 11:24:00
他挂掉的原因一定有Log,然后优化它通常都是人下错SQL,导致很慢,然后mySQL只能玩到GB级
作者: Tony427 (重新出发...fight!!)   2019-05-28 17:57:00
正规化用久了,还会听过反正规化喔XD

Links booklink

Contact Us: admin [ a t ] ucptt.com