Хіба SQLite трохи не занижена? [зачинено]


15

Перш ніж я задаю питання, дозвольте спершу описати свої думки щодо SQLite.

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

Наприклад: MS-SQL може мати набагато більше функціональних можливостей, масштабованості тощо. Звичайно, я не кажу, що важка установка - це причина не вибрати конкретну базу даних.

Не зрозумійте мене неправильно: MS-SQL - це чудова якість продукту. Я дуже досвідчений з MS-SQL; Я дуже добре розумію продукт як професіонала. Я просто віддаю перевагу менше в тих умовах, коли це насправді не потрібно (= не багато користувачів, <10-15).

Скільки функціональних даних бази ви реально використовуєте? На мій досвід, це часто просто звичайний SQL (SELECT, INSERT та UPDATE).

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

Наприклад: розгляньте програму ERP з, скажімо, 15 користувачами. Чому для цього не можна використовувати SQLite? Давайте визначимось: з мого професійного досвіду більшість часу користувачі цього типу додатків отримають доступ до бази даних приблизно 5-10% від загального часу, який вони використовують. В інших 90-95% вони просто переглядають інформацію на екрані, вводять дані в сітку / форму, і коли вони зберігають свій вхід, що не більше 1 секунди часу в базі даних. Fe: 1,5 хвилини вхідного часу проти 1 секунди економії часу.

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

Деякий хлопець, який повинен думати так само, як я, навіть створив клієнт-серверне рішення для SQLite: SQLitening . Це змусило мене більше переконатися, що я, можливо, не обманюю себе.

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

Багато наших клієнтів не витрачають багато коштів на обладнання, тому я часто стикаюся з єдиним сервером із усім, що на ньому (Exchange, SQL (s), клієнтами тощо), і тому майже не затамував подих. Якби я міг доставити товар, який не має високих системних вимог, то мій клієнт був би радий. SQLite не додає ваги (принаймні, не дуже багато), що робить MS-SQL. Тому я б не вибрав SQLite, оскільки він безкоштовний, дешевий або простий в установці. Я вибрав би це з практичних / технічних причин.

FYI: За моєю професією ми продаємо продукцію (на замовлення та стандартну, в основному пов'язану з ERP) клієнтам, де в середньому не більше 5-6 людей будуть використовувати продукт. Є деякі винятки, але не більше 10-15 користувачів.

Питання: чи я правий, думаючи, що я можу використовувати SQLite для деяких багатокористувацьких додатків, як, наприклад, описаний нами приклад? Чи є якісь технічні недоліки, про які я повинен знати? Які ваші переживання (негативні чи позитивні) допоможуть зробити правильний вибір?

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


9
Вибачте, але додавши "Я прав?" не перетворює гніту в питання.
пдр

1
@pdr: Чому ти вважаєш це сказом? Я не негативно оцінюю MS-SQL або інші бази даних; це в основному всі прекрасні продукти. Я просто ділюся своїми думками та зацікавлений почути думку інших програмістів. Нічого більше, нічого менше.

3
Тут немає жодного питання, лише пошук валідації. З питань поширених запитань: "Ви повинні задавати лише практичні, відповідальні запитання на основі актуальних проблем, з якими ви стикаєтеся. Чатливі, відкриті запитання зменшують корисність нашого веб-сайту та відштовхують інші питання з головної сторінки". programmers.stackexchange.com/faq
pdr

1
@pdr: Я це розумію, але я чесно мав намір поставити питання тут. Можливо, я не був зрозумілий, тому перефразував питання.

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

Відповіді:


8

Є безліч випадків, коли SQLite є безліч. Користувач, відділ чи компанія його рідко переростають (ми про це не чуємо так багато, тому що ніхто не дзвонить програмісту, якщо програма працює просто чудово.) Ви можете зробити таку ж аргументацію для файлу MS Access (Windows) або Компактне видання SQL Server (потрібна деяка установка). Вони всі досить хороші для локальної програми, тому що вам не потрібно так турбуватися про безпеку файлу.

У багатокористувацькому сценарії в локальній мережі файл переходить у загальну папку, до якої потребують доступу всі користувачі - безпека дзвінків. Просте обслуговування або будь-які зміни структури таблиці, як резервне копіювання або додавання стовпця, не дозволяють іншим користувачам отримувати доступ. Минулої ночі резервна копія не спрацювала, оскільки хтось забув вийти з програми. Що станеться, коли ви хочете зробити резервну копію посеред дня? Усі раціоналізують, що вони не потребують резервного копіювання протягом дня через технічні обмеження своєї бази даних. У якийсь момент установка SQL Server Express / іншого еквівалента на вашому сервері потребує початкових налаштувань та конфігурації безпеки, більше задіяна на передньому плані, але не потребує невеликого обслуговування.

Завжди є стурбованість масштабністю / переробкою. Навіть якщо кількість користувачів або кількість даних все ще керуються, хтось завжди має ідею використовувати живі дані на якійсь інтрамережі чи іншому веб-сайті / браузерному інтерфейсі. Файлові бази даних представляють проблеми. Потрібна лише одна людина, яка хоче отримати доступ до файлу даних через VPN (додаток встановлено на своєму ноутбуці), щоб створити проблему "масштабування". Ви можете створити додаток, щоб дозволити відключеним користувачам, які можуть синхронізуватися під час повернення. Просто здається, що це не варто для випадкових користувачів поза офісом.


Ви можете зробити той же аргумент для SQL Server Compact Edition, але не для бази даних MS Access. Бази даних доступу трактуються так, як справжня база даних, але працюють більше, як спільні файли. Вони є крихким рішенням; SQL Server Compact насправді є кращою, швидшою, надійнішою альтернативою, яка все ще працює з фронтенсами Access. Я підозрюю, що SQLite істотно довговічніший за базу даних Access, хоча технічно це спільне файлове рішення.
Роберт Харві

@RobertHarvey - У нас є бізнес-вимоги, коли MS Access протягом 10 років був досить хорошим (тобто кращим, ніж Excel) рішенням. Коли укладається велика угода, ми повинні щось розробити. Користувачів живлення, що володіють навичками Access, набагато простіше знайти та використовувати їх. Функціонал повинен існувати до певної дати, але нам пощастило, що масштабність, продуктивність, зростання даних та безпека ніколи не були чинником. Оновлення доступу - це вже інша історія.
JeffO

Не розумій мене; Я думаю, що Access чудовий. Але SQL Server Compact - це моя мінімальна потреба в резервних копіях для будь-яких нових додатків Access, де користувачі діляться даними.
Роберт Харві

@RobertHarvey - мені доведеться розібратися в цьому. Дякую
JeffO

12

Я думаю, що це чудово використовувати, коли вам потрібна "внутрішня" база даних. Тобто база даних, з якою ваша програма / код буде взаємодіяти, але це не буде безпосередньо пов’язано з основною причиною існування вашої програми. Замість використання величезних відображень в пам'яті або кеш-менеджерів, ви можете, наприклад, використовувати таку базу даних. У мене є дуже конкретний приклад цього, оскільки я нещодавно використовував це в тестових випадках JUnit / DBunit, коли мені потрібно було підключитися до бази даних, виконати певну роботу, прочитати дані та стерти все наприкінці. Оскільки для створення бази даних вам потрібно створити лише порожній файл, зробити це було досить просто.

Я бачу ще одне використання: коли у вас є лише один користувач. Так, це можливо, подумайте, наприклад, "Firefox" або "Opera" :-)

Крім того, на веб-сайті SQLite вони дуже чесно ставляться до цього і пояснюють, що НЕ ВИКОРИСТОВУЄТЬСЯ (див. Параграф "Ситуації, коли інша RDBMS може працювати краще")

ps: пов'язане з коментарями до Sql Server Express, так, його потрібно "встановити". У мене виникли проблеми з оновленням особисто (мені довелося видалити деякі ключі реєстру, пов’язані з попередньою версією, щоб мати можливість встановити 2008 R2). Однак, якщо ви хочете порівняти SQLite з базою даних, розробленою Microsoft, перегляньте Sql Server Compact Edition , яке вам не потрібно встановлювати (див. "Розгортання на основі приватних файлів").


Я подивився на CE, але якось здається, що SQLite краще / швидше / простіше. Не знаю точно, я не використовував / тестував CE достатньо, щоб бути впевненим.

5

Наприклад: розгляньте програму ERP з, скажімо, 15 користувачами. Чому для цього не можна використовувати SQLite?

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

Скажімо, у вас є 100 користувачів, кожен працює протягом 60 секунд, заповнюючи форму, а потім подаючи її. Тож вам потрібно обробити близько 1,6 транзакцій за секунду. Модель даних є складною, а збереження форми передбачає читання та запис у великі великі таблиці, можливо навіть спілкування з іншою системою, тому кожна «форма подання» призводить до транзакції, яка займає 2 секунди. Але SQLite не може одночасно обробляти транзакції, тому це може обробляти лише 0,5 транзакцій за секунду. На жаль

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


Я розумію і згоден. Але в моїй професії я дійсно не маю клієнтів, які використовують наші продукти (стандартні та спеціальні, в основному пов'язані з ERP) з більш ніж 10 людьми. В середньому це навіть 5-6 користувачів. Я перефразую своє запитання.

4
@Marcus V: Питання: якщо клієнт виріс багато і виявив, що створений вами додаток стає неможливо повільним у використанні, і ви скажете їм причину, що СУБД не може обробляти стільки користувачів, і вони запитують " чому ви не використали кращу СУБД ", як ви думаєте, що відповідь" їх важко встановити "буде отримана? Я можу вам сказати, якою була б моя реакція: я думаю, що "це любитель. Мені потрібно знайти когось іншого, щоб написати моє програмне забезпечення".
Майкл Боргвардт

Ти маєш рацію. Я не думаю, що ти це мав на увазі саме так, але можу запевнити, що я не аматор. Я обов'язково користуюсь "справжніми" системами СУБД, якщо ситуація попросить цього. Наша продукція ліцензується для багатьох користувачів. Я б розвивався за допомогою SQLite, лише коли знаю, що кількість користувачів порівняно невелика (<10-15). Якщо клієнт перевищить ліміт, що в нашій базі клієнтів відбудеться не скоро, ми завжди можемо відносно швидко / просто перетворити їх в іншу базу даних. Це не ракетна наука;). На основі ваших зауважень я перефразував питання, щоб зробити його більш зрозумілим.

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

1
@Jeff O: Я думаю, ви неправильно зрозуміли мої наміри. Я не вибираю SQLite, тому що він безкоштовний, дешевий та / або простий в установці. Я вибрав би це лише тому, що він невеликий, швидкий та зручний для ресурсів. Тож це в основному з практичних / технічних причин. Багато наших клієнтів не витрачають багато коштів на обладнання, тому я часто стикаюся з єдиним сервером із усім, що знаходиться на ньому (Exchange, SQL тощо), і тому майже не затамував подих. Якби я міг доставити товар, який не має високих системних вимог, то мій клієнт був би радий. SQLite не додає ваги, як це робить MSSQL.

4

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

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

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


2
Ти маєш рацію. MS-SQL Express - продукт прекрасної якості. Просто я вважаю це трохи роздутим і використовую занадто багато ресурсів. У наш час ПК / сервери це не проблема. Я просто та стара людина, яка все ще вважає, що більш потужне обладнання не означає, що я повинен нехтувати / витрачати ресурси, якщо зможу цього уникнути. Менше краще ...;).

2
база даних з двигунами DB може оптимізувати доступ, кешуючи її пам'яттю, а не читаючи / записуючи з дисків. Але я не впевнений у
такій

1
@sarat: Afaik SQLite інтенсивно використовує кеші пам'яті.

2

Я не розглядаю SQLite як серйозну базу даних, якщо ви маєте справу з кількома ГБ даних щогодини. Це стає болісно повільним і знижує продуктивність всієї програми. Вибачте, але я не згоден з вашим захопленням SQLite :-)


1
Я поважаю вашу думку. Я просто практична людина. Коли я вибираю інструмент, я його вибираю, тому що вважаю це найбільш реальним / практичним рішенням. Я не захоплююся SQLite, але захоплююсь тим, як їм вдалося так багато вкласти в такий невеликий, ефективний та швидкий пакет. Як я вже згадував у своєму запитанні: якщо MS-SQL є кращим інструментом для певної роботи, я б просто вибрав це. Але, як я пояснив, у багатьох випадках я справді вважаю, що SQLite просто чудово підходить.

Цей обсяг даних про історію є великим, якщо.
JeffO

@Jeff O: Правильно. Я б вибрав SQLite лише в тому випадку, якщо кількість користувачів порівняно низька (<10-15), а також загальний обсяг даних не високий. За нашим досвідом, загальний розмір бази даних часто становить 300-400 МБ і майже ніколи не перевищує 1 Гб.

1

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

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.