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

77

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

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

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

Резиновая утка
источник
6
@gnat: Это совершенно другое.
Роберт Харви
1
Если это закрыто как дубликат, это должен быть дубликат этого вопроса . Ответы и вопросы более соответствуют тому, что я спрашиваю.
RubberDuck
1
@ Mawg это рабочий проект. Я отодвинул все, что мог, чтобы добиться соблюдения требований. Надо начать работу над этим, и я больше ничего не могу с этим поделать.
RubberDuck
4
Errrm, новая работа? Я знаю, что я бы. Но, как 30-летний фрилансер, мне легко уйти, пока он действительно не поразил фаната (некоторые люди, которым вы просто не можете помочь), но я понимаю, что это не так просто для всех. Оставайтесь, если нужно (нет сопоставимого работодателя) в области, и т. д.), но не оставайтесь, если это начинает влиять на вас
Mawg

Ответы:

85

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

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

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

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

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

MichelHenrich
источник
1
«База данных - это деталь». Большое спасибо за ссылку. Я искренне верю, что смогу заняться этим проектом, оставив базу данных в качестве отложенного решения после просмотра этого выступления.
RubberDuck
6
И просто назову это: все эти практики (возможно, самые важные) в Agile-разработке (инкрементная разработка, простейшая вещь, которая может сработать, управляемая тестами, в первую очередь нуждающаяся в пользователях ...).
Слёске
8
Я хотел вернуться и еще раз поблагодарить вас. Весь мой средний уровень работает без базы данных, и теперь я прекрасно понимаю, как эти данные должны сохраняться. Я не могу отблагодарить тебя достаточно. Я бы снова проголосовал, если бы мог.
RubberDuck
12
Если вы действительно фиксируете все требования с помощью метода «сначала код» и действительно выражаете все эти требования в своей окончательной базе данных , я могу согласиться с этим ответом. Но я видел много-много проектов, в которых удовлетворение от того, что что-то «работает», приводит к тому, что «если она работает, база данных должна быть достаточно хорошей», даже если это ужасный дизайн базы данных, с неизбежными и серьезными проблемами производительности потом. Кроме того, очень многие люди думают, что если код проверяет данные, вам не нужны ограничения CHECK или FOREIGN KEY. Вы делаете .
Росс Прессер
2
Возможно, это описано в видео - к сожалению, я не могу сейчас это сделать - но еще одно преимущество поэтапного подхода заключается в том, что при правильном выполнении это помогает закрепить неопределенные спецификации. «Похоже ли, что этот экран захватывает всю необходимую контактную информацию? Поля расположены в порядке, который имеет смысл с вашим рабочим процессом?» Возможность задавать эти вопросы - с чем-то конкретным в качестве ссылки - часто является IME единственным способом получить необходимую информацию.
Дэвид
17

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

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

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

Джеймс Снелл
источник
Я искренне согласен, но этого не произойдет. Спасибо за ваше время, хотя.
RubberDuck
9
Если у вас нет времени, чтобы сделать это правильно, где вы найдете время, чтобы сделать это снова?
Уолтер Митти
Кто сказал что-то о том, что не правильно сделал @WalterMitty? Пожалуйста, смотрите ссылку на видео в принятом ответе. База данных - это деталь , которая не должна быть в наличии , чтобы справляться с перепадами 95% программного обеспечения.
RubberDuck
1
Я понял, что «этого не произойдет», чтобы обозначить, что вы собираетесь приступить к написанию кода, даже не зная, какая информация нужна заинтересованным сторонам из системы. Я думаю, что Джеймс дал вам очень хороший совет по выполнению базового системного анализа, не увлекаясь параличом анализа.
Уолтер Митти
Вы неправильно поняли меня @WalterMitty. Я принял подход обратной связи. Я создам то, что, по моему мнению, должно (без базы данных), а затем передам это пользователям. Изменить программу. Повторение. После нескольких итераций я должен точно знать, как будет выглядеть база данных. Насколько я понимаю, Agile-подход специально разработан, чтобы справляться с неясными требованиями. Во мне хорошо видно этот проект.
RubberDuck
12

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

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

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

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

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

Тулаинс Кордова
источник
Это все очень верные вещи, и на самом деле это будет заменять «не для процесса» и таблицы, но я не вижу , как это ответ на мой вопрос. Можете ли вы уточнить?
RubberDuck
1
@RubberDuck Я добавил пояснение в конце своего ответа.
Тулаинс Кордова
11

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

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

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

Джеймс Андерсон
источник
Это именно то, как я обычно работаю. Сначала требования , да. Как бы я хотел вытащить некоторые твердые требования из кого-то прямо сейчас.
RubberDuck
Сначала требования, хотя вы не должны ждать, пока требования не будут выполнены (они никогда не будут). Начните, как только у вас будет достаточно, чтобы понять, каковы цели приложения, а затем получить больше, когда они вам нужны.
Слёске
@sleske - Хороший аналитик должен почувствовать более «динамичные» (то есть расплывчатые и изменчивые) части требований и создать некоторую гибкость в дизайне, чтобы легко справляться с прихотями пользователей.
Джеймс Андерсон
1
@JamesAnderson: На самом деле, я большой поклонник принципов гибкой разработки, где вы обычно разрабатываете только то, что вам нужно сейчас , если только вы не знаете, что не сможете изменить дизайн позже (редко бывает). Но я начинаю уходить не по теме ...
Слёске
8

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

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

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

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

user949300
источник
3
+1 для ни «сначала кода», ни «сначала базы данных», но «сначала нефункционального графического прототипа» (он же «быстрое прототипирование»), потому что в отсутствие требований прототип графического интерфейса помогает прояснить требования конечным пользователям.
k3b
1
Правда, но это также заставляет их поверить, что приложение так же хорошо, как и сделано. Я был сожжен таким образом раньше и теперь требую, чтобы мы сначала
четко сформулировали
@ Mawg да, к сожалению, это опасно. Один из вариантов (по крайней мере, в Java) - использовать странный «внешний вид», чтобы прояснить, что это прототип.
user949300
Если вы не знаете, куда идете, любой код доставит вас туда.
-1

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

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

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

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

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

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

Джон Рейнор
источник
Так лежит безумие. Никогда не сохраняйте данные, пока не будете готовы сохранить данные. Нормализация данных после факта - это кошмар.
RubberDuck
1
Есть разница между настойчивостью и нормализацией. Вопрос, на который могут ответить только вы, заключается в том, нужно ли мне только упорствовать или упорствовать и нормализоваться. Модель данных - это модель, если нет требований, то сложно что-то моделировать реляционно.
Джон Рейнор
-2

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

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

Kein IhpleD
источник
3
кажется, это не дает ничего существенного по сравнению с замечаниями, сделанными и объясненными в предыдущих 5 ответах
комнат
Моя точка зрения заключается в том, чтобы следовать подходу в зависимости от типа клиента
Kein IhpleD