摘要: ?
最近在遇到一個客戶的POC的問題,其中經(jīng)歷諸多有意思的事情, 有必要記錄一下，以作為后續(xù)創(chuàng)業(yè)所要避免的地方。文章來源地址http://www.zghlxwxcb.cn/news/detail-466965.html
客戶POC出現(xiàn)的問題:
- 查詢SQL中, 存在給查詢到的列屬性賦值的情況
- 給屬性的賦值的數(shù)據(jù)類型，和列屬性的數(shù)據(jù)類型，不匹配，比如給整形的屬性賦值字符串
- 在所做的項目中，數(shù)據(jù)庫對于查詢，從myql/sql層，到列引擎層, 有一次的查詢語法樹的轉(zhuǎn)換
- 在最開始暴漏出的問題中, 存在union all場景下無法賦值，但是在union場景下卻能賦值
- 對于union all的場景, 已經(jīng)被解決，解決方案也比較簡單，重點在于找到數(shù)據(jù)類型不一致的地方，然后使用要賦值的類型，做一次數(shù)據(jù)類型的轉(zhuǎn)換
- 到此為止，唯一遺留的, 便是加上order by之后, 導(dǎo)致查詢結(jié)果出錯
- 對于order by, 此時是對temp table做處理, 在昨晚排序之后，會將元組進行一次給sender的傳遞, 此時存在拿列屬性的操作, 而此時, 僅僅是依據(jù)列的屬性做取值, 而沒有考慮到給列賦值的數(shù)據(jù)的類型
- 通過以上的分析, 可以發(fā)現(xiàn)最麻煩的并不是具體的修復(fù)，而是找到列屬性和給列賦值的值的相關(guān)信息，這要考慮到對于查詢語法樹本身的結(jié)構(gòu)
在解決過程中的問題
一. 技術(shù)團隊中的拖延現(xiàn)象大大出乎我的意料
- 此處如果僅僅歸因于態(tài)度問題，是無法解釋的
- 更多的，是做這事情的人的能力問題，具體可以理解為:
- 對現(xiàn)有代碼的熟悉程度
- 對問題的敏感度, 也就是從現(xiàn)象關(guān)聯(lián)到代碼的能力
二. 能力問題
- 此處再次提出能力問題, 就不僅僅是對代碼熟悉本身了
- 此處也包括從現(xiàn)有信息做出更快決策，以及從他人身上學(xué)習(xí)的能力
- 考慮到我已經(jīng)將問題的重點給出，依然是徘徊，那么就必須理解為此人無法從他人身上學(xué)習(xí)
- 由于無法從他人身上學(xué)習(xí)，那么就必須從零開始做摸索，導(dǎo)致大量的耗時在摸索上
文章來源：http://www.zghlxwxcb.cn/news/detail-466965.html
到了這里，關(guān)于2023-05-25 最近的一個客戶POC的反思的文章就介紹完了。如果您還想了解更多內(nèi)容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！
