Як я можу дізнатися, що мої дані є реляційними або об'єктно-орієнтованими за своєю природою?

Просто прочитайте ці рядки-

• Якщо ваші дані мають об’єктну природу, то використовуйте об'єкти зберігання ("NoSQL"). Вони будуть набагато швидшими, ніж реляційна база даних.

• Якщо ваші дані мають реляційний характер, накладні витрати реляційної бази даних варті того.

від-

http://seldo.com/weblog/2011/06/15/orm_is_an_antipattern

Отже, як я можу знати, чи є мої дані реляційними за своєю природою чи об'єктно-орієнтованими?

Загрожуючи розстріляти на шматки, я спробую просте англійське визначення.

Для мене "реляційний характер" означає: всі елементи певного типу мають майже однакові атрибути, що дозволяє спростити розробку простої таблиці, але всі елементи в цій таблиці, а потім SQL для виконання CRUD та пошуку. Крім того, якщо ваші дані можуть бути змодельовані таким чином, що всі елементи мають один обмежений набір типів, ви можете визначити реляційну структуру даних, що відповідає цьому набору типів.

"Природа об'єкта" перекладається на: Предмети подібного типу можуть мати найрізноманітніші атрибути, і ці атрибути можуть бути найрізноманітнішими за своєю суттю та типом. Дуже часто це можна (за умови достатнього зусилля) перекласти на реляційну модель, але багато таблиць були б дуже рідко заселеними, і ви б закінчилися дуже неефективними приєднаннями LEFT OUTER, що робить ефективність реляційної бази даних млявою у порівнянні в базу даних NOSQL.

Я б сказав, що з моєї точки зору, немає жодної суворої лінії, яка розділяє ці два. Напевно, ви можете знайти будь-яку кількість прикладів, які потрапляють де-небудь між двома крайнощами.

Гаразд, тепер я відкрив себе для снайперів з усіх боків. Будь-які коментарі вітаються. Подивимось, чи зможемо ми разом вдосконалити це визначення.

Дані обидва.

(строго кажучи, це не може бути об'єктом в природі, оскільки йому не вистачає поведінки, але ми не будемо вибирати).

Рішення щодо зберігання даних у базі даних RDBMS або NoSQL залежать більше від того, як ви збираєтесь використовувати дані , а не від реальної "природи" самих даних.

Якщо ви збираєтесь підтримувати всілякі навігаційні шляхи до даних, то, можливо, ви захочете зберігати дані в RDBMS, оскільки у вас будуть різні способи доступу та представлення даних. Вам потрібна база даних, щоб зробити для вас багато важких підйомів. Наприклад, до даних "Замовлення" можна отримати доступ через замовника, особу з продажу, код (товар), дату, регіон тощо.

З іншого боку, якщо у вас є мінімальні навігаційні шляхи, ви можете просто зберігати весь об’єкт. Наприклад, "Кошик", доступ до якого використовується лише веб-переднім кінцем і який довго не зберігається або багато аналізується, може бути краще підходить до магазину NoSQL. Жертвоприношення (зберігання документа або ключових значень) NoSQL зберігає дані в тому, що ви не маєте відносин між колекціями - якщо вам не потрібні ці відносини (для навігаційних шляхів, спеціальних запитів або звітів) і піклуєтесь про них у своїх додаток, тоді вам буде добре.

Звичайно, ви можете зберігати дані в обох з різних причин, але у цього є свої недоліки.

Дані не є "об'єктом у природі" або "реляційним у природі". Будь-який вид даних може бути представлений як у реляційній, так і в об'єктній моделі / структурі графіків. Що підходить, залежить від того, як дані будуть використовуватися програмами. Часто у вас можуть бути навіть обидва. Наприклад, дані, що використовуються на веб-сайті, можуть зберігатися у реляційній базі даних, але за запитом завантажуються у структуру графіків, які потім кешуються в сховищі значень ключів пам'яті.

Твердження, що об'єкти зберігання / NoSql будуть швидшими, ніж реляційні для деяких видів даних, просто помилкове. Що важливо - це те, як ваша програма використовує дані, а не форму самих даних. Зберігання об'єктів буде швидше при завантаженні графіка об'єкта, що зберігається як одиниця, але буде набагато повільніше при спеціальному запиті на багатьох об'єктах або оновленні властивостей на багатьох об'єктах.

Я думаю, що ключовим рядком статті є:

"Likewise, sometimes the output will be a single object X, which is easy to represent. But sometimes the output will be a grid of aggregate data, or a single integer count"

Мені здається, автор зазначає, що якщо ваш код, наприклад, отримує кількість клієнтів в Іспанії за деякою логікою, ви не повинні заповнювати список клієнтів усіма клієнтами в Іспанії, а потім рахувати замовник заперечує. (до якого ORM може підштовхнути вас)

Очевидно, ви не можете сказати від самої структури даних клієнта, чи буде вона використовуватися так. тому я думаю, що ми повинні інтерпретувати "дані", щоб означати "всю інформацію, яку використовує ваша програма". Якщо сюди входять такі речі, як агрегати або "Усі X, пов'язані з Y", то ваші "дані" не підходять для атомного підходу NoSql