既然提到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要小心
1. Laravel 有支援 deleted_at 做 soft delete3. JSON 之後很難維護，不建議濫用
大型系統不用fk的話，那用關連式資料庫的用意何在？
大型資料庫真的不要亂用與濫用FK，懂得就懂。不懂硬要來學術派戰文字的就對他笑笑就好
作者:
yaya517 (Abby)
2019-05-16 07:15:00看過很多大型CRM確實都沒有在用FK的
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