Созданная пользователем структура базы данных: нереляционные или реляционные базы данных?

Question

Я хочу, чтобы в моей базе данных были динамические поля.

Например: я хочу создать приложение для пользователей, чтобы создавать свои собственные формы.

Пользователь может создавать следующие формы:

Личный профиль:

• ФИО
• Улица
• Работа
• Телефон
  • Главная
  • Работа
• Интересы
  • Проценты 1
  • Проценты 2
  • Проценты 3

Работа:

• Имя
• Фамилия
• Работа
  • Департамент
    • Специальность 1
    • Специальность 2
  • Департамент
    • Специальность 1
    • Специальность 2

Страна:

• Соединенные Штаты
  • Государство
    • Нью-Йорк
      • Города
        • Нью-Йорк
        • Foo
    • Alabama
      • Города
        • Бар
        • Баз

Как видите, это очень динамичная структура:

• Нет предопределенного количества полей
• Нет предопределенных имен полей
• Пользователь создает структуру базы данных

Итак, мне интересно, какая база данных лучше для этого: реляционная (mysql / postgresql) или нереляционная, например mongodb / couchdb / cassandra, или даже XML-базы данных, такие как xindice?

И даже если я выберу для этого нереляционные базы данных, было бы разумно хранить на нем информацию, критичную для безопасности, такую ​​как информация о клиентах и ​​счетах?

Я слышал, как люди говорят, что если ваша информация требует уникальности, используйте реляционную базу данных. «Мы не хотим рисковать, чтобы выставлять счета нашим клиентам дважды». Какие проблемы в нереляционных базах данных они на самом деле означают? Разве вы не можете хранить уникальные данные в нереляционных базах данных?

Еще одна вещь, о которой я думал: не означает ли сохранение данных в нереляционных базах данных, что у меня будут дублированные записи?

Рассмотрим этот пример:

Категория:

• Office

  • Приложение
    • Textmate
      • Автор: Foobar
      • Цена: 120
    • Foo
      • Автор: Foobar
      • Цена: 120

• Office

  • Приложение
    • Textmate
      • Автор: Foobar
      • Цена: 120
    • Бар
      • Автор: Foobar
      • Цена: 120

Как видите, существуют ситуации для идентичных записей. Как с этим справляются нереляционные базы данных? Я так привык к реляционным базам данных.

Подводя итог моим вопросам:

• Какой тип базы данных для созданной пользователем структуры базы данных?
• Являются ли нереальные базы данных для хранения критически важной информации?
• Как нереальные базы данных обрабатывают дубликаты?

Answer 1

Я настоятельно рекомендую вам проверить CouchDB для этого.

1. Вы общаетесь с CouchDB, используя простой REST API. Другими словами, это « Сделано из Интернета», а не просто бэк-бэнд, такой как MongoDB и другие. CouchDB может фактически обслуживать формы и получать заявки, поскольку имеет встроенный веб-сервер.
2. Будучи хранилищем документов JSON, он хорошо подходит для хранения структурированных данных, но без схемы. (Формы и их представления на самом деле являются документами, и имеет больше смысла моделировать их таким образом, ИМО.)
3. Вы можете легко сохранить документ JSON, описывающий каждую веб-форму в том же «ведре», что и отправленные формы. (CouchDB может даже анализировать формы POST и превращать их в документы JSON, как вам удобно. Например, иметь автоматическую отметку о времени отправки форм).
4. Вы можете написать так называемую функцию "_show", чтобы фактически генерировать HTML-код каждой формы в CouchDB. Также проверьте "_update" и функции проверки.
5. Он имеет необходимые функции безопасности.
6. Конфликты документов можно легко идентифицировать. Более того, CouchDB автоматически определяет «выигрышную» версию документа, но вы по-прежнему будете иметь доступ к «проигрышным» версиям документа (пока вы не скажете CouchDB уплотнить базу данных, которая удаляет старые ревизии).
   • Относительно уникальности: вместо того, чтобы CouchDB генерировал уникальные документы _id, вы захотите назначить _id, который действительно представляет уникальную отправку формы. Если каждому пользователю разрешена только одна отправка для каждой формы, используйте что-то вроде этих строк для каждого документа JSON, созданного из отправки формы: submission:user:5:form:a3df2a712

Используя CouchDB, вы можете избежать трудностей динамического создания уникальных таблиц для каждой формы, которую может создать пользователь.

Answer 2

Если ваши данные хорошо соответствуют реляционной модели, но вам нужно хранить некоторые динамически отформатированные данные, которые не являются огромными, тогда вам, вероятно, будет лучше хранить JSON, XML или аналогичные данные в виде столбца.Делая это, вы теряете некоторые преимущества первоклассной типизации SQL (индексация, проверка ограничений внешнего ключа, проверка типов и т. Д.), Но это хорошо для хранения динамически структурированных документов, когда ваши запросы не заботятся об их внутренних элементах.

Если вы заинтересованы в хранении в основном реляционных данных с оттенком JSON / XML / и т. Д., Я рекомендую обратиться к PostgreSQL.PostgreSQL имеет тип данных XML, но я не рекомендую использовать его, так как ненавижу XML: P.Никто не мешает вам хранить JSON в поле TEXT, но вскоре PostgreSQL получит тип данных JSON с поддерживающими функциями.Модуль hstore contrib обеспечивает эффективный способ хранения пар ключ / значение, а также обеспечивает поддержку полнотекстового индекса.

Несмотря на то, что перетаскивание JSON или аналогичного в столбец базы данных SQL выглядит по-другомуреляционной модели, как правило, вам все равно лучше делать это (когда это имеет смысл!).В противном случае вам придется объяснить всю схему вашего приложения базе данных, что приведет к большому количеству кода SQL и кода отображения базы данных, который на самом деле ничего не делает.

Answer 3

Выбор базы данных зависит больше от того, что и как вы хотите запросить, и от того, что вы хотите сохранить.Все базы данных позволят вам хранить практически все, что вы захотите.

СУБД особенно хороши при выполнении запросов на основе реляционной модели и делают это разумно произвольно.С помощью специальных фильтров и объединений вы можете творить всякие чудеса.

Базы данных NOSQL, как правило, менее гибки в своих запросах, но хорошо справляются с другими задачами (например, лучше работают с "неструктурированными" данными дляпример).

Учитывая то, что вы разместили здесь, я бы просто использовал базу данных SQL и определял таблицы так, как этого хочет пользователь.Настройте индексы, настройте запросы.Звучит как настоящий ежу понятно для меня.БД SQL легко обрабатывает все эти «определения полей на лету», потому что ... это то, что они делают.Так что используйте это.