#database #sql-server-2005 #entity-framework #database-design
#База данных #sql-server-2005 #entity-framework #база данных-дизайн
Вопрос:
У нас есть стороннее программное обеспечение, и меня попросили создать для него расширение. Расширение будет обрабатывать данные, существующие в текущем программном обеспечении, и включать некоторые дополнительные данные.
Существующие данные чрезвычайно денормализованы. Большая часть данных, с которыми я буду работать, а это примерно 4-5 разных объектов, существует в одной таблице. Мне нужно будет добавить дополнительные поля к большинству этих объектов.
Я вижу 2 способа сделать это:
-
Создайте новую таблицу для новых полей, которая соответствует существующей таблице 1: 1 и использует тот же денормализованный стиль, который они используют
Плюсы: она будет соответствовать существующей денормализованной структуре базы данных и будет проста в создании
Минусы: очень денормализованная, и я немного одержим нормализацией своих баз данных. В текущей таблице уже более 50 столбцов, и ее действительно следует разделить на 4-5 разных таблиц.
Я также не думаю, что смогу легко использовать EF с текущей структурой базы данных (мой предпочтительный способ работы с базой данных), и мне придется вручную создавать модели данных в коде вместо использования EF для их генерации
-
Создайте совершенно новый набор таблиц и используйте триггеры для синхронизации данных между таблицами
Плюсы: могу создавать таблицы так, как я хочу, и могу использовать EF для обработки операций с базой данных и для создания моделей данных для меня
Минусы: необходимо использовать триггеры для синхронизации данных с существующей таблицей
Как вы думаете, какая идея лучше?
Ответ №1:
Я думаю, это зависит от того, на какое расширение вы смотрите. Если вы добавляете пару наворотов к существующему интерфейсу, и особенно если вам не нужно оборачивать существующий интерфейс, тогда вам, возможно, лучше зажать нос и смириться с уродливой базовой структурой данных.
Все сводится к тому, что нужно создавать и поддерживать меньшую кучу кода:
-
Код расширения, который становится уродливым из-за денормализованной базы расширенных атрибутов — или —
-
Чистый код расширения весь уродливый код запуска синхронизации таблиц.
Мне кажется, что если расширение действительно существенное, то 2 может оказаться меньше 1. Однако, если вы смотрите только на эти несколько наворотов, то 1, вероятно, будет намного меньше, чем 2.
Ответ №2:
Я думаю, что ответ заключается в том, как наилучшим образом использовать ваше время в сочетании с тем, насколько вы контролируете таблицы сейчас и в будущем. Лично я бы создал альтернативную таблицу с некоторыми отношениями. Если вы решите изменить существующую таблицу, вам не только теперь придется регрессионно тестировать приложение и тестировать свое новое приложение, но вы рискуете, что будущие обновления нарушат работу обоих приложений. Итак, я говорю, работайте с тем, что вы можете контролировать. Ваше время будет использоваться более эффективно, и вы будете позиционировать себя с меньшим риском в будущем. Умный для вас и умный для бизнеса. Надеюсь, это поможет.
Комментарии:
1. Вероятно, мне следует перефразировать первый вариант… На самом деле я бы не редактировал существующую таблицу, а создал новую таблицу, которая ссылается на нее 1: 1 для получения дополнительных данных, используя тот же стиль базы данных. Это то, что мы делали в прошлом для других их таблиц.
2. Я бы выбрал первый вариант. Я думаю, что второй вариант является излишним и может стать кошмаром для управления. Подумайте, насколько легко или сложно было бы передать ее другому разработчику без вашей помощи. Я полагаю, что я придерживаюсь позиции меньшего объема работы, меньшего управления данными и простоты обслуживания в сочетании с надежностью.
3. Я полностью согласен с позицией Джеффа в комментарии выше. «Одержимости» любимым шаблоном или стилем недостаточно для бизнес-решения. Я могу это понять, хотя и пытался изменить существующий материал или расширить его в своем собственном стиле (против того, что там было). Это почти всегда было ошибкой с точки зрения времени и денег, которые она потребляла. Если ваше расширение не велико и у вас достаточно времени (что позволило бы вам создать свой собственный фундамент в БД), я бы боролся с навязчивой идеей и предпочел простой режим. Следуйте своим предпочтениям в проектах, где вы можете начать с нуля.