Гибкая система управления каталогами ... что-то мне не хватает?

Question

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

Теперь, для следующей основной версии, я пытаюсь изменить это так, чтобы он мог сам определять все столбцы - поэтому у меня есть таблица ItemType, где он называет типы элементов;таблица ItemTypeProperty, чтобы он мог определить все столбцы и их типы данных, таблица Item, в которой все элементы хранятся с идентификатором их ItemType, и таблица ItemPropertyValue, которая использует ItemID, ItemTypePropertyID и сохраняет значение.Цель состоит в том, чтобы дать ему возможность сказать, что ему нужен столбец типа, так что, если есть два типа элемента с именами Range и Collection, он может сказать, что он хочет, чтобы Collection был свойством Range.

Имеет кого-либоЗдесь я уже сталкивался с созданием подобного рода систем, и, если да, есть ли что-то серьезное, чего мне не хватает, или что-то, что я, возможно, захочу рассмотреть, прежде чем я получу слишком много дальше?Я имею в виду какую-то проблему, которую я могу решить позже, которую я мог бы избежать, если бы что-то сделал сейчас?В качестве альтернативы есть какие-либо технологии, которые могут оказать большую помощь?Я пробовал Linq, но в то время мне было сложно настроить его под свои нужды.В настоящее время я использую VB.Net 2.0 (ограничение, установленное сервером; не под моим контролем) с Sql Server 2008. Я создал свою собственную систему, основанную на архитектуре MVC.

Заранее спасибо.

С уважением,

Ричард

Редактировать:

Моя новая структура базы данных:

Таблица: ItemType

• ID
• Имя

Таблица: ItemTypeProperty

• ID
• ItemTypeID
• Имя
• Описание
• Тип данных

Таблица: Элемент

• ID
• ItemTypeID

Таблица: ItemPropertyValues ​​

• ID
• ItemID
• ItemTypePropertyID
• Значение

Answer 1

Каковы основные архитектурные драйверы здесь? Насколько важна ремонтопригодность? Как бы вы сравнили их с потребностями времени выполнения, такими как производительность?

Это может звучать банально, но четкое представление о том, что важно, а что нет, поможет вам принять правильные решения.

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

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

Особенности:

• Важно правильно подобрать модель данных. Прежде чем вы зайдете слишком далеко, убедитесь, что вы понимаете 5-ую нормальную форму : в основном вы (вероятно) столкнетесь с проблемами, когда в вашей системе могут быть две концепции, которые не могут быть связаны в реальном мире - потому что они все значения (ItemTypes) в одной таблице ( эта ссылка может быть лучше).
• Отчетность будет сложнее - потому что у вас нет хорошей плоской структуры таблицы для отработки, поэтому вы также можете получить меньшую поддержку инструментов (просто догадка - абсолютно неподдерживаемое мнение).
• Может оказаться, что вы вводите в свою систему «больше» констант - если вы просто убедитесь, что вы наносите на карту их относительно заранее (это относится к правильной модели данных).

Обновление:

"Кажется, это работает, но я не буду знать, пока у меня есть несколько ItemTypes и экземпляры тех "

Именно это я и хотел сказать о моделировании данных. Под моделированием данных я имел в виду не столько физическое построение БД, сколько тщательное понимание базовых данных - «логических данных». Начиная с ручки и бумаги / белая доска - отличный первый шаг; Исходя из этого, вы вполне можете перейти к выполнению некоторых проектных работ с использованием одной или нескольких баз данных, чтобы на самом деле опробовать их, прежде чем переходить к полной системе.

"Если система такого размера может быть эффективно, как тогда, почему не может это? "

Вы, вероятно, пытаетесь сравнить яблоки и груши. Некоторые причины:

• Аппаратное обеспечение и конфигурация. Я предполагаю, что ваша система и эта не совсем то же самое.
• Архитектурные приоритеты: я бы предположил, что этот сайт создан с учетом производительности; это, конечно, не то, что вы можете добавить в качестве запоздалой мысли, однако это не означает, что вы не можете улучшить производительность старой системы - вы, конечно, можете - хотя это специализированный навык.
• Кэширование, предварительный расчет: использование кеширования является довольно очевидным способом повышения производительности. Другой способ - предварительно рассчитать данные до того, как они будут запрошены. Это то, что вы можете рассмотреть.