Стоит ли проектировать базу данных до написания кода приложения?

57

Какой самый простой и эффективный способ создания базы данных? С моей точки зрения, есть несколько вариантов дизайна хранилища данных приложения:

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

По вашему опыту, что вы считаете наиболее продуктивным и эффективным методом?

Томас Стрингер
источник
Разделяй и властвуй с SDLC
Премрай
1
Вы можете найти flywaydb.org интересным. Это позволяет вам контролировать версию вашей схемы базы данных.
Турбьёрн Равн Андерсен

Ответы:

41

В дополнение к другим ответам ...

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

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

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

Произойдут незначительные изменения в схеме, объединение или разделение таблиц, изменение отношений и т. Д., Но в локализованных «островках» ваша модель + базовый дизайн не изменится.

ГБН
источник
6
И стабильность важна, потому что имена таблиц и представлений, имена столбцов, имена хранимых процедур и т. Д. Являются открытым интерфейсом базы данных. (И рано или поздно будет много приложений, использующих этот интерфейс.)
Майк Шеррилл 'Cat Recall'
Я бы сказал, что это довольно идеализированный подход, мой опыт показывает, что время от времени происходят радикальные изменения, и нам нужно быть гибкими, быстро адаптироваться к новым требованиям и продолжать рефакторинг.
Звон
@zinking: я делаю это Agile вещь прямо сейчас.
ГБН
@gbn, извините, чтобы задать вопрос ниже. Я понятия не имею, как справиться со сценарием. Пожалуйста, посмотрите. stackoverflow.com/questions/46285924/… . Пожалуйста, предложите мне лучшее решение.
RGS
27

Вам будет сложно найти любой современный отдел программного обеспечения, который не использует какой-либо вариант Agile. Для сравнения, администраторы баз данных застряли в темных веках, так как в @ RobPaller все еще распространено мнение.

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

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

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

Марк Стори-Смит
источник
4
Agile и базы данных идут вместе с предостережениями. Agile является границей для VLDB: может не хватить времени для проверки и тестирования изменений в миллиардных таблицах строк между результатами. И «гибкая разработка» - это не то же самое, что «оптовые изменения» из-за нехватки
осознанности
2
Не могу согласиться с тем, что у меня нет предвзятости, но я не думаю, что это имеет отношение к вопросу. Речь идет не о том, следует ли вам подходить к дизайну бессистемно, а о том, должна ли ваша модель данных развиваться по мере развития приложения. VLDB выпускает ордер, который я добавлю.
Марк Стори-Смит
3
Я читаю вопрос как «новое приложение без БД», а не как «существующее приложение, требующее изменений в БД»
gbn 11.10.11
Кроме того, я где-то упускаю вашу точку зрения :) Один, чтобы взять в чат?
Марк Стори-Смит
4
+1 для общего настроения вашего ответа, но «Изменение схемы базы данных еще никогда не было таким простым, как изменение кода», на самом деле зависит от того, сколько у вас кода (и сколько ему лет). ИМО обратное в более общем смысле верно
Джек Дуглас
12

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

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

  1. Сфера действия - вы позволяете вводить новые требования в неподходящее время.
  2. Недостаточные бизнес-требования. Разработчики моделей данных (или системные аналитики) недостаточно перевели требования бизнес-аналитиков. Это привело к неполной или неправильной модели данных для поддержки требований вашего приложения.

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

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

RobPaller
источник
7
Добавление множества новых требований в ходе проекта не является «неуместным». Это то, что ваши методы разработки должны поддерживать и поощрять www.agilemanifesto.org/principles.html
nvogel
1
Я хорошо знаю некоторые принципы гибкой разработки и являюсь их сторонником в области хранилищ данных, где это имеет смысл для бизнеса. Спасибо за ваш комментарий.
РобПаллер
11

Мне посчастливилось создать несколько баз данных средней сложности, все из которых используются в бизнесе, с различными интерфейсами, включая веб, Access и C #.

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

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

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

Я ХОРОШО в том, что я делаю. Но только один из меня делает это в среде, которая "не занимается разработкой".

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

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

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

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

На мой взгляд, это огромная победа.

ErikE
источник
+1 Отличный ответ. Облегченная разработка требований - ОГРОМНЫЙ плюс в проекте с участием многих заинтересованных сторон.
Зейн С Халсолл
10

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

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

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

nvogel
источник
2
Не думаете ли вы, что для определения концептуальной модели потребуется какое-то предварительное мышление?
ГБН
Некоторые предварительные размышления могут быть полезны, но попытка определить всю модель заранее, как правило, контрпродуктивна. Модель должна соответствовать бизнес-требованиям и соответствовать результатам проекта (включая приложение) по мере их развития. Вы не можете и не должны ожидать, что эти вещи не изменятся. Кроме того, создание всей модели заранее может на самом деле помешать другим разработкам из-за необходимости создания фиктивных интерфейсов для поддержки пока неиспользуемых частей схемы.
nvogel
Я подозреваю, что @dportas, и я работаю в подобных условиях :)
Марк Стори-Смит
9

В мире архитектуры фраза «Форма следует за функцией» была придумана, а затем соблюдалась при строительстве высоких зданий. То же самое должно применяться к инфраструктуре БД и разработке приложений.

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

К сожалению, некоторые магазины разработчиков подберут что-то вроде memcached, загрузят его с данными в ОЗУ (таким образом рассматривая это как канал передачи данных) и получат базу данных, такую ​​как MySQL или PostgreSQL, которые будут вести себя просто как хранилище данных.

Стимулом для использования базы данных должен быть правильный взгляд на нее: как на СУБД. Да, система управления реляционными базами данных. Когда вы используете RDBMS, ваша цель должна заключаться не только в создании таблиц для хранения, но и для извлечения. Отношения между таблицами должны моделироваться после данных, которые вы хотите увидеть, и того, как они представлены. Это должно основываться на связности и целостности данных наряду с известными бизнес-правилами. Эти бизнес-правила могут быть закодированы в вашем приложении (Perl, Python, Ruby, Java и т. Д.) Или в базе данных .

ЗАКЛЮЧЕНИЕ

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

RolandoMySQLDBA
источник
1
@RolandoMySQLDBA, вы предполагаете, что проект базы данных, созданный во время разработки приложения, будет хуже, чем проект, созданный ранее? Почему? Противоположность часто верна.
nvogel
1
@dportas: я делаю упор на вариант 1 с точки зрения минимизации изменений в дизайне БД. Я потратил 2/3 моей технической карьеры программиста в магазинах, где очень сложные модели данных и инфраструктура превращались почти ежемесячно по прихоти. Я ограничился такими изменениями, потому что потребности и цели бизнеса не были запечатлены в камне. Я довольно старая школа в этом. Ничего плохого в том, чтобы быть немного индивидуалистом, пока дизайн не создает много «технического долга» (да, я прочитал ваш ответ) в будущем.
RolandoMySQLDBA
2
+1 за «использование СУБД в качестве реляционной базы данных, а не бита для массивов» - какой бы подход вы ни выбрали
Джек Дуглас
2
@dportas: хотя это действительно так (бизнес-правила меняются), хорошо спроектированная БД не будет радикально меняться между итерацией (или спринтом, или чем-то еще) и другой, поскольку она отражает все соответствующие структуры данных рабочего процесса. Если это происходит (радикальное изменение), это означает сбой в бизнес-правилах, фиксирующих действия.
Фабрицио Араужо
3
@dportas: не все изменения БД, только РАДИКАЛЬНЫЕ. Незначительные изменения являются частью бизнеса по созданию программного обеспечения. Но необходимость разбивать данные на две разные базы данных в середине работы - это сбой в разработке и захвате бизнес-правил. (Это на самом деле случилось со мной.
Фабрицио Араужо
9

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

Мой типичный рабочий процесс, если я работаю один:

  1. Определите, что должно делать приложение
  2. Посмотрите, может ли какая-либо из задач быть разбита на повторно используемые компоненты
  3. Определите, как каждая задача должна взаимодействовать с хранилищем данных - какие вопросы они будут задавать относительно данных, как часто они будут писать и т. Д.
  4. Разработайте базу данных таким образом, чтобы она могла отвечать на все вопросы, которые нам нужно было задать, и чтобы она хорошо выполняла самые частые задачи.
  5. Напишите заявку.

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

  1. Определите, что приложение должно делать.
  2. Определите, где хорошие моменты, чтобы разбить приложение на отдельные компоненты
  3. Определите, как каждый компонент должен взаимодействовать с другими.
  4. Согласуйте API для каждого из взаимодействий.

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

Джо
источник
1
Вариант 2 заключается в том, что с гибкой методологией вы не знаете 1, 2 или 3, кроме той, которая предназначена для следующего спринта. Изменения неизбежны, по объему, требованиям и ожиданиям.
Марк Стори-Смит
8

Я имею в виду следующее правило: «Вы можете получать из базы данных только ту информацию, которую имеете для создания данных». Итак, сначала я создаю базу данных, а затем код.

Почему? Независимо от того, какую методологию / язык / набор инструментов я использую, если все соответствующие данные хорошо спроектированы и сохранены в БД, я могу их извлечь. Независимо от того, есть ли в C # / Delphi / FORTRAN / COBOL / Assembly / VBA или Crystal Reports; ОО разработан или событие / данные / что бы ни было обусловлено; проворный или водопад. Если данные есть, я могу получить их, если инструменты, которые я использую, могут подключиться к базе данных. Я могу создать отчеты о продажах, если смогу ВЫБРАТЬ заказы для доходов за квартал - даже если мне придется записывать их побитно при сборке.

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

Фабрицио Араужо
источник
7

Как обычно, это зависит;)

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

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

Аляска
источник