若是全站用同一套使用者，那就是 users 表。若是前後台拆分，就是前台用 members, 後台用 managers(或是admins)但是我看英文的一些討論說完全沒必要拆分。但我被要求拆分。我的上級說，雖然可以透過欄位像是 is_admin 或是角色來區分，但是分開比較安全。有道理嗎？
members如果被某種方式取得，至少還不知道managers。疑問：如果能駭到 members, 不能順便把 managers 也駭到手？如果說不知道表名，隨便猜，managers, admins, users。如果被加上前綴、後綴，查 information_schema表也可以。如果說 information_schema 通常不開放給網站資料庫的帳號密碼，但我沒有收過這樣的規範。
我的表單送出後，都會去查找 information_schema 的表的欄位，例如訂單，就去查訂單表有哪些欄位。如果訂單的表單欄位 input name 跟訂單資料表的欄位一致，那就跑迴圈寫入。當然還要加上 fillable 判斷。像創建者、修改者、創建時間、修改時間，會略過。
如果說不開放 information_schema 給當前網站系統的資料庫連線帳號，那我的系統可能又要調整一番。蠻麻煩的。但我沒收到這個指示。
如果不管業務面，金主，案主什麼的，單純從程式技術、資訊安全來說，前後台使用者拆分，是否有必要？
前後台使用者我仍然有做關聯。其實我只被要求前後台使用者分開，資料表取什麼名稱是我自己定的。我這邊沒人懂 laravel (?! ) 我是這樣做，前台 members, 後台 managers, 然後用 users 做為全站共用的表，也只使用它的 id 欄位。然後另外兩個表都各有 user_id 欄位。這不就又統一了嗎 (呵呵)。只是帳號密碼是存在前後台各自的表。但是其它地方需要記錄哪個使用者，就可以用 users.id。例如訂單表 creator_id, modifier_id，我對應的是 users.id。
大家覺得呢
已邀請的邦友 {{ invite_list.length }}/5
完全沒道理，使用者的表沒有必要分開前後台，理由如下
現在反而還越來越多站台希望整合會員系統，將這部分功能抽離出來變成一個服務，使各站台可以使用同一個登入系統，減少使用者要記很多帳密的困擾。
我認為現在還特地將Admin另開表來儲存，實屬畫蛇添足的行為。
我猜主管是有遇到過 SQL injection，不是整個DB被攻破，而是單一表被抄走的狀況。
這在早期沒framework的時候應該還蠻常見的。
把權限、使用者都放在一張表的話，的確會有這種顧慮，但用laravel且都寫ORM的狀況下應該是不用擔心這個。
froce 有SQLi基本上就能把整個DB包走，是不是同張表其實沒有關係，多掃一下而已，他主管的顧慮確實是沒有意義，這種其實就是懂一點但不多的長官會有的顧慮
以下為ChatGPT的回答：user和admin帳號共用table優缺點為何?
共用同一個表來存儲user和admin帳號有其優點和缺點，根據具體應用場景可能會有不同的影響。以下是詳細的分析：
簡化設計
數據一致性
方便擴展
role），可以方便地擴展不同類型的用戶，而不需要修改數據庫結構。安全性挑戰
潛在性能問題
複雜性增加
共用一個表適合數據結構相似且數量不大、要求數據一致性高的應用場景。對於較大的系統或需要高度安全性和性能的場景，可能需要考慮將不同類型的用戶存儲在不同的表中，以便更好地管理和優化。
最終選擇應該根據具體的應用需求、數據量、性能要求以及開發團隊的技術能力來決定。
要談資安, 應該先盤點:你的利害關係人有哪些?
而不是一下就跳到資料庫要用甚麼表去...例如:
為什麼? 因為資安是花錢的事情, 他帶來的拖累通常大於效益;
如果這是連利害關係人都不關心的事情, 你就不需要花成本去處理他.
對員工而言:
你有沒有獨立隔離的前後台? 他完全不關心, 只要速度快好用就好
對主管機關而言:
你有沒有獨立隔離的前後台? 影響的是:
萬一出事情的話, 他對你施以行政罰的力度要多大?
有獨立前後台的被害(駭)廠商, 你可以辯解:
我真的很用心在關注資安! 前後台都投入了很多的時間與人力, 把他們獨立隔開了, 就是為了在萬一出事的時候, 能夠將受到影響的範圍縮到最小, 這些措施, 足以證明我們不但非常重視資安, 而且也採取了更嚴謹的態度, 來設計整體架構; 雖然不幸, 我們仍然遭到入侵, 但我們事前已經盡到最大努力來防止!....
沒有獨立前後台的被害(駭)廠商, 你只能辯解:
........反正被駭了也都是全部被拿走啊? 我們覺得這樣比較方便, 所以就放在一起...
資安事件民事賠償, 在法院的裁定是很吃心證的 (因為客觀證據幾乎很難取得或保存, 即便有, 也很難被法官客觀評價), 你覺得上面哪一種講法, 會讓法官形成對你有利的心證?
members和admin拆不拆分「資料表」其實沒有太大差別
真要拆的話
就拆成在經由不同防火牆、不同網段的兩部不同的伺服器(資料庫)上面
這樣更為安全
其實更為重要的是
你的「訂單資料」在那一台伺服器上面？
與其在乎member/admin帳號
應該先確保訂單資料的安全性吧？
帳號被駭大不了全部作廢重建
訂單資料被駭就大件事了
如果不管業務面，金主，案主什麼的，單純從程式技術、資訊安全來說，前後台使用者拆分，是否有必要？
以程式技術來說確實沒有那麼必要，但以資訊安全來說分開是會好一些，因為以後您們可以視資安需求將後台管理者的Table移到另一台安全性更高的獨立DB，彈性大一些。
我能理解您主管的想法，相信他應該沒必要也不想跟您吵這些問題，因為工程師可以不管業務面，金主，案主什麼的，他卻不能不管，互相理解一下。
在職場相遇就是緣份（當然不一定是好的緣份，我們會稱之為逆增上緣），主管若有特別提出需求就作吧，反正工程師加班是常態，多這個需求也不過是多加幾個小時班，畢竟整個案子的成敗他要負責的～～這次您幫他，下次他幫您，多麼和諧快樂的工作環境呀～～
是沒人懂laravel ，還是沒人懂你寫的laravel 
要你做啥你就做啥，不爽幹掉他升主管自己去溝通阿
還是分個表都不會做?
這種東西也要上來問
iThome鐵人賽
看影片追技術