※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1488033350.A.737.html
→ qrtt1: 『彈性』變動其實挺難掌握的，但也不是做不到。就是得花時 02/25 22:40
→ brucetu: 如果你要用關聯式資料庫那應該是每個欄位是一條record 一 02/25 22:40
→ brucetu: 個userDefineTable有多個userDefineColumn 02/25 22:40
→ qrtt1: 間，另一個更嚴重的問題是 scope 一直變，你到底想不想結案 02/25 22:40
→ qrtt1: 執行專案，如果無法明確有每一階段該達到的目標，又一直變 02/25 22:41
→ qrtt1: 更終止（或滿足條件）將沒有結束的一天。這到底是個經濟活 02/25 22:41
→ qrtt1: 動。還是你不在乎他能不能結案＠＠？ 02/25 22:41
→ brucetu: 而userDefineTable中每個cell就以他所在的column和rownum 02/25 22:43
→ brucetu: ber定位出來，這只是概念 效率很差 只記columnIndex不對u 02/25 22:43
→ brucetu: serDefineColumn關聯會更好，不過nosql也許更適合 02/25 22:43
→ brucetu: 我以為他講得是想刻一個google試算表的系統 抱歉手機推 02/25 22:45
→ brucetu: 沒注意到推文交錯了 哈哈 02/25 22:45
推 abc0922001: 給user亂搞，擦屁股的還是你XD 02/25 22:49
推 Masakiad: 怎麼聽起來像是一個烏托邦軟體？一個軟體要滿足所有根 02/25 23:20
→ Masakiad: 本不同的spec除非你包山包海包你全家，沒有在想到才加 02/25 23:20
→ Masakiad: 還可以無痛的 02/25 23:20
推 Kazimir: 我怎麼有點看不懂.. 不能只是table嗎? 02/25 23:23
推 vn509942: 前期需求分析+成本效益 卡實在 02/25 23:29
推 mdkn35: mongoDB是你的好選擇 02/25 23:33
推 felixgugu: 樓上正解 02/25 23:37
推 lovdkkkk: 存 Object 或物件轉 String 隨便你要多彈性都可以唷 :D 02/25 23:54
推 GoalBased: 我以為cms都是這樣做的... 02/25 23:54
→ y3k: mongo吧? 我記得可以 沒用過mysql的json 02/26 00:11
推 Kazimir: 如果彈性的意思是說要隨意改變schema 那該用mongo 02/26 00:26
→ Kazimir: 不過這個範例感覺起來RDB就行啦？ 02/26 00:26
推 ichico: CMS的確都是這樣做的，用key-value-pair的方式存取 02/26 09:23
→ ichico: 不是從改變schema著手而是從資料結構面 02/26 09:23
→ ichico: 或者是用xml，用Mongo/MSSQL 2016存json也是一種解法 02/26 09:24
推 shechiway: influxdb可能也符合需求 02/26 09:32
→ pttworld: 深入某一行業knowhow，把所有可能子項儲存，供組合用。 02/26 09:56
→ maxqq: 你確定你寫得完一堆物件嗎? 02/26 10:30
推 guest0710: 我想到excel跟google表單... 02/26 11:17
推 Beersheep: 原來可以用mongo 我之前也有想過類似的專案 02/26 11:31
推 asneo: 用MONGODB 02/26 13:56
推 mathrew: mongo 正解 02/26 17:30
推 lovdkkkk: 啊 上面的物件是指 Mongo mixed 的 JS 物件不是 JAVA 的 02/26 17:45
→ justben: 用GraphQL啊，你要做的是把所有的欄位列出來，接下來 02/26 18:08
→ justben: 讓使用者自己串就好惹,或者留一些可以自訂的欄位也行 02/26 18:09
推 Masakiad: 純存資料當然mongo或開補充用table就好，code可不能這 02/26 22:32
→ Masakiad: 樣搞啊！當a店要用gps做lbs的時候就不是欄位的問題，而 02/26 22:32
→ Masakiad: 是code也要實作。 02/26 22:32
推 plum2122: Mongo+1 不過自己心裡對於架構還是要有個底比較好 02/26 22:53
推 alog: 資料還好 倒是介面你會搞到最後事情做不完 02/27 03:36
→ alog: 先把規格談清楚再來談後續架構 看你感覺掉坑了 02/27 03:37
推 alog: 而事實上越多規格工錢越貴 所以你模擬的需求大概在客戶聽完 02/27 03:40
→ alog: 報價後突然就醒了 然後開始收斂天馬星空的想法 02/27 03:40
推 alog: 彈性有時候是真的去跑過實際需求後 02/27 03:41
→ alog: 客戶給你的經驗跟想法 然後你會找出一個答案 02/27 03:42
→ alog: 或是為了將系統販售給不同客戶時 你會有一些結構上的調整讓 02/27 03:42
→ alog: 他適用於每一個人 02/27 03:42
→ alog: （先註明：盡可能，並非都能通用 02/27 03:43
→ alog: 然後節省你的開發成本 02/27 03:43
→ alog: 而得出來的彈性設計 這要看你做什麼 02/27 03:44
→ alog: 我認為你目前提到的規格一般關聯資料庫就解決了 02/27 03:45
推 jerry771210: XML 02/27 17:42
推 jerry771210: HBase, mongo, redis, dynamo 很多都可以啊 02/27 17:45
推 cmcotton: mongo好用 02/28 20:26