Як RDBMS можна вважати пристрастю?

Завершивши рівень обчислювальної техніки в 2003 році та отримавши ступінь з обчислювальної техніки в 2007 році та вивчивши свою торгівлю в компанії з великим використанням SQL, я висунувся на ідею використання реляційних баз даних для зберігання.

Тож, не дивлячись на відносно нову розробку, я здивовано прочитав коментар (на https://softwareengineering.stackexchange.com/q/89994/12436 ), який сказав:

[Деякі розробники] зневажають [SQL] і думають, що це і RDBMS - привид

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

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

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

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

Справжнє рішення об'єктно-реляційної невідповідності - OODBMS , які, на жаль, не отримали особливої ​​тяги. Популярним двигуном, який підтримує OOBD, є PostgreSQL, який є гібридним OO / RDBMS. Інша OODBMS - Zope Object DB , яка вбудована в Python і в типових умовах використовує RDBMS як основний двигун.

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

Ні OODBMS, ні NoSQL не є "просто плоским файлом".

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

Чи повинні досвідчені програмісти знати запити до бази даних?

Я висловив твердження, що якщо використовується база даних RDBMS, що, незважаючи на Linq або ORM, розробник повинен володіти передовими знаннями SQL.

Це було дуже непопулярним твердженням, як видається, через поважні розбіжності щодо важливості SQL, до менш поважного мислення, що RDBMS по суті поступається базам даних NoSQL, як MongoDB.

РЕДАКТУВАННЯ: Щоб додатково додати свою претензію, я наводжу SK-логіку користувача:

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

примха :

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

RDBMS існують протягом багатьох віків (принаймні, з точки зору CS), тому той, хто сказав, що або мав на увазі сказати щось інше, або не зрозумілий.

Альтернатива RDBMS - це не просто плоский файл. Коли я навчався в школі, OODBMS була новою річчю, і мій професор був правильний, коли він назвав це пристрастю. Вам слід поглянути на різні моделі та відзначити тенденції. Я бачив все більшу залежність від OLAP, і хотів би зробити ставку на нову багатовимірну систему, яка може швидше обробляти дані, знаходиться недалеко.

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

Без контексту важко визначити, хто / чому твердження про те, що RDBM вважаються придуманим.

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

Є й інші альтернативи, такі як NoSQL, які, схоже, зростають у популярності з проектом з відкритим кодом.

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

Реляційні бази даних - це примха в тому ж сенсі, що мікрокомп'ютери - це примха.

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

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

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

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

Концепція RDBMS (і її основний засіб SQL) являє собою крок у технології, яка, як і багато інших, може бути замінена кращими, тобто все.