Ryan He on Nostr: 看到一個在關鍵項目使用SQLite的例子 ...
看到一個在關鍵項目使用SQLite的例子
『我經營一家售賣劇院門票的服務，更重要的是提供檢查門票是否有效的服務。
通過掃描QR碼檢查門票，當人們走進門口時進行。人們不僅討厭坐在座位上等待（或更糟的是，站在排隊等待）...您還需要支付數百名員工站在一旁無所事事等待 - 可能每削減一秒過程的成本約為5美元。除了工資成本之外，等待表演開始的人在酒吧不買飲料。許多活動的飲料銷售額比門票銷售額還高...通常門票銷售收入的高比例歸給擁有表演版權的人。他們通常也從飲料銷售中獲得一定比例的收入，但這比例較小。
因此，在表演實際開始之前，盡可能晚地開始掃描門票是有很強的動機的。如果有1秒的停機時間...可能會觸發十分鐘的故障排除（打開然後再關掉等）由十多個人進行。
演出晚了十分鐘可能會非常糟糕。如果演出準備於下午6點開始，演出結束於晚上11點，這是五個小時，其中一些人在整個時間內都在不停地工作 - 這真的不太好。現場活動是危險的，工作場所死亡事故太常見，有些為了防止這些事故而採取的措施實際上不留給某人在表演期間進行用餐休息的時間。亞歷克·鮑德溫被一把“道具”槍擊身亡，部分原因是工作人員在拍攝現場的關鍵時刻休息，打斷了例行的安全檢查...在劇院中也會發生這樣的事情。
有關休息的工會規定是一切都是按計劃進行的，因為現實世界中會發生延遲，所以設有財務懲罰以阻止延遲。因此，而不是每秒5美元，那十分鐘可能會使您每秒花費20美元...換句話說，這是預算中沒有的12000美元成本...製片人將不得不解釋為什麼他們的預算超支了12000美元 - 請記住，即使表演順利進行，該表演可能實際上並不在單個晚上的演出中獲利12000美元。有時候，他們即使順利進行，也可能不會獲利。
所有這些都意味著您一秒的停機時間將會引發正式的書面事件報告和討論發生的事情的會議，這些會議將不可避免地包括調查替代門票服務。我們知道像這樣的小事情可能會讓我們損失一大筆錢，因為當新客戶告訴我們他們在短暫的停機期後離開了競爭對手時，我們經常贏得新客戶（我們最大的競爭對手最近有一個錯誤，即在某些便宜的Android手機上隨附的糟糕瀏覽器中無法購買門票...他們相對迅速地解決了這個問題，但我們仍然吸引了很多新客戶）。
當然 - 這只在特定建築物的7:30 pm到7:55 pm之間才會如此關鍵...上午10點的一小時停機是不會被注意到的...但如果這是一個全球服務，每個時區都有數十個城市，那麼這個關鍵的狀態就是24/7/365。
一秒的停機時間絕對會對公司的利潤造成可測量且巨大的成本。我們在去年2月部署了一個用於門票掃描的重要新系統。它運作得非常完美，自那時以來我們沒有進行任何更改 - 除了測試它之外，我們將在接下來的兩個月內開始部署它。這就是我們有多不願意破壞事物。
我們考慮過使用PostgreSQL，但決定它不夠可靠。
我們使用SQLite - 每個手持掃描設備以及服務器都運行自己的數千個數據庫。服務器本身對於每個個別事件都有一個單獨的數據庫（還有冗余的服務器，因此每個事件都有多個服務器端的數據庫）。還有一些關鍵事項的數據庫，如掃描門票，與較不重要的事項（如付款記錄，活動詳情等）分開。
對於服務器來說，PostgreSQL在很多方面都優於SQLite - 但SQLite的一個重要優勢是靈活性 - 我們可以進行分階段的部署，從我們開始售賣門票（實際事件的幾個月前）到實際事件的時刻，除非我們認為一個錯誤將直接影響事件，否則不會對該數據庫進行任何部署。今天的一次部署通常只適用於明天開售的事件。
每個業務案例都有不同的需求，但通讀這篇有關Postgres未來的文章，聽起來他們正在努力改進一些我選擇不在這特定案例中使用它的原因。』
https://news.ycombinator.com/item?id=38849223
『我經營一家售賣劇院門票的服務，更重要的是提供檢查門票是否有效的服務。
通過掃描QR碼檢查門票，當人們走進門口時進行。人們不僅討厭坐在座位上等待（或更糟的是，站在排隊等待）...您還需要支付數百名員工站在一旁無所事事等待 - 可能每削減一秒過程的成本約為5美元。除了工資成本之外，等待表演開始的人在酒吧不買飲料。許多活動的飲料銷售額比門票銷售額還高...通常門票銷售收入的高比例歸給擁有表演版權的人。他們通常也從飲料銷售中獲得一定比例的收入，但這比例較小。
因此，在表演實際開始之前，盡可能晚地開始掃描門票是有很強的動機的。如果有1秒的停機時間...可能會觸發十分鐘的故障排除（打開然後再關掉等）由十多個人進行。
演出晚了十分鐘可能會非常糟糕。如果演出準備於下午6點開始，演出結束於晚上11點，這是五個小時，其中一些人在整個時間內都在不停地工作 - 這真的不太好。現場活動是危險的，工作場所死亡事故太常見，有些為了防止這些事故而採取的措施實際上不留給某人在表演期間進行用餐休息的時間。亞歷克·鮑德溫被一把“道具”槍擊身亡，部分原因是工作人員在拍攝現場的關鍵時刻休息，打斷了例行的安全檢查...在劇院中也會發生這樣的事情。
有關休息的工會規定是一切都是按計劃進行的，因為現實世界中會發生延遲，所以設有財務懲罰以阻止延遲。因此，而不是每秒5美元，那十分鐘可能會使您每秒花費20美元...換句話說，這是預算中沒有的12000美元成本...製片人將不得不解釋為什麼他們的預算超支了12000美元 - 請記住，即使表演順利進行，該表演可能實際上並不在單個晚上的演出中獲利12000美元。有時候，他們即使順利進行，也可能不會獲利。
所有這些都意味著您一秒的停機時間將會引發正式的書面事件報告和討論發生的事情的會議，這些會議將不可避免地包括調查替代門票服務。我們知道像這樣的小事情可能會讓我們損失一大筆錢，因為當新客戶告訴我們他們在短暫的停機期後離開了競爭對手時，我們經常贏得新客戶（我們最大的競爭對手最近有一個錯誤，即在某些便宜的Android手機上隨附的糟糕瀏覽器中無法購買門票...他們相對迅速地解決了這個問題，但我們仍然吸引了很多新客戶）。
當然 - 這只在特定建築物的7:30 pm到7:55 pm之間才會如此關鍵...上午10點的一小時停機是不會被注意到的...但如果這是一個全球服務，每個時區都有數十個城市，那麼這個關鍵的狀態就是24/7/365。
一秒的停機時間絕對會對公司的利潤造成可測量且巨大的成本。我們在去年2月部署了一個用於門票掃描的重要新系統。它運作得非常完美，自那時以來我們沒有進行任何更改 - 除了測試它之外，我們將在接下來的兩個月內開始部署它。這就是我們有多不願意破壞事物。
我們考慮過使用PostgreSQL，但決定它不夠可靠。
我們使用SQLite - 每個手持掃描設備以及服務器都運行自己的數千個數據庫。服務器本身對於每個個別事件都有一個單獨的數據庫（還有冗余的服務器，因此每個事件都有多個服務器端的數據庫）。還有一些關鍵事項的數據庫，如掃描門票，與較不重要的事項（如付款記錄，活動詳情等）分開。
對於服務器來說，PostgreSQL在很多方面都優於SQLite - 但SQLite的一個重要優勢是靈活性 - 我們可以進行分階段的部署，從我們開始售賣門票（實際事件的幾個月前）到實際事件的時刻，除非我們認為一個錯誤將直接影響事件，否則不會對該數據庫進行任何部署。今天的一次部署通常只適用於明天開售的事件。
每個業務案例都有不同的需求，但通讀這篇有關Postgres未來的文章，聽起來他們正在努力改進一些我選擇不在這特定案例中使用它的原因。』
https://news.ycombinator.com/item?id=38849223