嗨，開發者！
我是 Alex，技術愛好者。我很高興向您展示 Jinbase，我的多模型事務嵌入式資料庫。
大約一年前，我介紹了 Paradict，這是我對多格式流序列化的看法。鑑於其可讀性，Paradict 文字格式實際上是設定檔的一種有趣的資料格式。但是使用 Paradict 來管理設定檔最終會使其編程介面變得混亂，並使那些仍然可以選擇專用於設定檔的替代庫（TOML、INI 檔案等）的使用者感到困惑。所以我使用 Paradict 作為 KvF（鍵值文件格式）的依賴項，這是我的一個新項目，專注於帶有部分的配置文件。
憑藉其緊湊的二進位格式，我認為Paradict 將成為一個新專案的有效依賴項，該專案將依賴I/O 函數（例如Open、Read、Write、Seek、Tell 和Close）來實現簡約但可靠的功能持久性解決方案。但那是在我了解到「文件很難」之前。 SQLite 及其事務、BLOB 資料類型和 BLOB 的增量 I/O 似乎是我的新專案的正確選擇。
Jinbase 最初只是一個鍵值存儲，最終成為一個多模型嵌入式資料庫，突破了我們通常使用 SQLite 所做的事情的界限。當我意識到鍵值儲存不太適合為每個新記錄自動產生唯一識別碼(UID) 的情況時，第一次轉換到第二個資料模型（倉庫），從而為使用者節省了時間提供可能意外發生衝突並因此覆蓋現有記錄的識別符的負擔。之後，我實現了一種搜尋功能，該功能接受倉庫儲存的UID 範圍、倉庫和鍵值儲存的時間跨度（記錄自動帶有時間戳記）以及鍵值儲存中字串和整數鍵的GLOB 模式和數字範圍.
佇列和堆疊資料模型是作為必須按特定順序使用記錄的用例的解決方案而出現的。典型的記錄將在單一事務單元中從資料庫中檢索和刪除。
由於使用SQLite作為儲存引擎，Jinbase事實上支援關係模型。為了方便起見，與 Jinbase 內部相關的所有表都以 jinbase_ 為前綴，這使得 Jinbase 成為開啟舊版 SQLite 檔案以新增與臨時關係模型安全共存的新資料模型的有用工具。
所有四個主要資料模型（鍵值、倉庫、佇列、堆疊）都支援與 Paradict 相容的資料類型，例如字典、字串、二進位資料、整數、布林值、日期時間等。在幕後，當使用者發起寫入操作，Jinbase 會迭代序列化（二進位資料除外）、分塊並儲存資料。一筆記錄不僅可以批次訪問，還可以有兩種層級的部分存取粒度：位元組級和欄位級。
雖然SQLite 的BLOB 增量I/O 旨在針對一行中的單一BLOB 列，但Jinbase 對此進行了擴展，以便對於每個記錄，增量讀取覆蓋所有區塊，就好像它們是單一統一的BLOB 一樣。僅對於字典記錄，Jinbase 會自動建立並維護一個由指向根欄位的指標組成的輕量級索引，然後允許從任意記錄中提取在返回之前自動反序列化的欄位內容。
Jinbase 最明顯的用例是儲存使用者首選項、退出前保留會話資料、基於順序的資料流處理、向其他進程公開資料、使用新資料模型升級舊版 SQLite 檔案以及自訂資料持久性解決方案。
Jinbase 以 Python 編寫，可在 PyPI 上使用，您可以使用 README 中的範例。
讓我知道您對這個項目的看法。
專案連結：https://github.com/pyrustic/jinbase
以上是Jinbase – 多模型事務嵌入式資料庫的詳細內容。更多資訊請關注PHP中文網其他相關文章！
