Re: [請益] 這是個很低級的錯誤嗎？

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