Схема базы динамических данных

То, что Вы предлагаете, не является новым. Много людей попробовало его..., большинство нашло, что они преследуют "бесконечную" гибкость и вместо этого заканчивают с очень, намного меньше, чем что. Это - "мотель плотвы" проектирований баз данных - данные входят, но почти невозможно вывести его. Попытайтесь осмыслять запись кода для ЛЮБОГО вида ограничения, и Вы будете видеть то, что я имею в виду.

конечным результатом обычно является система, которую НАМНОГО более трудно отладить, поддержать, и полный проблем непротиворечивости данных. Это не всегда случай, но как правило, именно так он заканчивается. Главным образом, потому что программист (программисты) не видит, что эта железнодорожная авария прибывает, и не удается оборонительно кодировать против нее. Кроме того, часто заканчивается случай, что "бесконечная" гибкость действительно не настолько необходима; это - очень плохой "запах", когда команда разработчиков получает спецификацию, которая говорит "Черт возьми, что у меня нет подсказки, какие данные они собираются поместить здесь, таким образом позвольте им поместить БЕЗОТНОСИТЕЛЬНО"..., и конечные пользователи очень хорошо имеют предопределенные типы атрибута, которые они могут использовать (кодируйте универсальный телефон # и позвольте им создать любой # их - это тривиально в приятно нормализованной системе и поддерживает гибкость и целостность!)

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

то, Почему начинаются с разногласиями, сложило так много против Вас, хотя?

не верят мне? Google "Одна Истинная Таблица поиска" или "единственный дизайн таблицы". Некоторые хорошие результаты: http://asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:10678084117056

http://thedailywtf.com/Comments/Tom_Kyte_on_The_Ultimate_Extensibility.aspx?pg=3

http://www.dbazine.com/ofinterest/oi-articles/celko22

http://thedailywtf.com/Comments/The_Inner-Platform_Effect.aspx?pg=2

В прошлом я выбрал опцию C - Составление 'длинной, узкой' таблицы, которая хранит динамические значения столбцов как строки, которые тогда должны вертеться для создания 'короткого, широкого' набора строк, содержащего все значения для определенного объекта. . Однако я использовал ORM, и это ДЕЙСТВИТЕЛЬНО сделало вещи болезненными. Я не могу думать, как Вы выполнили бы в нем, скажем, LinqToSql. Я предполагаю, что должен был бы создать Хеш-таблицу для ссылки на поля.

@Skliwz: я предполагаю, что он больше интересуется разрешением пользователям создать пользовательские поля.

sql уже позволяет изменять Вашу схему: команда ALTER.

просто имеют таблицу, которая перечисляет поля, которые пользователям не разрешают изменить и записать, что хороший интерфейс для ИЗМЕНЯЕТСЯ.

Создайте 2 базы данных

• , DB1 содержит статические таблицы и представляет "реальное" состояние данных.
• DB2 свободен для пользователей сделать с тем, как они желают - они (или Вы) должны будут записать код для заполнения их таблиц нечетной формы от DB1.

Звуки мне как то, что Вы действительно хотите, являются своего рода "метасхемой", схемой базы данных, которая способна к описанию гибкой схемы для того, чтобы хранить фактические данные. Динамические изменения схемы раздражительны и не что-то, что Вы хотите смешать с, особенно не, если пользователям разрешают внести изменение.

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

Для разъяснения то, что я подразумеваю под "метасхемой":

CREATE TABLE data (
    id INTEGER NOT NULL AUTO_INCREMENT,
    key VARCHAR(255),
    data TEXT,

    PRIMARY KEY (id)
);

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

Смысл наличия реляционного DB бережно хранит Ваши данные и последовательный. Момент Вы позволяете пользователям изменять схему, там идет Ваша целостность данных...

, Если бы Ваша потребность состоит в том, чтобы хранить гетерогенные данные, например, как сценарий CMS, я предложил бы хранить XML, проверенный XSD подряд. Конечно, Вы теряете производительность и легкие возможности поиска, но это - хороший компромисс, по моему скромному мнению.

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

Я сделал это в реальном проекте:

база данных состояла из одной таблицы с одним полем, которое было массивом 50. Это имело индексный набор 'слова' на нем. Все данные были без типов, таким образом, 'словарь' работал как ожидалось. Числовые поля были представлены как символы, и фактическая сортировка была сделана в стороне клиента. (Это все еще возможный иметь несколько полей массива для каждого типа данных в случае необходимости).

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

Преимущества:

1. можно перестроить и добавить/удалить столбцы динамично, никакую потребность в дампе/перезагрузке базы данных. Любые новые данные столбца могут быть установлены на начальное значение (фактически) в нулевое время.
2. Фрагментация минимальна, так как все записи и таблицы являются тем же размером, иногда это дает лучшую производительность.
3. Вся схема таблицы является виртуальной. Любая логическая схема stucture возможна (даже рекурсивный, или объектно-ориентированный).
4. Это хорошо для "неперезаписываемого, читайте главным образом, no-delete/mark-as-deleted" данные (большинство веб-приложений на самом деле похоже на это).

Недостатки:

1. Индексация только полными словами, никаким сокращением,
2. Сложные запросы возможны, но с небольшим снижением производительности.
3. Зависит от того, поддерживает ли Ваша предпочтительная система баз данных массивы и словари (она была реализована В прогрессе RDBMS).
4. Реляционная модель находится только в уме программиста (т.е. только во времени выполнения).

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

Я знаю, что модели, обозначенные в вопросе, используются в производственных системах на всем протяжении. Довольно большой используется в крупном учреждении университета/обучения, на которое я работаю. Они конкретно используют долгий узкий подход таблицы для отображения, данные, собранные многими, варьировались системы сбора данных.

кроме того, Google недавно выпустил их внутренний протокол совместного использования данных, буфер протокола, как открытый исходный код через их сайт кода. Система баз данных, смоделированная на этом подходе, была бы довольно интересна.

Проверка следующее:

Google Protocol Buffer

модели

xml поле со строгим контролем типов в MSSQL работало на нас.

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

Если вам действительно нужно позволить своим клиентам делать это, вот несколько советов:
- Создайте надежный инструмент администрирования для выполнения изменений схемы и не допускайте внесения этих изменений каким-либо другим способом.
- Сделайте это административной функцией; не позволяйте обычным пользователям получить к нему доступ.
- Регистрируйте каждую деталь о каждом изменении схемы. Это поможет вам отладить проблемы, а также предоставит вам данные CYA, если клиент сделает что-то глупое.

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