[請益] 適合動態修改schema的db

看板Soft_Job (軟體人)作者 (500年沒換暱稱了)時間9年前 (2017/02/25 22:35), 編輯推噓24(24033)
留言57則, 24人參與, 最新討論串1/2 (看更多)
自己想做一個小專案,目的是能根據不同的需求動態建立db schema ex: A子想建立一個跟餐廳有關的db,欄位有 名稱、地址、電話 隔天,A子又要建立另一個db是關於帳務的,欄位有 日期、金額、類別 B子也想建立自己的餐廳db,但是欄位 除了 名稱、地址、電話,還想有GPS 所以要讓user自己決定db schema 目前作法是一個db裡面先放相對應的schema name -> schema 之後要操作的時候就知道怎麼做 但是這個作法code/db看起來會很混亂 不知道有沒有更好的作法?或是有適合這種需求的db? 如果能直接方便動態挑戰schema更好 是不是nosql會比較適合呢? 謝謝大家~ -- ※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 111.249.227.79 ※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1488033350.A.737.html

02/25 22:40, , 1F
『彈性』變動其實挺難掌握的,但也不是做不到。就是得花時
02/25 22:40, 1F

02/25 22:40, , 2F
如果你要用關聯式資料庫那應該是每個欄位是一條record 一
02/25 22:40, 2F

02/25 22:40, , 3F
個userDefineTable有多個userDefineColumn
02/25 22:40, 3F

02/25 22:40, , 4F
間,另一個更嚴重的問題是 scope 一直變,你到底想不想結案
02/25 22:40, 4F

02/25 22:41, , 5F
執行專案,如果無法明確有每一階段該達到的目標,又一直變
02/25 22:41, 5F

02/25 22:41, , 6F
更終止(或滿足條件)將沒有結束的一天。這到底是個經濟活
02/25 22:41, 6F

02/25 22:41, , 7F
動。還是你不在乎他能不能結案@@?
02/25 22:41, 7F

02/25 22:43, , 8F
而userDefineTable中每個cell就以他所在的column和rownum
02/25 22:43, 8F

02/25 22:43, , 9F
ber定位出來,這只是概念 效率很差 只記columnIndex不對u
02/25 22:43, 9F

02/25 22:43, , 10F
serDefineColumn關聯會更好,不過nosql也許更適合
02/25 22:43, 10F

02/25 22:45, , 11F
我以為他講得是想刻一個google試算表的系統 抱歉手機推
02/25 22:45, 11F

02/25 22:45, , 12F
沒注意到推文交錯了 哈哈
02/25 22:45, 12F

02/25 22:49, , 13F
給user亂搞,擦屁股的還是你XD
02/25 22:49, 13F

02/25 23:20, , 14F
怎麼聽起來像是一個烏托邦軟體?一個軟體要滿足所有根
02/25 23:20, 14F

02/25 23:20, , 15F
本不同的spec除非你包山包海包你全家,沒有在想到才加
02/25 23:20, 15F

02/25 23:20, , 16F
還可以無痛的
02/25 23:20, 16F

02/25 23:23, , 17F
我怎麼有點看不懂.. 不能只是table嗎?
02/25 23:23, 17F

02/25 23:29, , 18F
前期需求分析+成本效益 卡實在
02/25 23:29, 18F

02/25 23:33, , 19F
mongoDB是你的好選擇
02/25 23:33, 19F

02/25 23:37, , 20F
樓上正解
02/25 23:37, 20F

02/25 23:54, , 21F
存 Object 或物件轉 String 隨便你要多彈性都可以唷 :D
02/25 23:54, 21F

02/25 23:54, , 22F
我以為cms都是這樣做的...
02/25 23:54, 22F

02/26 00:11, , 23F
mongo吧? 我記得可以 沒用過mysql的json
02/26 00:11, 23F

02/26 00:26, , 24F
如果彈性的意思是說要隨意改變schema 那該用mongo
02/26 00:26, 24F

02/26 00:26, , 25F
不過這個範例感覺起來RDB就行啦?
02/26 00:26, 25F

02/26 09:23, , 26F
CMS的確都是這樣做的,用key-value-pair的方式存取
02/26 09:23, 26F

02/26 09:23, , 27F
不是從改變schema著手而是從資料結構面
02/26 09:23, 27F

02/26 09:24, , 28F
或者是用xml,用Mongo/MSSQL 2016存json也是一種解法
02/26 09:24, 28F

02/26 09:32, , 29F
influxdb可能也符合需求
02/26 09:32, 29F

02/26 09:56, , 30F
深入某一行業knowhow,把所有可能子項儲存,供組合用。
02/26 09:56, 30F

02/26 10:30, , 31F
你確定你寫得完一堆物件嗎?
02/26 10:30, 31F

02/26 11:17, , 32F
我想到excel跟google表單...
02/26 11:17, 32F

02/26 11:31, , 33F
原來可以用mongo 我之前也有想過類似的專案
02/26 11:31, 33F

02/26 13:56, , 34F
用MONGODB
02/26 13:56, 34F

02/26 17:30, , 35F
mongo 正解
02/26 17:30, 35F

02/26 17:45, , 36F
啊 上面的物件是指 Mongo mixed 的 JS 物件不是 JAVA 的
02/26 17:45, 36F

02/26 18:08, , 37F
用GraphQL啊,你要做的是把所有的欄位列出來,接下來
02/26 18:08, 37F

02/26 18:09, , 38F
讓使用者自己串就好惹,或者留一些可以自訂的欄位也行
02/26 18:09, 38F

02/26 22:32, , 39F
純存資料當然mongo或開補充用table就好,code可不能這
02/26 22:32, 39F

02/26 22:32, , 40F
樣搞啊!當a店要用gps做lbs的時候就不是欄位的問題,而
02/26 22:32, 40F

02/26 22:32, , 41F
是code也要實作。
02/26 22:32, 41F

02/26 22:53, , 42F
Mongo+1 不過自己心裡對於架構還是要有個底比較好
02/26 22:53, 42F

02/27 03:36, , 43F
資料還好 倒是介面你會搞到最後事情做不完
02/27 03:36, 43F

02/27 03:37, , 44F
先把規格談清楚再來談後續架構 看你感覺掉坑了
02/27 03:37, 44F

02/27 03:40, , 45F
而事實上越多規格工錢越貴 所以你模擬的需求大概在客戶聽完
02/27 03:40, 45F

02/27 03:40, , 46F
報價後突然就醒了 然後開始收斂天馬星空的想法
02/27 03:40, 46F

02/27 03:41, , 47F
彈性有時候是真的去跑過實際需求後
02/27 03:41, 47F

02/27 03:42, , 48F
客戶給你的經驗跟想法 然後你會找出一個答案
02/27 03:42, 48F

02/27 03:42, , 49F
或是為了將系統販售給不同客戶時 你會有一些結構上的調整讓
02/27 03:42, 49F

02/27 03:42, , 50F
他適用於每一個人
02/27 03:42, 50F

02/27 03:43, , 51F
(先註明:盡可能,並非都能通用
02/27 03:43, 51F

02/27 03:43, , 52F
然後節省你的開發成本
02/27 03:43, 52F

02/27 03:44, , 53F
而得出來的彈性設計 這要看你做什麼
02/27 03:44, 53F

02/27 03:45, , 54F
我認為你目前提到的規格一般關聯資料庫就解決了
02/27 03:45, 54F

02/27 17:42, , 55F
XML
02/27 17:42, 55F

02/27 17:45, , 56F
HBase, mongo, redis, dynamo 很多都可以啊
02/27 17:45, 56F

02/28 20:26, , 57F
mongo好用
02/28 20:26, 57F
文章代碼(AID): #1OiPP6St (Soft_Job)
文章代碼(AID): #1OiPP6St (Soft_Job)