Работа с редизайном приложения

Если вы не хотите изменять дизайн базы данных, вы всегда можете реструктурировать свой пользовательский интерфейс (UI). Используйте хороший шаблон, если вы решили работать с веб-формами, тогда я советую использовать шаблон Model View Presenter, или если вы знаете много javascript и html, и вам не нравится модель веб-форм, используйте новый ASP.NET MVC.

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

Надеюсь, ты сможешь что-нибудь сделать с этой информацией.

Вам нужно изменить дизайн базы данных или всего приложения? Вы выполняете одиночную миссию или вам нужна приличная помощь? Использует ли ваша компания какие-либо стандарты методологии (процессы SDLC) или вы являетесь независимым ИТ-отделом?

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

Суть в следующем: потратьте приличное количество времени на оценку работы, которая потребуется для прохождения всего процесса. Если четыре месяца - отлично. Сомневаюсь, что так и будет. Как только у вас будет задокументированная и подробная оценка затраченных усилий, отнесите ее своему боссу и объясните ему, насколько на самом деле крайние четырехмесячные временные рамки.

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

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

Надеюсь это поможет.

Это что-то вроде старой поговорки, что умные структуры данных и тупая логика каждый раз побеждают обратное. См. Правило 5 в статья о философии unix. Когда дело доходит до этого, каждый проект, в котором я был, где мне приходилось копаться в коде для исправления сломанных структур данных, был головной болью.

Краткий ответ: переделайте данные, если можете.

Длинный ответ: будьте прагматичны. Если вы можете избавить себя от головной боли, переделав только часть базы данных, сделайте это. Разобраться с этим в логике приложения будет гораздо сложнее, чем на уровне базы данных.

Надеюсь, это поможет!

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

Однако возможно ли исправить только одну или две худшие части базы данных и таким образом добиться улучшения в целом? Посмотрите на наименее эффективные запросы, чтобы увидеть, что действительно не так (не только с вашей личной точки зрения на то, что вам не нравится, но и на то, что сейчас действительно не работает). Может быть, что-то меньшее, чем полный редизайн, может дать вам серьезный прирост производительности.

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

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

мои 0,02 $

Чтобы добавить мои 0,02 доллара, вы сначала должны понять, почему вы делаете редизайн, в чем проблема с текущим программным обеспечением, это производительность, ремонтопригодность, лучшая база для расширения продукта и т. д. Затем четко сформулируйте свои цели для новый продукт (например, улучшение UX, целей производительности, фреймворка и т. д.), возможно, это даст вам лучшее представление о том, что нужно изменить и что работает.