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

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

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

The live music event (described in full using the JSON schema at the bottom of this question) is an object that stores data such as where the event will take place, the time/date of the event and the cost of the event. The live music event object has both one-to-one (event--> name, event --> description) and one-to-many (event--> venues, event--> dates, event--> ticket types) relationships. Furthermore, the event object can contain one or more performer IDs, which link to the performer object. The performer object stores data on musicians who are performing at the live music event.

Дані будуть запитуватися користувачами за допомогою простих ("Знайти події з назвою" 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"
        }                                       
    }
}   
24
JSON не є форматом зберігання. Правда, ви можете зберігати дані за допомогою текстових файлів, але тільки за найпростіших сценаріїв. JSON, що є "новими", ніж реляційні бази даних, не має ніякого відношення до вашого рішення.
додано Автор sgwill, джерело
@PeterKrauss: Можливо, було б більш точним для мене сказати, що JSON - це не база даних, яка з нею порівнювала ОП. У всякому разі, ОП розумів, що я маю на увазі.
додано Автор sgwill, джерело
@RobertHarvey і виборці, в даний час (2017) JSON є форматом магазину : див. PostgreSQL 9.6+ ... Основний з ~ 2012, професійний і зрілий з кінця 2015 року (тип даних JSONb).
додано Автор Manuel, джерело
Ви не могли б запрограмувати свій запит на пошук значень у відповідному масиві?
додано Автор Brian, джерело
Я розумію, що це не формат зберігання. Я мав на увазі, що я міг би використовувати JSON-об'єкт MongoDB або Postgre для зберігання даних у форматі JSON.
додано Автор Brian, джерело
Я не знаю вимог сайту, але хотів би шукати за: виконавцем, місцем проведення і, можливо, датами. Чи буде це проблемою, оскільки вони зберігаються в типах масивів?
додано Автор bstpierre, джерело
Дивіться також подібні stackoverflow.com/questions/ 31972056/& hellip;
додано Автор Engin Atik, джерело
Це потребує деякого оновлення людини !!!
додано Автор budwiser, джерело

6 Відповіді

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

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

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

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

'Go not to the elves for counsel, for they will say both no and yes.' -- Frodo

40
додано

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

  • Сховище
  • Пошук і вилучення

Зберігання

There are plenty of opinions on why to use no-sql or RDBMS store for your data. One of the most important items that we thought was useful is that we can easily define and store json objects in Зберігання without having to worry about defining it's full structure or relationship between different types of objects. Some of the other reasons to use a NoSql db would be ability to auto shard data, location based Пошукes and easy maintenance. There are many good NoSql databases out there, my personal preference is MongoDB. However, if you have not used NoSql database before, there is a definite learnign curve as you learn to re-wire your mind. Most of us have been using RDBMS for a while now and it takes conscious effort to break out of that habit. Plus you will find yourself wanting to redo your data model as you proceed along with your efforts and have a better usnderstanding of concepts. If ability to refactor or remodel is not an options for your project I would suggest to stick with what you already know best.

Пошук

If you intend to provide any kind of Пошук that is usable, I strongly suggest that you use a dedicated text Пошук engine such as SOLR to perform your Пошукes. Text Пошукes are slow and if you have multiple shards then even more so slower. SOLR supports blazing fast text Пошукes including weighted Пошук params, location based Пошукes and much more. SOLR however is not suited as a primary store of your data. This does mean that you will have to create mechanisms for dual insert and update to both you primary database and your SOLR layer when adding or updating events. Plus you will have to keep the SOLR later updated by removing any outdated/ended events.

Although this does seem like lot of extra work you will thank yourself for foresight of using a full text Пошук engine later on. None of the NoSql databases or RDBMS come close to performance and agility of SOLR/Lucene.

5
додано

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

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

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

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

3
додано

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

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

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

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

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

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

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

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

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

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

2
додано

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

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

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

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

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

0
додано
Якби я знайшов програміста з хорошим розумінням того, як у запитах використовувати метод зберігання ключів-значення noSQL, чи могли б ви сказати, що це було б найважливішим викликом для подолання використання JSON як формату зберігання даних?
додано Автор Brian, джерело
Б'юся об заклад, було б, просто тому, що єдина структура даних бідна/бідніша за-avg. розробникам відома реляційна база даних. Це приблизно середня якість розробників, і як вони навчилися уникати навчання, NoSQL було б правильним вибором для нереляційних даних ... кожен раз насправді, для розробників часто буває простіше, якщо ваші дані дійсно не -реляційні. АЛЕ ви повинні отримати правильний вибір БД, NoSQL це зробити або перерва на початковий вибір .. і наскільки добре він відповідає даним.
додано Автор TechZilla, джерело

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

Також тільки тому, що деякі дані є суто реляційними, це вже не означає, що вони повинні зберігатися в деяких СУБД (SQL). Реляційні дані IMO краще будуть переводитись у графічні бази даних.

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

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

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

0
додано
ІТ КПІ - JavaScript
ІТ КПІ - JavaScript
504 учасників

співтовариство javascript розробників в Telegram