Чи потрібно спробувати впертість у плоский файл перед базою даних?

Хтось мені пояснив, що оскільки у спритному розвитку, політиці та логіці застосування мають бути важливіші деталі, такі як метод стійкості, рішення щодо стійкості має бути прийняте наприкінці. Тому може бути гарною ідеєю почати з більш простої наполегливості, наприклад, плоских файлів, поки ми не досягнемо того, що слабкість цього методу стане очевидною, і лише потім ми змінимо стійкість, наприклад, використовуючи реляційну базу даних.

Це правда, чи я неправильно зрозумів цю концепцію? Це, як спритна команда зазвичай будує додаток? Які обґрунтування цього є, і коли я не повинен застосовувати такий підхід?

Концепція, що передається, - це щось, що, безумовно, є частим гнучким і актуальним, ідеєю відштовхувати речі до останнього відповідального моменту.

Однак насправді приклад фактично спирається на абсолютно помилкове припущення для початку:

що реалізувати базу даних з плоскими файлами простіше / менше, ніж використовувати RDBMS. - Часто абсолютно помилковий

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

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

Крім того, якщо ви не знаєте, що ваш рівень стійкості починати з нього, це ще більш підходящий акт, щоб почати з загальної RDBMS, яку добре знає ваша команда, оскільки зробити зміни пізніше з плоских файлів на RDBMS набагато більше, ніж пізніше перехід від однієї RDBMS до іншої. Існує безліч інструментів для перетворення з більшості будь-яких поширених RDBMS в інші подібні, і поради, і такі, оскільки це добре пройдений шлях. Інструментів для перетворення з плоского файлу в будь-який заданий RDBMS вкрай мало, коли ваш плоский файл має певний формат, про який раніше не писали інструменти, окрім ваших власних бібліотек.

Підсумовуючи це: Концепція правильна і точна, але приклад ґрунтується на надзвичайно великому і часто (майже завжди) неточному припущенні .

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

Одне, що ви можете зробити, щоб спростити початкову складність, використовуючи щось на зразок SQLite (бібліотека, яка дає вам безсерверну базу даних SQL, яка зберігається у файлі). У нього гнучка система типу, тому вам не доведеться серйозно виконувати схему, жоден сервер для налаштування / підключення до & відновлення вашої БД не такий простий, як видалення файлу. Він також дозволяє просто включити зображення БД разом з кодом у керування версіями, якщо це необхідно.

Це приклад, який використовується для демонстрації концепції, а не концепції саме по собі.

Концепція полягає в тому, що ви не приймаєте архітектурне рішення до останнього відповідального моменту , але не пізніше. Але насправді у вас часто є рішення про базу даних, яку ви будете використовувати дуже рано. Це може бути не ідеально, але це факт.

Як тільки це рішення буде прийнято, ви його активно не уникаєте. Збереження чогось у існуючій базі даних часто настільки ж просто, як зберігання у плоському файлі.

Але перехід від MySql на Linux до SQL Server у Windows може бути не таким простим, як перехід із плоского файла в будь-якому місці на SQL Server у Windows. Це справжній сенс. Тож, поки немає сумнівів щодо остаточного рішення, візьміть найпростіший можливий варіант, враховуючи зміни. Як тільки рішення буде прийнято, дотримуйтесь його.

Що ви наполягаєте?

Я в складній команді, і для одного додатку ми зберігаємо майже все в базі даних. Зауважте, якби ми цього не зробили, це не мало би зробити для цього додатка - збереження речей у базі даних є значною частиною її основної причини .

Отже: Що ви наполягаєте і що робить ваша заява? Якщо програма не на самому ділі все одно , де його дані зберігаються, то ви можете написати невеликий шар , який робить рішення (це рішення може бути збережено в файлі конфігурації де - небудь) з бази даних проти плоских файлів. Я думаю, вам потрібно оцінити вашу програму та ваші дані та вирішити, чи є сенс у вашому конкретному випадку вкладати час у постійність бази даних чи просто читати / записувати плоскі файли (що , можливо, буде швидшим за часом розробки).

Багато людей неправильно трактують цей аспект спритного, оскільки вони не повинні планувати заздалегідь майбутні функції. Ніщо не могло бути далі від істини. Те, що ви не робите, - це дозволяти планувати майбутні функції, щоб відкласти доставку цінності своїм клієнтам зараз.

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

Ще один мій хобі-проект - це корекція кольору відео та фотографії. Цей додаток буде абсолютно непридатним, не в змозі зберегти мою роботу в процесі роботи, і код, необхідний для цього, є розповсюдженим у всій програмі. Якщо я не зрозумію це з самого початку, то змінити це може бути надзвичайно важко, тому я витратив чимало зусиль на наполегливість вперед.

Більшість проектів потраплятимуть десь між ними, але вам ніколи не слід погано планувати майбутні функції, якщо це додасть мало зайвих зусиль. Бази даних можуть бути складними, але більша частина цієї складності прихована за надійним, добре перевіреним інтерфейсом. Робота, яку вам доведеться виконати у вашій програмі, може бути набагато меншою для бази даних, ніж для плоского файлу, оскільки всі функції, які база даних надає вам безкоштовно. Є "гібридні" варіанти, такі як SQLite, якщо ви ще не хочете мати справу з клопотами сервера баз даних.

Я думаю, ви ставите фокус на неправильних значеннях. У спритності, цінність бізнесу знаходиться у фокусі. Ви створюєте продукт, щоб доставити ділову цінність деяким кінцевим споживачам.

Якщо ви створюєте шар стійкості пізно або доповнюєте його по ходу, це ваша стратегія щодо надання ділової цінності клієнту. Я не вірю, що сам термін "спритний" диктує, чи варто робити те чи інше.

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

Це дуже хороша презентація, я можу порекомендувати вам переглянути її.

Але я з цим не згоден! Принаймні, до ступеня.

Я не вірю, що ви можете назвати історію користувача на "Готово", якщо історія користувача містить дані, які слід зберігати, а ви насправді не реалізуєте жодного типу стійкості.

Якщо власник продукту вирішить, що зараз саме час жити, ви не можете цього зробити. І якщо ви не почали впроваджувати наполегливість до кінця в проекті, ви також не маєте інформації про те, скільки часу знадобиться для впровадження шару стійкості, що залишає це основним ризиком для проекту.

Швидкі проекти, над якими я працював, не відклали стратегію доступу до даних. Але він був роз’єднаний, що дозволяє нам змінювати його по ходу. І вся схема бази даних не розроблена вперед. Таблиці та стовпці створюються так, як вони потрібні для того, щоб реалізувати збережений користувачем, який, зрештою, надає ділову цінність.

Для того, щоб побачити, на які запитання потрібно відповісти, перш ніж приступати до нового проекту, потрібно добре оцінити та досвід.

Якщо кінцевий продукт досі невідомий, тоді складання / складання прототипів швидко допоможе вам розібратися, і так допоможе повторне повторення. Це, звичайно, спричинить такий ризик, як виявлення пізно в процесі, що впровадження наполегливого процесу займе більше часу, ніж ви повідомили своїм зацікавленим сторонам.

Якщо кінцевий продукт добре відомий, то важливіше знати, як зрозуміти, як буде працювати наполегливість у вашій програмі. Існує ризик, що ви знайдете проблеми зі специфікацією свого продукту пізніше в процесі розробки.

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

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

Існують причини, що існують бази даних, і одна з них - це спростити розробники.

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

Забуті елементи даних, невідповідні структури даних та інші кошмари можна уникнути, створивши модель даних наперед.

Ви можете залишити свій фактичний вибір технології бази даних до моменту використання даних. Але більшість "наполегливих" технологій тісно пов'язані з програмуванням і навіть стилями дизайну. Якщо ви кодуєте реляційну базу даних, а пізніше вирішите перейти на значення хмарного ключа, вам потрібно буде повністю переписати половину коду.

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

Чи варто спробувати наполегливість у плоському файлі перед базою даних?

Так, ви повинні спробувати. Особливо, якщо ви ніколи цього не пробували. Як би не вийшло, ви щось навчитесь.