Добавить новые столбцы в приложении asp .net

Question

Я сталкиваюсь с этим вопросом в новом небольшом проекте: Система, которая будет построена, позволит пользователю добавлять новые столбцы в таблицу в системе, и тогда пользователь сможет поддерживать данные, я думаю, что есть два способа реализовать это: 1) создайте несколько таблиц, включая таблицу «columns» с «columnName», columnValue, «datatype» и т. Д. Для хранения определения столбца, другую таблицу «XXCoumn» для хранения значения столбца (введенного пользователем) и пользователя хранилища процедура для запроса / обновления данных столбца. 2) создайте столбец в схеме таблицы, когда пользователь введет новый столбец, тогда ведение данных таблицы будет таким же, как обычно

Как вы думаете, ребята? или любое новое предложение?

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

Answer 1

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

1) Дизайн Entity-Attribute-Value (EAV) : этот параметр вы описываете, когда у вас есть таблица, в которой есть столбцы для ColumnName, Type и Value. Преимущество этого варианта заключается в возможности легко размещать неограниченное количество новых столбцов, но я обнаружил, что это болезненно, когда приходит время возвращать значимые данные обратно. Например, скажем, у вас есть строки в этой таблице EAV для {Color, varchar} {Red, Green, Blue} и {Size, varchar} {Small, Medium, Large}. Если вы хотите найти все маленькие зеленые элементы, вам нужно что-то вроде этого (конечно, непроверенный SQL):

SELECT * 
FROM ITEMS 
WHERE ITEMID IN (SELECT ITEMID 
                 FROM ITEM_ATTRIBUTES ATT INNER JOIN ITEM_VALUES VLS
                     ON ATT.AttributeID = VLS.AttributeID
                 WHERE ATT.ColumnName = 'Color' AND VLS.Value = 'Green')
  AND ITEMID IN (SELECT ITEMID 
                 FROM ITEM_ATTRIBUTES ATT INNER JOIN ITEM_VALUES VLS
                     ON ATT.AttributeID = VLS.AttributeID
                 WHERE ATT.ColumnName = 'Size' AND VLS.Value = 'Small')

Сравните это с фактическими столбцами в таблице предметов для цвета и размера:

SELECT *
FROM ITEMS
WHERE COLOR = 'Green' AND SIZE = 'Small'

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

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

3) Существующие пользовательские столбцы : я работал с несколькими приложениями, такими как CRM, которые предоставляют дюжину или более столбцов, уже имеющихся для определения пользователя. По сути, разработчики помещают в столбцы, такие как «Текст1», «Текст2», «Текст3», «Номер1», «Номер2» и т. Д. Затем пользователи предоставляют информацию заголовка и описания для этих столбцов, и именно это приложение использует для отображать цели. Преимущество этой модели заключается в простом извлечении данных, а также в заранее определенной схеме БД, которая должна упростить логику приложения. Проблемы целостности данных остаются, однако. Другим очевидным недостатком является то, что у вас закончатся предопределенные столбцы, чего вы обычно стараетесь избегать с помощью этого типа решения.

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

Answer 2

"Система, которая будет построена, позволит пользователю добавлять новые столбцы в таблицу в системе ..."

Действительно - это история пользователя? Похоже, вы уже определились с решением, для меня.

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

Расширение схемы привело бы к гораздо более эффективным запросам - как вы могли бы добавить индексы и тому подобное - но это действительно предоставляет некоторые реляционные правила для ваших пользователей. Кроме того, расширение (вероятно) блокирует всю таблицу, и необходимо будет выполнить одновременное редактирование.

Answer 3

Возможно ли, что вы смотрите на свое решение вбок? Похоже, вам нужна таблица сопоставления (вроде как ваш # 1). У вас есть таблица, скажем, «объекты», например, таблица «свойства», которая содержит то, что вы называете столбцами, а затем таблица, содержащая значения, поэтому она просто имеет object_id, property_id, value.

Чтобы выразиться умнее, чем я сказал, взгляните на модель Атрибут-значение .

Answer 4

Если это централизованно размещено вами, я бы предложил НЕ разрешать вводимым пользователем данным изменять схему базы данных (т. Е. Управлять созданием новых таблиц).

Скорее вы можете захотеть изучить использование полей XML в SQL для хранения имен полей переменных данных или более общей структуры таблиц ... этот метод работает очень хорошо, если мы не говорим о сумасшедших объемах данных ...