Використання реляційної бази даних та об'єктів JSON для даних про події та дії


28

Я працюю над проектом, де я намагаюся вирішити між використанням стандартної реляційної бази даних SQL або об'єктами JSON для зберігання даних про подію чи діяльність.

Проект буде зберігати дані про кілька типів подій, тому я вирішив просто описати один тип події для цього питання.

Подія в прямому ефірі (описана повністю за допомогою схеми JSON в нижній частині цього питання) - це об'єкт, який зберігає такі дані, як місце проведення події, час / дата події та вартість події. Об'єкт події в прямому ефірі має як "один на один" (подія -> ім'я, подія -> опис), так і один на багато (подія -> місця, подія -> дати, подія -> типи квитків ) відносини. Крім того, об'єкт події може містити один або більше ідентифікаторів виконавця, які посилаються на об'єкт виконавця. Об'єкт виконавця зберігає дані про музикантів, які виступають на заході живої музики.

Користувачі запитують дані, використовуючи як прості ("Знайди мені події з" x "ім'ям)), так і складні (" Знайди мені події з музичним жанром "x" та "y" вартістю в радіусі "z" від мого поточного місцеположення ") запити. Дані будуть надані користувачами за допомогою веб-форми.

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

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

{
    "event": {
        "eventID":{
            "type":"string"
        },  
        "eventType":{
            "type":"array",
            "eventTypeItem":{
                "type":"string"
            }
        },
        "eventName":{
            "type":"string"
        },      
        "eventDescription":{
            "type":"string"
        },
        "eventVenueList":{
            "type":"array",
            "eventVenueListID":{
                "type":"integer"
            }
        },
        "eventURL":{
            "type":"string"
        },
        "eventTwitter":{
            "type":"string"
        },
        "eventFB":{
            "type":"string"
        },
        "eventInstagram":{
            "type":"string"
        },
        "eventEmail":{
            "type":"string",
            "format":"email"
        },
        "eventContactPerson":{
            "type":"string"
        },
        "eventDoorTime": {
            "type":"string",
            "format":"date-time"
        },  
        "eventPerformerIDList":{
            "type":"array",
            "liveMusicPerformerID":{
                "type":"integer"
            }
        },  
        "eventSetList":{
            "type":"array",
            "eventPerformerID":{
                "type":"integer"
            },
            "eventPerformerStartTime":{
                "type":"string",
                "format":"date-time"
            },
            "eventPerformerEndTime":{
                "type":"string",
                "format":"date-time"
            }                                   
        },
        "eventDateList": {
            "type":"array",
            "eventDateItem": {
                "type":"string",
                "format":"date-time"
            }   
        },
        "eventDateStartTime": {
            "type":"string",
            "format":"date-time"
        },
        "eventDateEndTime": {
            "type":"string",
            "format":"date-time"
        },
        "eventTicket":{ 
            "type":"array",
            "eventTicketType":{
                "type":"string" 
            },
            "eventTicketLowPrice":{
                "type":"number"
            },
            "eventTicketHighPrice":{
                "type":"number" 
            },
            "eventDatesAdvancePrice": {
                "type":"number"
            }   
        }
    },  
    "performer": {
        "performerID": {
            "type":"integer"
        },
        "performerType": {
            "type":"string"
        },
        "performerName": {
            "type":"string"
        },
        "performerAlternateName": {
            "type":"array",
            "performerAlterateNameItem":{
                "type":"string"
            }
        },
        "performerGenreList": {
            "type":"array",
            "performerGenreItem":{
                "type":"string"
            }
        },
        "performerURL": {
            "type":"string"
        }                                       
    }
}   

Я не знаю вимог до сайту, але я хотів би шукати: виконавця, місця та, можливо, дати. Чи це буде проблемою, оскільки вони утримуються у типах масивів?
JeffO

Не можете ви запрограмувати свій запит на пошук значень у відповідному масиві?
zgall1

13
JSON - це не формат зберігання. Правда, ви можете зберігати дані, використовуючи текстові файли цього матеріалу, але лише за найпростішими сценаріями. JSON, що є "новішим", ніж реляційні бази даних, не має жодного значення для вашого рішення.
Роберт Харві

1
Я усвідомлюю, що це не формат зберігання. Я мав на увазі, що я можу використовувати об'єкт JSON MongoDB або Postgre для зберігання даних у форматі JSON.
zgall1

2
@RobertHarvey та виборці, сьогодні (2017) JSON - це формат магазину : див. PostgreSQL 9.6+ ... Основний з ~ 2012 року, професійний та зрілий з остаточного 2015 року (тип даних JSONb).
Пітер Краусс

Відповіді:


45

Я думаю, що ваше питання дійсно зводиться до: Коли я повинен використовувати підхід NoSQL проти RDBMS? Ви рано поселилися на JSON (рішення, яке стосується NoSQL), можливо, тому що ви отримали споживачів Ajax.

Звичайно, відповідь на те, коли використовувати підходи NoSQL порівняно з RDBMS, - це в основному про тип даних, з яким ви працюєте, і які споживачі ви очікуєте мати. Якщо ваші дані по суті є реляційними (досить плоскі ієрархії, немає дивних типів даних, таких як зображення чи аудіо, передбачувані зв’язки між схемами, які легко описати в ключах), і ваші споживачі, як очікується, з часом включатимуть людей, які хочуть робити запити Business Intelligence. (спеціальний запит), то RDBMS - це шлях. Досить легко перетворити запит у представлення JSON, тому він не обтяжує істотно ваших споживачів Ajax - він просто додає невелике кодування перетворення у ваші кінцеві точки (REST / SOAP / що завгодно). І навпаки, якщо ваші дані дуже ієрархічні (глибокі схеми), містять дивні типи даних, такі як зображення, аудіо, відео тощо, між сутностями мало зв’язків, і ви знаєте, що ваші кінцеві користувачі не будуть робити BI, тоді NoSQL / зберігання JSON може бути доречним.

Звичайно, навіть ці загальні рекомендації не є твердими. Причина, по якій Google розробила файлову систему Google, MapReduce (робота, яку Дуг Різ використовував для створення Hadoop в Yahoo) і пізніше BigQuery (орієнтований на NoSQL [схему] спосіб управління великомасштабними даними) був саме в тому, що у них було багато спеціальних BI-запити, і вони не змогли отримати реляційні підходи до масштабування до масштабів tera / peta / exa / zetta / yotta, якими вони намагалися керувати. Єдиний практичний підхід полягав у тому, щоб розширити масштаб, пожертвуючи деякою специфічністю користувальницького запиту, яку забезпечує RDBMS, і замінивши простий алгоритм (MapReduce), який можна було б легко легко кодувати для будь-якого заданого запиту.

З огляду на вашу схему вище, моє питання в основному буде: Чому б ви не використовували RDBMS? Я не бачу багато причин цього не робити. Наша професія повинна бути інженерно-орієнтована, а не орієнтована на моду, тому наш інстинкт повинен полягає у виборі найпростішого рішення, яке працює, правда? Я маю на увазі, що для ваших кінцевих точок, можливо, доведеться зробити невеликий переклад, якщо ваші споживачі Ajaxy, але ваші дані виглядають дуже плоскими, і, здається, ймовірно, що бізнес-користувачі захочуть робити всі види спеціальних запитів на такі речі, як музичні події (Які Подія була найбільш відвідуваною за 50 миль від нашої столиці минулого року?)

"Не йдіть до ельфів за порадою, бо вони скажуть і" ні "і". - Фродо


"Наша професія повинна бути інженерно-орієнтована, а не орієнтована на моду, тому нашим інстинктом має бути вибір ..." НАЙКРАЩЕ рішення, яке працює? ;)
Бінк

5

Я вважаю, що тут є більше міркувань, які ви можете не шукати. Тут є дві широкі проблеми:

  • Зберігання
  • Пошук та пошук

Зберігання

Існує безліч думок, чому використовувати для своїх даних магазин no-sql або RDBMS. Одним з найважливіших пунктів, який ми вважали корисним, є те, що ми можемо легко визначати та зберігати об’єкти json у сховищі, не турбуючись про визначення повноцінної структури чи зв’язку між різними типами об’єктів. Деякі з інших причин використання NoSql db - це можливість автоматичного розміщення даних, пошук на основі розташування та просте обслуговування. Є багато хороших баз даних NoSql, мої особисті переваги - MongoDB. Однак якщо ви раніше не використовували базу даних NoSql, існує певна крива навчання, коли ви навчитесь перенаправляти свою думку. Більшість з нас вже деякий час використовує RDBMS, і для того, щоб вийти з цієї звички, потрібні свідомі зусилля. Крім того, ви побачите, що хочете переробити свою модель даних, коли будете продовжувати свої зусилля та мати краще розуміння понять. Якщо здатність до рефакторингу чи реконструкції не є варіантом вашого проекту, я б запропонував дотримуватися того, що ви вже краще знаєте.

Пошук

Якщо ви маєте намір здійснити пошук, який можна використовувати, я настійно пропоную використовувати спеціальну пошукову систему тексту, наприклад SOLR, для здійснення своїх пошукових запитів. Пошук тексту відбувається повільно, і якщо у вас є кілька фрагментів, то ще повільніше. SOLR підтримує яскраві швидкі пошуки тексту, включаючи зважені параметри пошуку, пошук на основі місцезнаходження та багато іншого. Однак SOLR не підходить як основний склад ваших даних. Це означає, що вам потрібно буде створити механізми для подвійного вставки та оновлення як для вашої основної бази даних, так і для вашого рівня SOLR під час додавання або оновлення подій. Крім того, вам доведеться постійно оновлювати SOLR, видаляючи застарілі / закінчені події.

Хоча це виглядає як багато зайвої роботи, ви згодом подякуєте собі за передбачення використання повнотекстової пошукової системи. Жодна база даних NoSql або RDBMS не наближається до продуктивності та спритності SOLR / Lucene.


3

По-перше, якщо ви намагаєтесь зберігати дані JSON в будь-якому сховищі, але не в базі даних NoSQL , я напевно не заважаю вам використовувати JSON. Причина полягає в тому, що якщо ви, наприклад, зберігаєте свої дані у вигляді файлу JSON, відкривати їх, розбирати, пробирати через нього тощо буде дуже повільно.

Для початку, я можу звузити ваше питання до: Які плюси і мінуси NoSQL і RDBMS ? І вже тисячу разів відповіли в мережі.

Оновлення проекту можна, звичайно, використовувати або NoSQL, або RDBMS ; Однак я, як правило, можу порекомендувати вам подумати над цим полем і шукати інші менш видимі фактори, які можуть допомогти вам вирішити між двома варіантами. Спробуйте побачити, який варіант може прискорити розвиток? Що більше підходить для інших членів команди - якщо ви не є єдиним розробником. Якщо ви продаєте це, який із них дешевший, простіший і взагалі більше підходить для ваших клієнтів, що не розробляють?

Таким чином ви можете нарешті вирішити, яким шляхом рухатись, інакше вирішити, виходячи з даної інформації, буде важко, оскільки обидва варіанти могли б цілком відповідати.


2

У більшості застосувань є вимоги до

  1. Введіть дані, виконайте деяку обробку, збережіть дані, отримайте дані та запитайте їх. Також може виникнути вимога створювати звіти про дані.
  2. Обмінюватися даними між різними частинами системи або із зовнішніми системами

Для досягнення вимог до пункту 1 необхідний метод збереження даних. Як правило, якщо обсяг даних дуже малий, а тип даних простий і не вимагає широких можливостей пошуку, тоді може бути використана проста файлова структура. Оскільки дані стають складнішими, може використовуватися структура XML (або навіть JSON) з даними, які все ще зберігаються у файлах. Пошук, хоча стає більш проблематичним. У міру збільшення обсягу даних і збільшення складності пошуку зазвичай вибирається база даних, яка забезпечує стандартні стандартні методи для збереження даних, запитів і т.д. .

Для досягнення вимог до пункту 2 існують різні методи, що дозволяють здійснювати обмін даними між системами, включаючи XML, JSON тощо.

Ці методи дозволяють визначати структуру даних користувачем і є незалежною від мови, що дозволяє різній системі обмінюватися даними.

У вашому конкретному випадку ви правильно використовуєте JSON, описуючи набір музичних подій. Хоча ви могли зберігати дані у форматі JSON, шукаючи ці дані, оскільки кількість музичних подій зростатиме буде повільно і неефективно.

Використовуючи підхід до розділення проблем, тоді кращим підходом є збір даних, зберігання в базі даних, виконання запиту на основі введення користувача в базу даних, а потім повернення результатів у форматі JSON на сторону клієнта для відображення даних.

Додатковою проблемою підходу JSON є зміна структури даних. Наразі ваша структура порівняно проста. Ви можете використовувати цю структуру протягом декількох місяців, і тоді буде визначено додаткове поле. Що ви робите з усіма існуючими об'єктами JSON? Поновити їх було б проблематично.

Якщо ви використовували базу даних, то додавання додаткового поля є відносно простим, і лише ваш код для створення JSON потрібно буде змінити в одному місці, таким чином, ви отримаєте все нове JSON з новим полем.

Коротше кажучи, використовуйте кожен фрагмент технології для того, що було розроблено для JSON для обміну даними та Бази даних для збереження даних.


0

Я думаю, ви матимете кращий успіх у використанні NoSQL, ніж SQL для зберігання цих даних, через запити, які вам потрібно виконати.

Окрім того, що деякі дані є чисто реляційними, це ще не означає, що їх потрібно зберігати в деяких RDBMS (SQL). Реляційні дані IMO краще перекладатимуть у бази даних графіків.

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

Але на закінчення ви отримаєте більше свободи, використовуючи NoSQL (таким чином, JSON або якийсь інший формат, підтримуваний базою даних), враховуючи, що ви можете змінити схему в майбутньому, не враховуючи вже збережені дані.

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


0

Я думаю, ви повинні використовувати обидва, і я не вважаю це рішенням "проти".

Реляційна база даних має сенс для швидкого та ефективного зберігання та пошуку даних, що мають реляційні властивості.

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

Тому я рекомендую SQL для зберігання даних та JSON для формату передачі даних.

Це правда, що існують параметри ключових значень noSQL, такі як Mongo, Redis тощо. Вони мали б перевагу, можливо, більш просте відображення у форматі JSON, але їх, як правило, трохи складніше використовувати для запитів. Основна перешкода з ними - незнайомість загальним ІТ-спільнотою, особливо в порівнянні з SQL, який настільки відомий і має величезний масив ресурсів та знань, доступних майже для кожної уявної ситуації.


Якби я міг знайти програміста з хорошим розумінням того, як використовувати метод зберігання ключових значень noSQL у запитах, ви б сказали, що це було б найважливішим завданням для подолання використання JSON як формату зберігання даних?
zgall1

Надіюсь, це було б просто тому, що єдина структура даних погана / бідна, ніж середня. розробники знають, що це реляційна база даних. Але це стосується середньої якості розробників, і про те, як вони навчилися уникати навчання, NoSQL був би правильним вибором для нереляційних даних ... кожен раз, насправді, розробникам це часто простіше, якщо припустити, що ваші дані справді не -реляційні. АЛЕ Ви повинні отримати правильний вибір БД, NoSQL зробити або перервати на початковий вибір .. і наскільки добре він відповідає даним.
Дж. М. Бекер
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.