Який найкращий спосіб визначити, коли доцільно використовувати базу даних?

Я розпочав свою кар'єру програмування у веб-розробці за допомогою PHP та MySQL. Я досить звик використовувати db для зберігання найбільш динамічних даних, а також деяких даних налаштувань / параметрів. Іноді даних було б дуже багато, тоді як записів в інших випадках у таблицях було б мало. Мені це здалося природним, і наскільки я знаю, це більш-менш прийнятний підхід у веб-розробці. (Будь ласка, виправте мене, якщо я помиляюся ...)

Я зараз заглиблююся в настільні додатки, і моя природна схильність полягає в тому, щоб знову використовувати db для зберігання багато інформації, яка буде генерована за допомогою використання програми. Однак, наскільки я можу сказати, я не бачу програм (які я використовую), які використовують db дуже часто. [EDIT: З тих пір було зазначено, що це було помилковим припущенням, що багато додатків використовують легкі dbs, вбудовані в саму програму.] У чому причина цього? У який момент доцільно використовувати db? Чи є стандарти щодо цього? Також які причини НЕ використовувати db для розробки програми для настільних ПК?

якщо ваша програма орієнтована на документи, зберігайте речі у файлі документа

якщо ваша програма має справу з більш структурованими даними, занадто багато для одного документа (наприклад, XML-документа), використовуйте базу даних

Система баз даних традиційно сприймається як досить важка послуга - яку ви не обов'язково хотіли встановлювати на кожному клієнтському апараті там. Я фактично був у ситуаціях (розробка додатків GUI для настільних комп'ютерів, де потрібно було зберегти багато даних), де справжня система БД була б «ідеальним» рішенням, але тому що в той час єдині наявні бази даних були відносно важкими, ми замість цього подали плоскі файли даних.

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

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

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

При цьому, системи баз даних досить багато використовуються в настільних додатках. Задовго до Інтернету настільні програми були підключені до СУБД. В першу чергу для додатків, які не базуються на документах. Хоча в ці дні, з кращою доступністю легких двигунів, ви бачите, що лінії трохи розмиті. Наприклад, я використовую db SQLite як документи в кількох своїх додатках.

Одне, на що ви можете заглянути, - це легкі бази даних, які не потребують фактичної роботи бази даних. наприклад, на фронті Microsoft є SQL Server Compact , який є безкоштовним, вимагає лише одного файлу для бази даних та деяких DLL-файлів, доданих до вашої програми, і з точки зору розробника поводиться приблизно так само, як "справжній" SQL-сервер.

Я впевнений, що подібні варіанти є і на інших платформах.

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

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

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

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

З іншого боку, використання вбудованої бібліотеки баз даних (BDB, Tokyo Cabinet, SQLite, MS-SQL * сервер Compact тощо) є ще одним чудовим підходом.

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

Наприклад, врахуйте:

#include "superheader.h"

int main()
{
    int row=2, column=2;
    DatabaseType db;
    db.ConnectTo("programDB", "user", "pass");
    db.setTable("messages");
    string hello_world=db.fetch(row, column);
    cout<<hello_world;
    return 0;
}

Добре, що це надто спрощено, але очевидно, що це занадто багато. Немає реального сенсу мати такий рівень управління даними для "Hello World"

Зазвичай, як правило, я використовую базу даних, якщо у вас є безліч наборів даних, особливо якщо вони однозначно відрізняються АБО використовуйте базу даних, якщо обсяг даних досить великий. Бази даних в цілому пов'язані з деякими накладними витратами, але є багато таких, яких насправді не так багато. Наприклад, невеликі, легкі бази даних в пам'яті іноді корисні для невеликих проектів з важкою обробкою, плануванням або великою кількістю динамічних змін даних.

Існують різні стилі кодування, багато разів багато нічого поганого з базою даних, але більшість з нас просто не збираються йти «так далеко» для основних завдань. Є й інші випадки, коли правильна база даних може принести переваги продуктивності. Постарайтеся особливо зрозуміти відмінності в тому, де будуть знаходитися дані, як довго вони будуть знаходитись і що буде змінювати їх протягом їхнього життя.

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