Модель данных для рабочего процесса / приложения бизнес-процесса
Какой должна быть модель данных для приложения рабочего потока? В настоящее время мы используем модель на основе значения атрибута сущности в SQL Server 2000 с пользователем, имеющим возможность создавать динамические формы (на asp.net), но по мере роста данных производительность падает, и создание отчета затрудняется, и, что еще хуже, если слишком много. пользователи одновременно запрашивают данные (EAV).
Ответы 3
Обычно, когда ваша схема базы данных становится очень большой и несколько пользователей пытаются получить доступ к одной и той же информации разными способами, применяется Хранилище данных, чтобы уменьшить основную нагрузку на сервер базы данных. В отличие от вашей традиционной схемы, где вы, скорее всего, используете нормализацию для сохранения целостности данных, хранилище данных оптимизировано для скорости, и сохраняется несколько копий ваших данных.
Попробуйте использовать реляционную модель данных. Оно работает.
Я уверен, что это было большим подспорьем для ОП.
Как вы, вероятно, поняли, проблема модели EAV заключается в том, что таблицы очень быстро растут, а запросы - очень быстро. Например, запросы на основе EAV обычно требуют большого количества подзапросов, чтобы получить те же данные, которые было бы тривиально выбрать, если бы вы использовали более традиционно структурированные таблицы.
К сожалению, перейти к реляционной модели с традиционной структурой при этом оставляя старые формы открытыми для модификации. достаточно сложно.
Итак, мое предложение: учитывает изменения закрытие в устоявшихся формах и перенос их данных в стандартные, нормализованные таблицы. Например, если у вас есть набор форм доставки, которые вряд ли будут изменены (или изменениями которых вы можете управлять, изменив приложение, потому что это происходит так редко), вы можете создать фиксированную таблицу, а затем скопировать существующие данные из вашу таблицу (-ы) EAV. Это A) улучшит вашу способность составлять отчеты, B) уменьшит объем данных в ваших существующих таблицах (таблицах) EAV и C) улучшит вашу способность поддерживать одновременных пользователей / повысит производительность, потому что вы можете встроить более подходящие индексы в свои данные.
Короче говоря, думайте о динамической системе на основе EAV как о способе сбора потребностей пользователей (они сообщают вам, создавая свои формы), а НЕ как о постоянном хранилище. По мере того, как формы эволюционируют в свою окончательную форму, вы переходите к фиксированным таблицам, чтобы получить преимущества, описанные выше.
Последняя вещь. Если все это невозможно, рассматривали ли вы возможность сегментирования таблицы EAV на несколько таблиц по категориям? Например, поместите все формы отправки в одну таблицу, формы для персонала - во вторую и т. д. Это не решит проблему структуры запросов (требуются подзапросы), но поможет уменьшить ваши таблицы и повысить производительность.
Надеюсь, это поможет - я сочувствую вашему положению, поскольку сам был в подобной ситуации!
Ясно, что это шутка, призванная быть смешной. Хахаха.