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

Я думаю о создании веб-приложения для управления данными с открытым исходным кодом для различных типов данных.

Привилегированный пользователь должен иметь возможность

добавить новые типы сущностей (например, "пользователь" или "семейство" )
добавить новые свойства к типам сущностей (например, 'gender' to 'user')
удалить/изменить объекты и свойства

Это будут обычные задачи для привилегированного пользователя. Он сделает это через веб-интерфейс приложения. В конце концов, все данные должны быть доступны для поиска и сортировки всеми типами пользователей приложения. Меня беспокоят два вопроса:

a) Как данные должны храниться в базе данных? Должен ли я динамически добавлять/удалять таблицы базы данных и/или столбцы во время выполнения?

Я не эксперт по базам данных. Я застрял в воображении, что с точки зрения реляционных баз данных приложение должно иметь возможность динамически добавлять/удалять таблицы (сущности) и/или столбцы (свойства) во время выполнения. И мне не нравится эта идея. Аналогично, я думаю, следует ли обрабатывать такие динамические данные в базе данных NoSQL.

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

b) Как реализовать это в Python с использованием ORM или NoSQL?

Если вы рекомендуете использовать реляционную модель базы данных, я бы хотел использовать SQLAlchemy. Однако я не вижу, как динамически создавать таблицы/столбцы с ORM во время выполнения. Это одна из причин, почему я надеюсь, что существует гораздо лучший подход, чем создание таблиц и столбцов во время выполнения. Является ли рекомендуемая модель базы данных эффективной с помощью SQLAlchemy?

Если вы рекомендуете использовать базу данных NoSQL, какой? Мне нравится использовать Redis - можете ли вы представить эффективную реализацию на основе Redis?

Спасибо за ваши предложения!

Изменить в ответ на некоторые комментарии:

Идея состоит в том, что все экземпляры ( "строки" ) определенного объекта ( "таблица" ) имеют один и тот же набор свойств/атрибутов ( "столбцы" ). Тем не менее, это будет совершенно корректно, если некоторые экземпляры имеют пустые значения для определенных свойств/атрибутов.

В основном пользователи будут искать данные через простую форму на веб-сайте. Они запрашивают, например. все экземпляры объекта E с свойством P, имеющим значение V выше T. Результат может быть отсортирован по значению любого свойства.

Наборы данных не станут слишком большими. Следовательно, я думаю, что даже самый глупый подход все равно приведет к созданию рабочей системы. Тем не менее, я энтузиаст, и я бы хотел применить современные и соответствующие технологии, а также хотел бы знать о теоретических узких местах. Я хочу использовать этот проект, чтобы собрать опыт разработки "Pythonic", современного, масштабируемого и надежного веб-приложения.

Я вижу, что первые комментарии, как правило, рекомендуют подход NoSQL. Хотя мне действительно нравится Redis, похоже, было бы глупо не использовать модель документа/коллекции Mongo/Couch. Я искал mongodb и mongoengine для Python. Поступая таким образом, я делаю шаги в правильном направлении?

Изменить 2 в ответ на некоторые ответы/комментарии:

В большинстве ваших ответов я пришел к выводу, что динамическое создание/удаление таблиц и столбцов в реляционном изображении не. Это уже ценная информация. Кроме того, существует мнение, что вся идея динамической модификации объектов и свойств может быть плохим дизайном.

Как именно этот динамический характер должен быть основной целью/особенностью приложения, я не отказываюсь от этого. С теоретической точки зрения я согласен с тем, что выполнение операций в динамической модели данных должно быть медленнее, чем выполнение операций в статической модели данных. Это совершенно нормально.

Выраженный абстрактным способом, приложение должно управлять

расположение данных, то есть "динамический список" допустимых типов сущностей и "динамический список" свойств для каждого допустимого типа сущности
сами данные

Я ищу интеллектуальный и эффективный способ реализовать это. Из ваших ответов, похоже, что NoSQL - это путь, который является еще одним важным заключением.

Ответ 1

Итак, если вы концептуализируете свои сущности как "документы", то вся эта проблема хорошо отображает решение без sql. Как прокомментировано, вам нужно будет иметь какой-то модельный слой, который находится поверх хранилища документов и выполняет такие задачи, как валидация, и, возможно, применяет (или поощряет) какую-то схему, потому что нет никакого подразумеваемого требования к бэкэнд, чтобы объекты в та же коллекция (параллельно с таблицей).

Предоставление привилегированным пользователям возможности изменить концепцию схемы (а не просто добавлять поля к отдельным документам), которые легко поддерживать) будет представлять собой немного сложную задачу - вам придется обрабатывать перенос существующих данных в соответствии с новыми схема автоматически.

Считывая свои изменения, Mongo поддерживает поиск/заказ, который вам нужен, и предоставит вам поддержку "пустых ячеек" (документов, не имеющих определенного ключа), которые вам нужны.

Если бы я был вами (и на данный момент я работаю над похожим, но более простым продуктом), я бы придерживался Монго и заглянул в облегченную веб-фреймворк, например Flask, чтобы обеспечить интерфейс. Вы будете сами по себе, чтобы предоставить модель, но вы не будете бороться с неявным выбором моделирования.

Ответ 2

Выбор SQL или NoSQL не является вашей проблемой. Вам нужно больше узнать о дизайне базы данных в целом. Как вы сказали, вы не эксперт по базам данных (и вам не обязательно), но вы абсолютно должны изучить немного больше парадигмы РСУБД.

Это распространенная ошибка любительских энтузиастов в выборе решения NoSQL. Иногда NoSQL является хорошим решением, наиболее времени не является.

Возьмем, к примеру, MongoDB, о котором вы упомянули (и является одним из хороших решений NoSQL, которые я пробовал). Без схемы, не так ли? Err.. не совсем. Вы видите, что когда-то нет схемы без ограничений, проверки и т.д. Но ваши модели приложений/сущности не могут стоять на воздухе! Разумеется, будут какие-то ограничения и логика проверки, которые вы будете реализованы на вашем программном уровне. Поэтому я даю вам mongokit! Я просто приведу из описания проекта этот маленький бит

MongoKit приносит структурированную схему и уровень проверки поверх отличный драйвер pymongo

Хммм... неструктурированный стал структурированным.

По крайней мере, у нас нет права SQL? Да, мы этого не делаем. У нас есть другой язык запросов, который, конечно, уступает SQL. По крайней мере, вам не нужно прибегать к карте/сокращению для основных запросов (см. CouchDB).

Не поймите меня неправильно, но у NoSQL (и особенно MongoDB) есть свои цели, но в большинстве случаев эти технологии используются по неправильной причине.

Кроме того, если вы заботитесь о серьезной сохранности и целостности данных, забудьте о решениях NoSQL. Все эти технологии слишком экспериментальны, чтобы сохранить ваши серьезные данные. Изучив немного, кто (кроме Google/Amazon) использует решения NoSQL, и для чего именно вы обнаружите, что почти никто не использует его для хранения своих важных данных. Они в основном используют их для регистрации, сообщений и данных в реальном времени. В принципе, что-то, что нужно для загрузки некоторого бремени из хранилища SQL db.

Redis, на мой взгляд, - это, наверное, единственный проект, который переживет взрыв NoSQL невредимым. Может быть, потому, что он не рекламирует себя как NoSQL, а как хранилище с ключом, что является именно тем, что есть, и довольно чертовски хорошо! Также они серьезно относятся к persistence. Это швейцарский армейский нож, но не очень хорошее решение для замены полностью вашей РСУБД.

Прошу прощения, я сказал слишком много:)

Итак, вот мое предложение:

1) Немного изучите модель РСУБД.

2) Django - хорошая структура, если большинство вашего проекта будет использовать СУБД.

3) Погрессивные камни! Также имейте в виду, что версия 9.2 принесет поддержку JSON. Вы можете сбросить все свои "динамические" свойства там, и вы можете использовать вторичное хранилище/двигатель для выполнения запросов (map/reduce) по указанным свойствам. Имейте торт и съешьте его тоже!

4) Для серьезных возможностей поиска рассмотрите специализированные механизмы, такие как solr.

РЕДАКТИРОВАТЬ: 6 апреля 2013 года

5) django-ext-hstore дает вам доступ к типу postgresql hstore. Это похоже в словарь python, и вы можете выполнять запросы на нем, с ограничением, которое вы не можете иметь вложенные словари в качестве значений. Также значение ключа может быть только типа string.

Удачи

Обновить в ответ на OP comment

0). Рассмотрим приложение "содержит данные" и уже использовано какое-то время

Я не уверен, если вы имеете в виду, что он содержит данные в устаревших dbms или вы просто пытаясь сказать, что "представьте, что БД не пуста и рассмотрим следующие моменты...". В первом случае это проблема миграции (совершенно другой вопрос), в последнем, хорошо ОК.

1) Администратор удаляет сущность "family" и все связанные данные

Почему кто-то полностью исключает сущность (таблицу)? Либо ваше приложение имеет отношение к семьям, домам и т.д., Либо нет. Разумеется, удаление экземпляров (строк) семейств понятно.

2) Администратор создает объект "дом"

То же самое С# 1. Если вы вводите совершенно новый объект в своем приложении, то, скорее всего, он будет инкапсулировать семантику и бизнес-логику, для которой должен быть написан новый код. Это происходит со всеми приложениями по мере их развития во времени и, конечно же, требует создания новой таблицы или, возможно, ALTER с существующей, Но этот процесс не является частью функциональности вашего приложения. то есть это происходит редко, и это проблема миграции/рефакторинга.

3) Администратор добавляет свойства "полы", "возраст",..

Почему? Разве мы не знаем заранее, что у House есть полы? Что a User имеет пол? Добавление и удаление, динамически, этот тип атрибутов не является особенностью, а конструктивным недостатком. Это часть этапа анализа/проектирования для идентификации ваших объектов и их соответствующих свойств.

4) Привилегированный пользователь добавляет некоторые дома.

Да, он добавляет экземпляр (строку) к существующей сущности (таблице) House.

5) Пользователь ищет все дома с не менее чем пятью этажами дешевле, чем 100 $

Совершенно корректный запрос, который может быть достигнут с помощью SQL или NoSQL. В джанго это будет что-то в этом роде:

House.objects.filter(floors__gte=5, price__lt=100)

при условии, что House имеет атрибуты floors и price. Но если вам нужно делать текстовые запросы, то ни SQL, ни NoSQL не будут достаточно удовлетворительными. Потому что вы не хотите использовать faceting или stemming по своему усмотрению! Вы будете использовать некоторые из уже обсуждавшихся решений (Solr, ElasticSearch и т.д.).

Некоторые общие замечания:

Примеры, которые вы давали о Houses, Users и их свойствах, не требуют какой-либо динамической схемы. Возможно, вы упростили свой пример, просто чтобы указать на свою мысль, но вы говорите о добавлении/удалении Entities(tables), как будто это строки в db. Сущности должны быть большой сделкой в приложении. Они определяют цель вашего приложения и его функциональность. Таким образом, они не могут меняться каждую минуту.

Также вы сказали:

The idea is that all instances ("rows") of a certain entity ("table") share the same set of properties/attributes ("columns"). However, it will be perfectly valid if certain instances have an empty value for certain properties/attributes.

Это похоже на обычный случай, когда атрибут имеет null=True.

И как последнее замечание, я хотел бы предложить вам попробовать оба подхода (SQL и NoSQL), поскольку, похоже, ваша карьера не зависит от этого проекта. Это будет опыт бенефициара, поскольку вы поймете из первых рук, минусы и плюсы каждого подхода. Или даже как "смешать" эти подходы вместе.

Ответ 3

То, о чем вы просите, является общим требованием во многих системах - как расширить базовую модель данных для обработки пользовательских данных. Это популярное требование для упакованного программного обеспечения (где он обычно обрабатывается в одну сторону) и программного обеспечения с открытым исходным кодом (где он обрабатывается по-другому).

Более ранний совет, чтобы узнать больше о дизайне РСУБД, как правило, не может повредить. Что я буду добавлять к этому, не попадайте в ловушку повторной реализации реляционной базы данных в вашей собственной модели данных конкретных приложений! Я видел это много раз, обычно в упакованном программном обеспечении. Не желая подвергать основную модель данных (или разрешение на ее изменение) конечным пользователям, разработчик создает общую структуру данных и интерфейс приложения, который позволяет конечному пользователю определять сущности, поля и т.д., Но не использовать средства РСУБД. Это, как правило, ошибка, потому что трудно быть почти таким же тщательным или без ошибок, как то, что может принести вам закаленная СУБД, и это может занять много времени. Это заманчиво, но ИМХО не очень хорошая идея.

Предполагая, что изменения модели данных являются глобальными (совместно используемыми всеми пользователями после того, как администратор сделал их), способ, которым я хотел бы подходить к этой проблеме, - создать интерфейс приложения, чтобы сидеть между пользователем-администратором и РСУБД, и применять любые правила вам необходимо применить изменения модели данных, но затем передать окончательные изменения в СУБД. Например, у вас могут быть правила, которые говорят, что имена сущностей должны следовать определенному формату, новым сущностям разрешено иметь внешние ключи к существующим таблицам, но всегда следует использовать правило DELETE CASCADE, поля могут быть только определенных типов данных, все поля должны иметь значения по умолчанию и т.д. У вас может быть очень простой экран с просьбой предоставить имя объекта, имена полей и значения по умолчанию и т.д., а затем сгенерировать код SQL (включая все ваши правила), чтобы внести эти изменения в вашу базу данных.

Некоторые общие правила и способы их решения будут такими, как:

- если поле не является нулевым и имеет значение по умолчанию, а в таблице уже есть записи, прежде чем это поле было добавлено администратором, обновите существующие записи, чтобы иметь значение по умолчанию при создании поля (несколько шагов - добавить поле, разрешающее null, обновить все существующие записи, изменить таблицу для принудительного выполнения не null w/default) - в противном случае вы не сможете использовать правило целостности на уровне поля)

- новые таблицы должны иметь различный шаблон именования, чтобы вы могли продолжать отличать вашу базовую модель данных от модели данных, расширенной пользователем, т.е. основные и пользовательские пользователи имеют разные владельцы RDBMS (dbo. vs. user.) или префиксы (нет для ядра, __ для пользовательских) или somesuch.

- нормально добавлять поля в таблицы, которые находятся в базовой модели данных (если они допускают значения нулей или имеют значение по умолчанию), и для администратора это нормально, чтобы удалить поля, добавленные администратором в таблицы основных моделей данных, но admin не может удалить поля, которые были определены как часть основной модели данных.

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

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

Чтобы ответить на ваши вопросы напрямую:

(1) Да, добавьте таблицы и столбцы во время выполнения, но подумайте о правилах, которые вам понадобятся, чтобы ваше приложение могло работать даже после добавления пользовательских данных и выбрать способ принудительного применения этих правил ( через приложение или через DB/хранимые procs или что-то еще) при обработке изменений таблицы и поля.

(2) Эта проблема не сильно зависит от вашего выбора механизма SQL и NoSQL. В каждом случае у вас есть базовая модель данных и расширенная модель данных. Если вы можете проектировать приложение для ответа на динамическую модель данных (например, добавлять новые поля к экранам, когда поля добавляются в таблицу БД или что-то еще), ваше приложение будет хорошо реагировать на изменения как в основной, так и в пользовательской модели данных. Это интересная задача, но не сильно зависит от выбора стиля реализации БД.

Удачи!

Ответ 4

Может быть, не имеет значения механизм персистентности ваших объектов модели (RDBMS, NoSQL и т.д.). Технология, которую вы ищете, является индексом для поиска и поиска ваших объектов.

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

Посмотрите на шаблон модели объекта-атрибута (EAV). Это может быть реализовано через SQLAlchemy для использования базы данных РСУБД как средство хранения вертикальной схемы и данных и их связывания.

Вы входите в поле Semantic Web Programming, возможно, вам стоит прочитать менее первую главу этой книги:

Программирование Семантический веб

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

Мое мнение состоит в том, что лучшие реализации этого могут быть достигнуты в настоящее время с графическими базами данных, и очень хорошим примером текущих реализаций являются Berkeley DB (некоторые реализации LDAP используют Berkeley DBs в качестве технической реализации для этого проблема индексирования.)

Однажды в графической модели вы можете делать какие-то "выводы" на графике, создавая БД с некоторым "интеллектом". Пример этого изложен в книге.