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

Я робив програму Python для вимірювання зростання codereview.SE . Мій підхід полягав у тому, щоб "Статистика сайту" відображалася на першій сторінці та зберігав їх на моєму жорсткому диску. Я планую робити це раз на день. Поки що я зробив достатньо, щоб отримати статистику та додати їх до текстового файлу. Скрипт python можна переглянути на github . Формат, який я використовую, такий

22-08-2013

questions 9073
answers 15326
answered 88
users 26102
visitors/day 7407

22-08-2013

questions 9073
answers 15326
answered 88
users 26102
visitors/day 7407

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

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

PS: Якщо можна додати кращі теги, будь ласка, зробіть це. У мене були сумніви щодо тегів, які можна було б додати.

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

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

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

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

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

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

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

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

Отже, використовуйте СУБД, коли це те, що вам потрібно. Використовуйте його, коли у вас є багато даних, коли вам потрібно мати доступ до цих даних швидко та, можливо, способами, які ви не можете повністю передбачити на самому початку. Якщо у вас є різні типи даних (різні типи записів), які з'єднані один з одним, використовуйте RDBMS, щоб ви могли відповідним чином співвідносити різні записи.

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

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

Звичайно, це буде викликом судження, але три основні критерії, які я вважаю, - це чи потрібно відповідати ACID , наскільки складні дані і, нарешті, скільки речей потрібно їх прочитати / записати. Поки ви просто читаєте і пишете один рядок на кожен додаток, і ваш додаток є єдиним додатком, який робить читання чи запис, ви, ймовірно, можете пропустити базу даних. Після того, як ви починаєте мати численні програми читання чи запис, або ваша структура даних стає складною (особливо, якщо вона має зв'язки між окремими рядками), то БД починає виглядати дійсно привабливо.

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

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

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

Якщо ви хочете пограти з SQL і що він може робити, SQLFiddle.com має кілька різних моделей RDBMS, з якими можна грати (виконувати запити, створювати схеми тощо)

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

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

На мій досвід, якщо ви абсолютно не знайомі з базами даних, вам може бути легше використовувати щось на зразок couchdb: http://couchdb.apache.org/, яке не є sql, і ви можете використовувати безпосередньо JavaScript або python тощо для запитів.