Сначала код против базы данных сначала

Когда я проектирую и создаю программное обеспечение, над которым я работаю, я обычно сначала проектирую и создаю внутренние таблицы SQL, а затем перехожу к реальному программированию. Хотя проект, над которым я сейчас работаю, озадачил меня. Вероятно, это связано с отсутствием хороших, твердых требований, но, к сожалению, на этот раз я мало что могу с этим поделать. Это ситуация типа "просто сделай это" ... но я отвлекся.

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

Если кому-то интересно, я использую SQL Server в качестве бэкэнда и MS Access в качестве внешнего приложения. (Доступ не мой выбор ... так что, пожалуйста, не ненавидите это слишком плохо.)

Что было первым: процесс или данные, используемые этим процессом? Я знаю, что это вопрос типа "курица или яйцо", но в случае с программным обеспечением, я считаю, что это процесс.

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

Это снимает фокус с базы данных и перемещает ее в суть проблемы: бизнес-правила. Если вы начнете с реализации бизнес-правил, вы в конечном итоге обнаружите (кстати, в процессе, очень похожем на Natural Selection), какие данные действительно нужны бизнесу. Если вы начнете с моделирования базы данных, без обратной связи о том, действительно ли нужны эти данные (или в этом формате, или на этом уровне нормализации и т. Д.), Вы либо в конечном итоге будете делать много поздних корректировок в схему (которая может потребовать сложных процедур миграции, если бизнес уже работает с ней), или вам придется внедрить «обходные пути» в бизнес-правилах, чтобы компенсировать несоответствующую модель данных.

TL; DR: База данных зависит от бизнеса - она ​​определяется ими. Вам не понадобятся данные, если у вас нет процесса, который работает с ним (отчет также является процессом). Сначала внедрите процесс, и вы найдете, какие данные ему нужны. Сначала смоделируйте данные, и вы сможете просто посчитать, сколько предположений было неверным, когда вы впервые смоделировали их.

Немного не в тему, но очень важно: рабочий процесс, который я описываю, часто используется вместе с очень важными практиками, такими как «Самое простое, что могло бы сработать», разработка через тестирование и фокус на отделении вашей архитектуры от деталей, которые встать на вашем пути (подсказка: база данных). Что касается последнего, этот разговор довольно хорошо обобщает идею.

Анализ первопричин предполагает, что эта проблема - не метод, а отсутствие спецификации. Без него на самом деле не имеет значения, что вы пишете первыми - вы все равно выбросите его.

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

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

Мой опыт выглядит следующим образом:

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

Также помните:

• Это больше не мир с одним приложением <-> с одной базой данных. Возможно, вашему приложению придется считывать или записывать данные из более чем одной базы данных, или ваше решение будет содержать более одного приложения, использующего одну и ту же базу данных.

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

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

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

Хороший четко определенный набор бизнес-требований приводит к хорошему набору функциональных требований. Если у вас есть хороший набор функциональных требований, то модели данных и спецификации модулей просто встают на свои места без особых усилий.

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

Для начальной базы данных «база данных» используйте что-то предельно простое, может быть, просто ключи / значения, хранящиеся в файле. Я не знаком с MS Access, поэтому не знаю, какой будет самый легкий бэкэнд. (столик из листовой бумаги?) Что бы ни было быстрым и грязным, планируйте выбросить его.

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

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

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

В качестве примера, может быть, у вас есть Person, поэтому у вас есть PK Person Id. Остальные атрибуты неизвестны, поэтому просто начните с таблицы Person с идентификатором пользователя PK и другого столбца, в котором будет храниться BLOB-объект, все данные о персоне.

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

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

По сути, вы начинаете с табличной модели и переходите к реляционной модели по мере продвижения проекта.

Или уточните требования до начала любой работы, чтобы изначально можно было разработать реляционную модель.

В общем, я думаю, что код идет после данных, потому что код будет манипулировать данными.

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