В гибкой разработке, я должен попробовать постоянство в плоском файле перед базой данных?


21

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

Это правда, или я неправильно понял концепцию? Так гибкая команда обычно создает приложение? Каковы причины этого и когда я не должен использовать этот подход?


1
Логика постоянства не является частью мелких деталей или менее важна. Это должно быть первое решение. Вы хотите свойства ACID для вашей персистентной структуры. Это решение не может быть отложено.
Manoj R

Ответы:


42

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

Однако, взятый пример на самом деле основывается на совершенно ложном предположении:

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

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

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

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

Итак, концепция верна и точна, но пример основан на очень большом и часто (почти всегда) неточном предположении .


6
И ваше ужасное предположение состоит в том, что они должны вручную писать весь код типа поиска и построения таблицы данных вручную! :-) Обычно, когда вы используете плоский файл, вы начинаете с использования встроенного формата сериализации вашего языка (например, Marshal в Ruby или NSKeyedArchiver в Cocoa / Objective-C) и просто выгружаете некоторые существующие внутренние объекты. До тех пор, пока ваше приложение не должно перезагружаться слишком часто, и пока вы получаете контроль над изменениями схемы в разных версиях приложения, этот метод может работать замечательно хорошо в течение длительного времени, особенно во время разработки.
Алекс Чаффи

@AlexChaffee справедливо, но в любом случае вам нужно так или иначе написать некоторый код вокруг этого материала, и современные ORM делают такие вещи с RDBMS или NoSQL в этом отношении довольно эквивалентными в тривиальности, где разница в воздействии на команду Основываясь больше на наборе навыков команд, чем на чем-либо, я просто думаю, что это плохой пример, чтобы проиллюстрировать то, что он пытается по этой причине. Лично я использую MSSQL в течение 13 лет, но если положить его на место, то из-за простоты раскрутит MongoDB из-за его простоты, чтобы он не влиял на реальную цель проекта, пока не имеет значения ACID.
Джимми Хоффа

17

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

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


4
Похоже, что вы получили отрицательный отзыв от общества плоских файлов.
JeffO

@JeffO: SQLite сохраняет свою базу данных в плоский файл.
Мистер Миндор

7
@ Мистер Миндор, большинство баз данных ... но это не имеет значения. «Плоский файл» здесь означает прямое манипулирование файлом, а не прохождение через некоторый слой БД.
GrandmasterB

Не согласен. Мне все еще нужно изучить, как работает SQLite, и реализовать код, который манипулирует базой данных SQLite в .NET, преобразовывает результат запроса в объекты и т. Д., Чтобы это не облегчало разработку. Это просто добавляет все трудности создания базы данных, без преимуществ полноценного сервера баз данных.
Луи Рис

11

Это пример, используемый для демонстрации концепции, а не самой концепции.

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

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

Но перейти с MySql в Linux на SQL Server в Windows может быть не так просто, как перейти с простого файла в любом месте на SQL Server в Windows. Это реальная точка зрения. Таким образом, пока есть сомнения относительно окончательного решения, выберите самый простой вариант - учет изменений. Как только решение принято, придерживайтесь его.


Я не согласен по поводу пути миграции. technet.microsoft.com/en-us/library/cc966396.aspx содержит подробные инструкции по миграции с MySQL на MSSQL, хотя для преобразования плоского файла в любой из вариантов потребуется вручную записать ETL в SSIS или его версию MySQL.
Джимми Хоффа

@JimmyHoffa: я не знаю, CSV довольно легко. blog.sqlauthority.com/2008/02/06/… tech-recipes.com/rx/2345/import_csv_file_directly_into_mysql, но я понимаю, что ни один путь не является ТАК сложным.
фунтовые

6

Что ты упорствуешь?

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

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


1
Приложение управляет очередью запросов и должно запоминать очередь после закрытия и перезапуска. Нет необходимости использовать базу данных, как в вашем приложении
Louis Rhys

@LouisRhys: Что будет сделано с этими данными очереди? Просто читать и показывать пользователю? Как вы думаете, какие преимущества вы получите от сохранения в базе данных?
FrustratedWithFormsDesigner

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

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

5

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

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

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

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


1
«Планы бесполезны, но планирование необходимо». - Эйзенхауэр
Алекс Чаффи

3

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

Если вы создаете слой постоянства поздно или создаете его по пути, ваша стратегия заключается в предоставлении бизнес-ценности клиенту. Я не верю, что сам термин «agile» диктует, следует ли вам делать то или другое.

Точка зрения на отсрочку стратегии хранения данных отстаивается в этой презентации Робертом К. Мартином (один из авторов гибкого манифеста).

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

Но я не согласен с этим! По крайней мере, в определенной степени.

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

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

Гибкие проекты, над которыми я работал, не откладывали стратегию доступа к данным. Но он был отделен, что позволило нам изменить его по пути. И вся схема базы данных не разработана заранее. Таблицы и столбцы создаются по пути, необходимому для реализации хранимых пользователем данных, которые, в конце концов, обеспечивают ценность для бизнеса.


1

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

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

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


0

Плоские файлы не просты!

Они позволяют хранение, и это все. Структура данных, пути доступа и т. Д. Зависит только от вас, и существует множество способов сделать это неправильно.

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

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

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

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

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


-1

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

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

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.