подключаемая архитектура хранилища данных

Question

У меня есть сменный инструмент управления системой. Архитектура такого рода вещей понятна (интерфейсы, публикация / подписка, ....). Как насчет хранилища данных, хотя. Что делают люди?

Мне нужны плагины, чтобы иметь возможность добавлять новые сущности, расширять существующие сущности, устанавливать новые отношения и т. Д.

Мои мысли (SQL), не обязательно хорошо продуманные

• каждый плагин просто расширяет схему, когда они установлены. В старые времена изменение схемы было большим нет-нет; теперь базы данных очень расслаблены об этом

• плагины имеют свои собственные таблицы. Если 2 из них имеют сущность (скажем) персона, то есть 2 таблицы p1_person и p2_person

• плагины имеют собственную базу данных

• придумать какую-то гибкую схему, в которой таблицы мягко набираются. Может быть, многие атрибуты упакованы в один атрибут. Конечная цель - создать одну большую таблицу с именем data, ключом имени таблицы и имени столбца и одним значением данных.

Не SQL

• объект БД. У меня нет опыта с этим. Кто-нибудь хочет передать опыт. db4o например. Могу ли я изменить «схему» объектов по мере развития приложения

NO-SQL

• это «где сейчас». Большинство из них, кажется, нацелены немного иначе, чем мои потребности. Кто-нибудь хочет передать опыт с этими

Извинения за открытый вопрос

Answer 1

Мое предложение - иди и прочитай о каркасе сущностей

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

Ваша идея одной большой таблицы с именемданные заставляют хомяков в моем компьютере плакать;)

Общая тенденция заключается в том, что схемы со слабым типом не используются, поскольку их невозможно отладить во время компиляции.То, что вы получаете от чего-то вроде структуры сущностей, - это строго типизированная extenislbe схема, которую вы можете кодировать, используя linq.

Объектные базы данных: как и вы, я не играл с ними массово - однако время, когдаЯ думал, что это было время, когда не было хорошего ORM для .net, и написание кода ado.net меня медленно убивало.

Что касается NO-SQL, то это базы данных, которые отвечают требованиям производительности.SQL работает плохо в ситуациях, здесь происходит много небольших записей.Я говорю плохо в тайне - он работает очень хорошо, но когда вы масштабируете миллионы одновременно работающих пользователей, все меняется.Я понимаю, что нет sql, что это нерационализированный формат, предназначенный для множества небольших быстрых операций записи и чтения.Масштаб сайтов, которые их используют, обычно очень велик.

ОК - в ответ

В настоящее время мне посчастливилось участвовать в проекте по созданию «зеленого поля», поэтому я использую EF для создания своей схемы.В других проектах я использую сценарии sql для обновления структур таблиц.Что касается реализации наследования таблиц в sql, то это очень легко, когда вы знаете эту концепцию, по сути, это отношение один ко многим с ограничением, которое будет когда-либо только 0-1.

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

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

Я не нашел замены для тщательного управления сценариями.