Использование реляционной базы данных против JSON-объекты для событий/данных о деятельности
Я работаю над проектом, где я пытаюсь решить между использованием стандартной реляционной базе данных SQL или объектов JSON для хранения данных о событиях или действиях.
В рамках проекта будут хранить данные на несколько типов событий, поэтому я решил просто описать один тип события за этот вопрос.
Живая музыка событие (описывается в полном объеме, используя схему JSON, в нижней части этот вопрос) - это объект, который хранит данные, такие как где будет проходить мероприятие, время/дата проведения и стоимость мероприятия. Живая музыка событие объект имеет один-к-одному (событие--> имя, событие --> описание) и один-ко-многим (событие--> места, события--> даты, события--> авиабилет типов) отношений. Кроме того, объект, событие может содержать один или более исполнителя идентификаторы, которые ссылаются на объект исполнителем. Объект исполнитель хранит данные на музыкантов, которые играют на живой концерт.
Данные будут запрашиваться пользователями, используя как простые (на"Найди меня событий с 'х' именем") и сложные (с"Найти меня событий с 'х' музыкальный жанр и 'м' затрат в радиусе 'з' от моего текущего местоположения и") запросы. Данные будут предоставляться пользователям через веб-форму.
Как вы можете видеть на определенных схем 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"
}
}
}
Я думаю, что ваш вопрос действительно сводится к: Когда я должен использовать подхода NoSQL и реляционных СУБД? Вы устроились на JSON начале (а в NoSQL-иш решение), возможно, потому, что вы've получили потребителей "Аякс".
Ответ, Конечно, когда использовать традиционные подходы и РСУБД's-это в основном о том, что тип данных, которые вы'вновь работает с потребителей и то, что вы ожидали. Если ваши данные по сути реляционной (довольно плоские иерархии, никаких странных типов данных, таких как изображения или аудио, предсказуемых отношений между схем, которые могут быть легко описаны в ключах), и ваши потребители, как ожидается, в конечном счете, людей, которые хотят делать бизнес-аналитику запросов (специальный запрос), то РСУБД является способом пойти. Это'ы довольно легко превратить запрос на представление JSON, так что это не'т существенно обременит ваш Аякс потребители -- это просто добавляет немного кодирования преобразования в конечные точки (остальное/мыло/что угодно). Наоборот, если ваши данные являются иерархические (глубокое схем), содержащую странные типы данных, такие как изображения, аудио, видео и т. д., там мало отношения между сущностями, и вы знаете, что конечные пользователи не будут заниматься Би, то в NoSQL/хранение JSON может быть уместным.
Конечно, даже эти общие рекомендации Не'т скала. Причина Google разработал Google для файловой системы HDFS и MapReduce (работы который был использован Дуг резки для создания платформы Hadoop в Yahoo), а позднее-сервис BigQuery (NoSQL-это ориентированный [схемы] способ управления "больших данных") был именно потому, что у них было много специальных Би запросы, и они не'т получить реляционных подходов для наращивания в Тера/Пета/Экса/Зетта/йотта Весы они пытаются управлять. Единственный практический подход для масштабирования, жертвуя некоторыми из специального запроса пользователя, что РСУБД обеспечивает, подставляя простой алгоритм (на основе MapReduce), которые могут быть закодированы достаточно легко для любого заданного запроса.
Приведенный выше схеме, мой вопрос был в основном такой: почему бы'т вы используете РСУБД? Я не'т вижу особой причины не. Наша профессия, как предполагается, машиностроительная, а не мода, так что наш инстинкт следует выбирать самое простое решение, которое работает, верно? Я имею в виду, конечные точки, возможно, придется сделать небольшой перевод, если ваши потребители Ajaxy, но ваши данные выглядит очень плоско и вполне вероятно, что бизнес-пользователи хотят сделать все виды специальных запросов на такие вещи, как музыкальные мероприятия (какое событие было самым посещаемым в пределах 50 км от нашей столицы в прошлом году?)
'идти не к эльфам за советом, ибо они говорят, как нет и да.' -- Фродо
Я считаю, что здесь больше вопросов, которые вы может быть искали. Существуют две основные проблемы здесь:
Хранение
Есть много мнений о том, почему использовать не-SQL и СУБД хранилище данных. Одним из самых важных предметов, которые мы думали, было полезно, что мы можем легко определить и хранить JSON-объектов в хранилище, не беспокоясь об определении его'полную структуру или взаимосвязи между различными типами объектов. Некоторые из других причин, чтобы использовать NoSQL БД будет возможности данных авто черепок, поиск местоположения и легкое обслуживание. Есть много хороших баз данных NoSQL там, мои личные предпочтения в MongoDB. Однако, если вы не использовали базы данных NoSQL и раньше, есть определенная кривая обучения, как вы узнаете, чтобы изменить свой ум. Большинство из нас уже используют СУБД для некоторое время теперь, и он принимает сознательное усилие, чтобы вырваться из этой привычки. Плюс вы окажетесь желая переделывать свою модель данных, как вы приступите вместе с вашими усилиями и лучше usnderstanding понятий. Если возможность рефакторинга или переделывать не является нужным для вашего проекта я рекомендую придерживаться того, что тебе уже лучше знать.
Поиск
Если вы намерены предоставлять любого вида поиска, которые можно использовать, я настоятельно рекомендую вам использовать выделенный текст в поисковик, например, ГУМЗ для выполнения поиска. Текст поиски идут медленно, и если у вас есть несколько сегментов, то тем более медленнее. ГУМЗ поддерживает молниеносно полнотекстовый поиск, включая взвешенные параметры поиска, поиск местоположения и многое другое. Однако ГУМЗ не подходит в качестве основного хранилища данных. Это означает, что вы должны создать механизмы для двойной Insert и Update как вы первичной базы данных и ГУМЗ слоя при добавлении или обновлении событий. Плюс вам придется идти позже ГУМЗ обновляется путем удаления устаревших/события закончились.
Хотя это, кажется, как много дополнительной работы вы будете благодарить себя за дальновидность использования полнотекстового поиска в дальнейшем. Никто из NoSQL баз данных и СУБД вплотную подошли к производительности и гибкости ГУМЗ/в Lucene.
Во-первых, если вы'вновь пытается Store данных JSON в любом месте, но не на базе NoSQL, я'd определенно не рекомендуется использовать JSON. Причина в том, что если вы храните ваши данные в JSON-файл, например, то это будет очень медленно, чтобы открыть его, разобрать его, перебрать и т. д.
Чтобы начать сказал, я могу уточнить свой вопрос: Какие плюсы и минусы NoSQL и RDBMS? И это уже отвечали тысячи раз на 'чистая.
Пересортицы вашего проекта, вы можете, конечно, использовать либо NoSQL или RDBMS; однако то, что я вообще могу рекомендовать вам думать из коробки и искать других, менее видимых факторов, которые могут помочь вам определиться между двумя вариантами. Попробовать, чтобы увидеть, какой вариант мог бы ускорить развитие? Который больше подходит для других членов команды - если вы не являетесь единственным разработчиком. Если вы'повторно продать этот, который дешевле, легче и, как правило, больше подходят для вашего номера-разработчик клиентам?
Таким образом, Вы сможете окончательно определиться, в какую сторону идти, иначе будет очень трудно решать, опираясь на предоставленную информацию, так как оба варианта вполне вписываются.
В большинстве приложений есть требования к
Для того чтобы достигнуть требований по пункту 1 метод сохранения данных не требуется. Как правило, если объем данных очень мал и тип данных является простым и не требует обширные возможности поиска, то простой структуры файла могут быть использованы. В качестве данных становится более сложным в XML (или даже в формате JSON) структура может быть использована с Данные до сих пор хранятся в файлах. Хотя поиск становится более проблематичным. С ростом объема данных и сложности поисковых запросов увеличивается база данных, как правило, выбирается который обеспечивает стандартных методов для сохранения данных, запросов и т. д. Базы данных, предназначенный для обработки больших объемов данных и их хранения,получения и быстрого и эффективного поиска данных.
Для того чтобы достигнуть требований пункта 2 Существуют различные методы, позволяющие обмен данными между системами, включая XML, JSON и т. д.
Эти методы позволяют структура данных определяется пользователем и зависит от языка, позволяющий разнородные системы для обмена данными.
В вашем конкретном случае, если вы правильно используете JSON описывает набор музыкальных событий. В то время как вы могли бы хранить данные в формате JSON поиск таких данных, как количество музыкальных событий растет будет медленным и неэффективным.
Используя разделение касается подхода, то лучше подход для сбора данных, хранения в базе данных, выполнить запрос на основе введенных пользователем данных в базе данных и затем возвращает результаты в формате JSON на стороне клиента для отображения данных.
Дополнительная проблема с подходом JSON-это изменение структуры данных. В настоящее время ваша структура является относительно простым. Вы можете использовать эту структуру в течение нескольких месяцев, а затем определены дополнительные поля. Что же ты тогда вообще со всех существующих объектов JSON ? Обновление данных будет проблематично.
Если вы использовали базу данных после добавления дополнительного поля является относительно простой и только ваш код, чтобы создать объект JSON должны быть изменены в одном месте, таким образом, давая вам все новые JSON новое поле.
Короче использовать каждую единицу техники за то, что он был разработан для JSON для обмена данными и базы данных для сохранения данных.
Я думаю, что вы будете иметь больший успех с использованием NoSQL, чем SQL для хранения данных, из-за запросов, что вам нужно сделать.
И только потому, что какие-то данные чисто реляционное не значит, это должно быть сохранено в некоторых СУБД (SQL) в качестве. Реляционных данных IMO перевел бы лучше в графовых БД.
Конечно, вы можете также писать запросы в SQL, но производительность будет ужасной из-за количества соединений вам потребуется (учитывая ваши данные будут нормализованы несколько, а не все в одну таблицу событий).
Но в заключение у вас будет больше свободы с помощью СУБД (таким образом, JSON или любой другой формат, поддерживаемый базой данных), учитывая, что вы можете изменить вашу схему в будущем, не принимая во внимание уже имеющиеся сведения.
Учитывая СУБД также можно посмотреть в графовых БД, если вы планируете использовать очень сложные запросы, поскольку это даст вам преимущества в создании их легко, а также выполнять их очень быстро.
Я думаю, что вы должны использовать обе, и я не'т вижу это как 'против' решение.
Реляционная база данных имеет смысл для быстрого и эффективного хранения и извлечения данных, который имеет реляционные свойства.
JSON-это отличный формат, потому что это простой, легкий и идеально подходит для передачи необработанных данных в очень простом формате с синтаксисом подходит для хранения и обмена текстовой информацией. Это's отличный для передачи небольших объемов данных между браузером и сервером. Это's не в таком удобном формате, чтобы начать использовать для реляционного типа запросов данных.
Поэтому я бы рекомендовал SQL для хранения данных и JSON формат данных.
Это правда, что есть ключ-значение в NoSQL варианты, такие как Монго, Redis и т. д. Они будут иметь преимущество, возможно, проще сопоставление в формате JSON, но, как правило, немного сложнее в использовании для запросов. Главное препятствие, с их незнанием Генеральной ИТ-сообщества, особенно когда по сравнению с SQL что и так известно и что такие ресурсы и знания, имеющиеся почти в любой ситуации можно себе представить.