my sql中用sql語句，增刪改錯了？不可以，有備份日志就可以還，否則會被刪除，只能通過日志恢復(fù)。sql怎么自測權(quán)限授予成功？登錄查詢分析器，賬號將使用您新創(chuàng)建的賬號，密碼將使用您設(shè)置的密碼。然后u

my sql中用sql語句，增刪改錯了？

不可以，有備份日志就可以還，否則會被刪除，只能通過日志恢復(fù)。

sql怎么自測權(quán)限授予成功？

登錄查詢分析器，賬號將使用您新創(chuàng)建的賬號，密碼將使用您設(shè)置的密碼。然后use對應(yīng)數(shù)據(jù)庫，通過執(zhí)行add，delete，chang

sql數(shù)據(jù)庫數(shù)據(jù)量龐大時怎么處理？

我用postgresql也發(fā)現(xiàn)了同樣的邏輯。存儲過程的代碼是c#的三分之一。因為存儲過程語言是為了描述數(shù)據(jù)而創(chuàng)建的，所以它對于混合處理變量和數(shù)據(jù)具有天然的優(yōu)勢。加上一些注釋，代碼比c#可讀性更好。而且因為服務(wù)器和數(shù)據(jù)庫是一個交互，所以執(zhí)行更快，用戶體驗好，服務(wù)器并發(fā)性好。Postgr

近幾年熱門討論的低代碼，甚至無代碼，只是一個噱頭嗎？

近年來，低代碼平臺在變得流行起來。從發(fā)展的角度來看，我對這個東西嗤之以鼻。

最近一直在研究這類東西，因為公司的老板們都癡迷于這個東西。低碼作為一種營銷理念，非常符合大佬們的想法，就是叫快速搭建，輕松適配。似乎可以縮短開發(fā)周期，節(jié)省部署和維護成本，節(jié)省資金，自然適合老板 的愿望。

然而，這些低代碼平臺的弱點被巧妙地隱藏了起來。動態(tài)解析渲染的低代碼平臺注定性能差，固化不成熟的表單(數(shù)據(jù)庫表)設(shè)計邏輯注定正確。數(shù)據(jù)量大，業(yè)務(wù)復(fù)雜的支撐極其難看?？杀氖?，市面上大部分產(chǎn)品都是這樣，整體架構(gòu)陳舊，設(shè)計不成熟，使用場景嚴重受限。其中，HW s AppCube考慮的比較多，但是學(xué)習(xí)成本一點都不低，也有自己相應(yīng)的問題。

該公司購買了一個低代碼平臺，并用它來構(gòu)建一個項目。最終由于性能、數(shù)據(jù)支持、兼容性等問題，大量功能在項目上線前重新開發(fā)，返工嚴重，研發(fā) ampampd組也不穩(wěn)定。可以說是賠了夫人又折兵。大佬們終于意識到這東西有漏洞。

如果未來低碼還是這個水平，無法突破，那么，

要不要解散你的技術(shù)團隊，給他們買個低碼平臺~

你想讓你的公司 公司倒閉了嗎？購買一個低代碼的研發(fā)平臺；ampD ~

想事半功倍？建議給公司買個低碼平臺~

低代碼有毒~粗略來說，業(yè)務(wù)線核心數(shù)據(jù)百萬以上，并發(fā)200以上。唐 不要冒險。

簡單的增刪改查詢還是挺合適的，但實際上編碼成本并不多。

雞肋食之無味，棄之可惜。