推 stevekevin10: 1.這是設計問題,要馬不要用ORM的關聯不然就不要隨 05/15 19:19
→ stevekevin10: 意删資料,大型的系統建議都不要有FK 05/15 19:19
→ stevekevin10: 2.建議pk就乖乖做pk的事情就好 05/15 19:20
→ stevekevin10: 3.可能的問題在於你之後改表單json內容改變時,過去 05/15 19:21
→ stevekevin10: 的資料跟新的資料用同一個邏輯層去跑可能會出錯。 05/15 19:21
1.我該慶幸當初因為覺得fk在laravel不好管才不用嗎哈哈
2.好的。之後另外寫邏輯將其矯正過來
3.會用json的地方不多。且目前系統不打算讓使用者更動舊的資料,所以還可以應付
謝謝您的建議
推 ashlikewing: 沒事不要用fk,用狀態值記錄刪除是可以的,但是如果 05/15 19:36
→ ashlikewing: 你的資料成長級數太快那最好評估一下這些留滯的資料 05/15 19:36
→ ashlikewing: 比例有沒有意義 ,表大是會影響效能的 05/15 19:36
效能問題之後可能會慢慢浮現。謝謝建議。
推 localhost: 都用ajax最簡單 05/15 19:38
→ ashlikewing: 不確定MYSQL的json支不支援索引,如果你要拉裡面的 05/15 19:39
→ ashlikewing: 資料做join要小心 05/15 19:39
推 zelda123: 1. Laravel 有支援 deleted_at 做 soft delete 05/15 22:15
目前預計整個系統僅有表單資料庫與其格式的設定檔的儲存會是json,能不用我也不想再用,畢竟用起來沒其他預設類別順
→ zelda123: 3. JSON 之後很難維護,不建議濫用 05/15 22:15
推 pseudoman: 沒事不用fk?資料庫都不正規化嗎@@ 05/15 22:49
推 lemon651: 大型系統不用fk的話,那用關連式資料庫的用意何在? 05/15 23:52
推 ashlikewing: 正規化和fk有什麼必要關係嗎?沒有fk就不能做了? 05/16 00:30
推 blackie1019: 大型資料庫真的不要亂用與濫用FK,懂得就懂。不懂硬 05/16 01:12
→ blackie1019: 要來學術派戰文字的就對他笑笑就好 05/16 01:12
推 yaya517: 看過很多大型CRM確實都沒有在用FK的 05/16 07:15
推 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
→ silent5566: 大型系統不推薦設FK 表格間相關太多時會被FK制肘 05/16 10:46
→ lwtech: 他掛掉的原因一定有Log,然後優化它 05/16 11:24
→ lwtech: 通常都是人下錯SQL,導致很慢,然後mySQL只能玩到GB級 05/16 11:27
謝謝您的數據。
之後如果有要儲存大量資料,打算換成postgresSQL
※ 編輯: newhandfun (223.136.119.119), 05/16/2019 22:32:24
→ lwtech: PSQL一樣,高併發高可用高網路本來就是三個不一樣的選擇 05/16 23:26
→ lwtech: 你要會db tunning 才重要,所以才會需要DBA 05/16 23:27
推 Tony427: 正規化用久了,還會聽過反正規化喔XD 05/28 17:57