我已經開始使用單個Rails應用程序。非常簡單，基本上只讀，用於一系列業務應用程序的前端（使用視圖支持檢索數據） - 使用一些標準表來擴充視圖。2 rails應用程序 - 使用通用引擎共享數據
我現在需要在一個新的應用程序中使用相同的一組數據（這兩個應用程序共享相同的數據，工作方式不同，嘗試將它們合併到同一應用程序中並不重要）。
我覺得把我可以重複使用的模型分割成他們自己的引擎並讓這兩個應用程序共享數據庫是最容易的。
添加一個API並讓這兩個應用程序查詢是一個選項，但實際上我不確定我能否提供一個API來正確滿足這兩個應用程序，因爲它們以不同方式使用數據。
在這個基礎上，我想到了如果我給每個應用程序一個表前綴，或者使用不同的架構來命名空間 - 這樣每個應用程序都擁有它們不共享的不同表格，但我可以輕鬆地重用現有視圖而不必複製它們。
這兩個選項似乎都很好，除了我忘記了常見視圖和數據的遷移之外。
所以，我能想到的唯一的事情是：
由於2個應用程序有點緊反正耦合的，我有我的公用數據引擎不遷移在所有 - 任何修改的意見/表將由「第一」申請處理。這似乎有點令人討厭，因爲模型現在被包含在一個單獨的引擎中。 我不喜歡在引擎中進行遷移然後將它們複製到一個或另一箇中的想法，因爲這基本上是相同的。
我使用pivotal labs的建議，但添加一些代碼來檢測它是否在「第一」的應用程序，並只適用於該。如果我沒有這樣做，我最終會遇到包括引擎遷移在內的兩個應用程序，這會導致這兩個應用程序嘗試運行相同的遷移，並導致除了痛苦之外的任何事情。
我實際上將普通數據分解到它自己的數據庫中。因此，應用程序＃1使用db＃1，應用程序＃2使用db＃2，公用數據存放在db＃3中，並且可由兩個應用程序訪問。隨着有點虛弱，我猜測我最終可能會有3個數據塊，3個schema_migrations，而且我可以盲目地將我的遷移留在引擎中，並按照pivotal labs將它們包含在兩個應用程序中 - 我的計劃是做類似this使所有這些工作，並有共同模型設置連接到他們自己的數據庫，而不是應用程序DB
堅持1分貝和多個模式，並以某種方式設置任務來運行引擎遷移只，只使用一個鎖定到它自己的模式的帳戶 - 這樣它會創建它自己的schema_migrations。
我有點癱瘓，因爲我不知道什麼是最不低劣的選擇。 3或4感覺「最好」，但不是很好。
儘管我希望在公共數據前面有一個API，但是這兩個應用程序將對這些數據進行分組和執行不同的操作，但我不知道該如何提供2個2而不是隻爲他們提供API方法 - 這將會非常快速。無論是那個還是我都必須爲大量對象提供JSON訂閱源，然後在客戶端應用程序中執行處理......這看起來非常浪費。如果我可以直接訪問數據庫，似乎更容易。我只是想盡量避免這種情況？您的意見是否仍然想要在他們之間建立一個API？ –
這取決於查詢改變了多少。如果只是一些變量運行相同的複雜查詢（例如開始和結束時間段），可以通過JSON API輕鬆公開。如果查詢變化很大，則可能需要直接訪問數據庫。在rails應用程序中定義第二個連接非常簡單。我認爲主要標準不是查詢的複雜性，而是需要修改多少。更多的變化，更容易去數據庫連接。 – ReggieB
感謝您的想法Reggie。非常感謝<3 –