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

Question

Для приложения мы собираем определенные данные формы. Пользователь может включать различные разделы по желанию.

Тип данных, которые должны быть получены в каждом разделе, является индивидуальным для каждого раздела. Иногда они являются простыми словарями пар ключ-значение. Иногда они содержат подкомпоненты с отношениями «один ко многим» или «многие ко многим». Хотя число разделов может увеличиваться, для каждого раздела будет известна схема.

Раньше разделы формы были исправлены, поэтому мы могли просто жестко кодировать структуры таблиц для каждого раздела. У нас нет общего способа реализации разделов - это новый доступ к данным и таблицы для каждого нового раздела.

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

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

Вместо того, чтобы заново изобретать это, я предполагаю, что работа была проделана в схемах для эффективных систем типов, хранящихся в базе данных. Есть мысли / рекомендации?

Спасибо.

Answer 1

Если пользователю разрешено создавать свои собственные типы данных, то база данных, в которой они хранятся, больше не является реляционной базой данных. Попытка сохранить эти данные традиционным способом будет хаосом.

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

Answer 2

Джейсон

Я не уверен, что понимаю ваш вопрос. Это краткое изложение того, что я почерпнул после прочтения:

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

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

Извините, если это не то, что вы искали. Это мой первый пост с ответами на StackOverflow, так что я все еще изучаю его.

Удачи,

Michael