Модификация базы данных или начать заново?

Question

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

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

Мне было поручено улучшить сайт и функциональность модели; однако я хочу уменьшить количество повторений данных на веб-сайте (это нормализация или разделение несвязанных элементов на отдельные таблицы?). Я не уверен, что лучший способ сделать это будет. Я подумываю о создании сценариев создания базы данных и создании нового проекта базы данных в VS для последующего изменения базы данных, а затем создания некоторых сценариев для заполнения новой модели базы данных из старой базы данных.

Я планирую использовать Entity Framework и ASP. NET MVC 2 для создания веб-сайта, так как я считаю, что он обеспечивает наиболее гибкую модель продвижения и модификации веб-сайта.

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

Мне любопытно, есть ли какой-нибудь материал о наилучшем способе сделать это или мне следует использовать другой инструмент для этого?

Редактировать: Предоставление дополнительной информации о модели

Мы используем 4 основных области:

1. Случаи (ошибки, особенности, рабочие задачи и т. Д.) 2. Билеты (мероприятия технической поддержки)
2. Ошибки (ошибки, сгенерированные из нашей библиотеки журналов, в основном трассировка стека с информацией о клиентах)
3. Лицензия (Отслеживает каждого клиента Лицензия позволяет модифицировать эти лицензии)

Это объекты, которые смешаны и используются во всех 4 основных областях.

1. Пользователи (Люди, которые используют систему)
2. Клиенты (Люди, которые используют наше программное обеспечение)
3. Магазины (места, где наши клиенты используют наше программное обеспечение)
4. Продукты (наше программное обеспечение)

Отношения

Случаи: Случаи должны иметь пользователя, могут иметь клиента, магазин, ошибку, тикет и / или продукт

Билеты Билет должен иметь пользователя и клиента, может иметь магазин, ошибку и / или продукт

Ошибка: Ошибка должна иметь продукт, может иметь дело, билет, магазин и / или продукт

Лицензия: Лицензии должны иметь Продукт и Клиента, могут иметь Магазин

Как я сказал, очень простой веб-сайт, с не очень сложной базой данных, если все сделано правильно.

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

например.

Каждый тип Case имеет отдельную таблицу, поэтому есть таблица FeatureRequest, Bug, Tasks, Completed и т. Д., Которые содержат одинаковую информацию.

Answer 1

Нормализация - это хранение данных без избыточности или аномалий.

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

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

Трудно ответить на ваш вопрос о том, следует ли изменить базу данных на месте или создать новую базу данных и перейти на нее.

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

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

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

---

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

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

---

Вот несколько предложений о ресурсах, которые помогут вам по-настоящему понять, что означает нормализация:

• SQL и реляционная теория от C.J. Date
• Уильям Кент * Простое руководство по пяти нормальным формам в теории реляционных баз данных
• Нормализация базы данных в Википедии и ее подстраницах для каждой соответствующей нормальной формы
• Антипаттерны SQL: предотвращение ловушек программирования баз данных , Билл Карвин. Я написал главу о нормализации базы данных, которая, я надеюсь, объясняет это простым английским языком и содержит хорошие примеры.

Вот несколько ресурсов для управления изменениями в базе данных:

• Рефакторинг баз данных Скотт В. Амблер и Прамодкумар Дж. Садалаж
• Методы Agile Database: эффективные стратегии для Agile Software Developer Скотт В. Амблер

Answer 2

Сколько у вас времени и насколько велика база данных?

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

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

Итак, пища для размышлений.Сколько времени вам потребуется, чтобы заново сделать базу данных, сколько это будет стоить.Будет ли работать с тем, что существует, достаточно для заданной функциональности?