Вам потрібно продумати, як ви підходите до заявки орієнтованим на документи. Якщо ви просто спробуєте повторити, як ви змоделюєте проблему в СУБД, тоді ви зазнаєте невдачі. Існують також різні компроміси, які ви, можливо, захочете зробити. ([ed: не впевнений, як це пов’язано з аргументом, але:] Пам’ятайте, що конструкція CouchDB передбачає, що у вас буде активний кластер із багатьох вузлів, які можуть вийти з ладу в будь-який час. Як ваш додаток буде обробляти один із вузлів бази даних, що зникає з під ним?)
Один із способів подумати про це - уявити, що у вас не було комп’ютерів, а лише паперові документи. Як би ви створили ефективний бізнес-процес, використовуючи передані шматочки паперу? Як можна уникнути вузьких місць? Що, якщо щось піде не так?
Інший кут, про який слід подумати, - це можлива послідовність, коли ви врешті-решт перейдете в стабільний стан, але певний період часу ви можете бути непослідовними. Це анафема на землі СУБД, але надзвичайно поширена в реальному світі. Прикладом канонічної операції є переказ грошей з банківських рахунків. Як це насправді відбувається в реальному світі - за допомогою окремих атомних операцій або через різні банки, що видають один одному кредитні та дебетові повідомлення? Що відбувається, коли ви пишете чек?
Тож давайте розглянемо ваші приклади:
- CRUD сутностей із деякими полями з унікальним індексом.
Якщо я правильно розумію це з точки зору CouchDB, ви хочете мати колекцію документів, де якесь іменоване значення гарантовано буде унікальним для всіх цих документів? Цей випадок, як правило, не підтримується, оскільки документи можуть створюватися на різних копіях.
Тому нам потрібно розглянути реальну проблему та з’ясувати, чи зможемо ми це моделювати. Вам справді потрібні, щоб вони були унікальними? Чи може ваша програма обробляти кілька документів з однаковим значенням? Вам потрібно призначити унікальний ідентифікатор? Чи можете ви це зробити детерміновано? Поширеним сценарієм, коли це потрібно, є де потрібно унікальний послідовний ідентифікатор. Це важко вирішити в тиражованому середовищі. Насправді, якщо унікальний ідентифікатор повинен бути строго послідовним щодо створеного часу, це неможливо, якщо вам потрібен ідентифікатор відразу. Вам потрібно послабити принаймні одне з цих обмежень.
- веб-додаток для електронної комерції, як
Я не впевнений, що додати тут, оскільки останній коментар, який ви зробили до цього допису, був сказати "дуже корисно! Спасибі". Чи не бракувало чогось із наведеного там підходу, що все ще викликає у вас проблему? Я думав, що відповідь Містера Курта була досить повною, і я додав трохи вдосконалення, яке зменшило б суперечки.