2008-09-26 76 views
0

我正在考慮一個應用程序,它是一個「自由格式」數據庫。一組筆記和工件。但是,同時在系統內還有一些更高層次的結構。我應該發佈文件格式還是API?

我10秒背的,餐巾紙設計需要在小文件(或許是XML),目錄中的組織存儲個人「項」,然後索引使用類似Lucene的整個集。

其背後的前提是,這將是平凡的人,以「接口」與系統,因爲他們需要僅僅是「把文件到正確的地方。」由於它們是簡單的文本文件,它們可以由任何程序(例如腳本語言)生成,並且如果必要的話甚至可以是文本編輯器。

細節是維護索引和任何其他可能的關係。

理論上,在啓動時,程序可以掃描目錄中已更改的文件並更新索引。它甚至可以在後臺執行此操作。我不認爲這是一個可怕的漫長過程,因爲我不希望有1000個參賽作品。但是如果尺寸變得太大,只有在指示時才能讓系統掃描。

或者我可以要求一些特殊文件與「新文件」或諸如此類的事情,該系統可以檢查開始更新。

另一種方法是使用其他格式而不是單個文件。使用某種數據庫,他們是一打一毛錢。但是通過這樣做,突然間,這些數據對於一個臨時用戶來說是非常「不透明」的。這使得腳本編寫等可能更困難。

現在,我可以使用具有廣泛支持的SQLLite之類的東西,併發布數據庫模式。或者我想我可以在應用程序中創建一個服務層。

如果我把它寫在Java中,我可以發佈一個工具可以使用Java API,但只有當它也被用Java編寫的。

或者我可以暴露API端口,比如,輕量級的Web服務(POX通過HTTP,REST或通過HTTP)。目前HTTP支持的範圍非常廣泛。這將要求應用程序運行以便使用任何實用程序。

與所有一樣,這是一個平衡。我認爲File解決方案更簡單,效率可能更低,但可能會限制內部複雜性。

該API可以更強大,但使用起來更困難,而且對於臨時用戶肯定沒有用處。

您認爲您會如何處理這類問題?

回答

2

我會使用文件格式(並以某種方式釋放您的訪問代碼作爲參考植入,以便人們可以做I/O)

0

雖然我不能要求知道哪些解決方案最適合您的需求,我會在事後一個設計,讓用戶到我的數據的膽量自由訪問。我想總體設計取決於新文件的添加頻率,訪問頻率以及存儲的信息類型

1

KISS

正如你所說,該文件的解決方案是簡單的,所以應該成爲最後的贏家。只要計劃將數據存儲器件作爲一個易於更換的模塊(SoC),並且只會根據需要增加複雜性。

0

絕對是一個嵌入式數據庫作爲主數據存儲。這將爲您節省很多頭痛,保持您的文件夾結構的方式。搜索,索引也會快很多。用戶可以通過複製單個文件來遷移或備份他們的數據。您可以利用全文搜索以及大量的SQL查詢和功能。

然後您可以選擇「導出」選項。導出到文件系統將構建前面描述的XML層次結構。您還可以輕鬆導出到單個文件,XML,CSV等。從這些導出導入也是一種選擇。

最後,如果您在內部足夠乾淨地分隔數據庫訪問權限,則可以將該API作爲API示例展示給用戶。

因此,使用嵌入式數據庫作爲主數據存儲區可以輕鬆地爲您提供所有其他選項,以及數據庫的性能。

相關問題