Я тільки почав з нереляційних БД, і все ще намагаюся обернути голову навколо цього і зрозуміти, якою буде найкраща модель. І я можу виступати лише за CouchDB.
Але я маю кілька попередніх висновків:
Ви придумали альтернативні конструкції, які працюють набагато краще в нереляційному світі?
Зміщення фокусу на дизайні: Дизайн моделі документа (відповідно до таблиць БД) стає майже неактуальним, в той час як усе залежить від проектування поглядів (відповідних запитам).
Структура БД документа змінює складності: у SQL є негнучкі дані та гнучкі запити, у БД документів - навпаки.
Модель CouchDB - це набір "документів JSON" (в основному вкладені хеш-таблиці). Кожен документ має унікальний ідентифікатор і його можна тривіально отримати за ідентифікатором. Для будь-якого іншого запиту ви пишете "представлення", які називаються наборами функцій карти / зменшення. Перегляди повертають набір результатів у вигляді списку пар ключів / значень.
Хитрість полягає в тому, що ви не запитуєте базу даних у тому сенсі, як ви запитуєте базу даних SQL: Результати запуску функцій перегляду зберігаються в індексі, і лише індекс можна запитувати. (Як "отримати все", "отримати ключ" або "отримати діапазон ключів".)
Найближча аналогія у світі SQL була б, якби ви могли запитувати БД лише за допомогою збережених процедур - кожен запит, який ви хочете підтримати, повинен бути заздалегідь визначений.
Оформлення документів надзвичайно гнучка. Я знайшов лише два обмеження:
- Зберігайте пов’язані дані разом в одному документі, оскільки приєднання нічого не відповідає.
- Не робіть документи настільки великими, що вони надто часто оновлюються (як, наприклад, розміщення всіх продажів компанії за рік в одному документі), оскільки кожне оновлення документа викликає повторну індексацію.
Але все залежить від проектування поглядів.
У альтернативних конструкціях я виявив, що робочі замовлення на розмір краще з CouchDB, ніж будь-яка база даних SQL, знаходяться на системному рівні, а не на рівні зберігання. Якщо у вас є деякі дані та ви хочете розмістити їх на веб-сторінці, складність загальної системи знижується щонайменше на 50%:
- відсутність проектування таблиць БД (незначна проблема)
- немає проміжного шару ODBC / JDBC, всі запити та транзакції через http (помірний випуск)
- просте відображення DB-об'єкта від JSON, що майже тривіально порівняно з аналогічним у SQL (важливо!)
- Ви можете потенційно пропустити весь сервер додатків, оскільки Ви можете спроектувати документи, які слід отримувати безпосередньо в браузері за допомогою AJAX, та додати трохи полірування JavaScript перед тим, як вони відображатимуться як HTML. (ВЕЛИЧЕЗНО !!)
Для звичайних веб-сайтів бази даних, що базуються на документах / JSON, є величезною виграшею, а недоліки менш гнучких запитів та деякого додаткового коду для перевірки даних здаються низькою ціною.
Чи вдарили ти головою об все, що здається неможливим?
Ще ні. Мапа / скорочення як засіб запиту до бази даних незнайоме і вимагає набагато більше мислення, ніж написання SQL. Існує досить невелика кількість примітивів, тому отримання необхідних результатів - це насамперед питання творчості з тим, як вказати ключі.
Існує обмеження в тому, що запити не можуть одночасно переглядати два чи більше документів - жодних з'єднань та інших видів взаємозв'язків між документами, але поки що нічого не було непереборним.
Як приклад обмеження, підрахунки та суми є простими, але середні показники не можуть бути обчислені переглядом / запитом CouchDB. Виправити: повернути суму та підрахувати окремо та обчислити середнє для клієнта.
Чи ви усунули проміжок будь-якими моделями дизайну, наприклад, щоб перевести з одного на інший?
Я не впевнений, що це можливо. Це більше повне перероблення, як переклад програми функціонального стилю в об'єктно-орієнтований стиль. Загалом типів документів набагато менше, ніж є таблиці SQL та більше даних у кожному документі.
Один із способів придумати це - подивитися у своєму SQL на вставки та загальні запити: Які таблиці та стовпці оновлюються, наприклад, коли клієнт розміщує замовлення? А які для щомісячних звітів про продажі? Ця інформація, ймовірно, повинна міститись у тому самому документі.
Тобто: один документ для Замовлення, який містить ідентифікатор клієнта та ідентифікатори продукту, із необхідними копіями полів для спрощення запитів. Все, що знаходиться в документі, можна легко запитати, все, що вимагає перехресних посилань між, наприклад, Замовлення та Клієнт, має робити клієнт. Тож, якщо ви хочете отримати звіт про продажі по регіонах, вам, мабуть, слід покласти код регіону в замовлення.
Ви навіть взагалі робите чіткі моделі даних (наприклад, в UML)?
Вибачте, ніколи не робив багато UML перед документами БД :)
Але вам потрібна якась модель, яка говорить про те, які поля належать до яких документів і які види значень вони містять. І для вашої власної довідки пізніше, і для того, щоб переконатися, що всі, хто використовує БД, знають умови. Оскільки ви більше не отримуєте помилки, наприклад, якщо ви зберігаєте дату в текстовому полі, і кожен може додати або видалити будь-яке поле, яке вам здається, вам потрібен як код перевірки, так і конвенції, щоб забрати слабку сторону. Особливо, якщо ви працюєте із зовнішніми ресурсами.
Чи сумуєте ви про якісь основні додаткові послуги, які надають RDBMS?
Ні. Але мій досвід розробник веб-додатків, ми маємо справу з базами даних лише в тій мірі, в якій ми повинні :)
Компанія, в якій я працював, зробила продукт (webapp), розроблений для запуску через бази даних SQL від багатьох постачальників, а "додаткові сервіси" настільки відрізняються від БД до БД, що їх доводилося реалізовувати окремо для кожної БД. Таким чином, нам було менше роботи з переміщення функціональності з RDBMS. Це навіть розширилося до повнотекстового пошуку.
Тож від чого я відмовляюся - це те, чого я ніколи насправді не мав. Очевидно, ваш досвід може відрізнятися.
Застереження: над тим, над чим я зараз працюю, є веб-сторінка щодо фінансових даних, котирувань акцій тощо. Це дуже гарна відповідність для БД документа, з моєї точки зору я отримую всі переваги БД (наполегливість та запити) без зайвих проблем.
Але ці дані досить незалежні один від одного, складних реляційних запитів немає. Отримайте найновіші котирування за тикером, отримайте котирування за тикером та діапазоном дат, отримайте метаінформацію компанії, це майже все це. Ще один приклад, який я бачив, - це програма для блогу, і для блогів не характерні масово складні схеми баз даних.
Що я намагаюся сказати, це те, що всі успішні додатки документів, про які я знаю, були з даними, які в першу чергу не мали великої взаємозв'язку: Документи (як у пошуку Google), повідомлення в блогах, статті новин, фінансові дані .
Я очікую, що є набори даних, які краще відображають SQL, ніж модель документа, тому я думаю, що SQL виживе.
Але для тих із нас, хто хоче просто простий спосіб зберігання та отримання даних - і я підозрюю, що нас багато - бази даних документів (як у CouchDB) є знахідкою.