LINUX.ORG.RU

Его крокейшество о вредности СУБД, если архитектурно она для программ, а не живого человека

 ,


0

3

Давно уже что-то про Столярова Croco ничего не было =) А тут он повод недавно дал, расписав почему считает недопустимым использовать СУБД в архитектуре при проектировании софта. То есть, если для каких-то программ нужно хранение данных, его надо индивидуально под программу делать, а не подключать базы данных.

Можно обсудить. В принципе я сам не люблю для локальных данных применять базы данных, часто достаточно просто текстовых файлов и это даже надежно и быстро. Но в целом каким-то луддизмом отдает. Его сообщение ниже:

http://www.stolyarov.info/guestbook#cmt97

==============

Я придерживаюсь принципа несколько более узкого: недопустимо создание, распространение и использовние программ, для работы которых требуется СУБД.

Причины можно назвать, например, такие:

  1. СУБД — это лишняя внешняя зависимость, при том что вообще любые внешние зависимости суть хамство в отношении пользователей и мейнтейнеров;
  2. СУБД требует трудозатрат на установку, настройку и дальнейшее администрирование;
  3. СУБД способна упасть (и да, падает намного чаще, чем, скажем, тот же апач — вообще пока мои сайты жили на «традиционной» CMSке, именно СУБД была причиной всех случаев downtime моих сайтов, за исключением одного, когда на сервере физически осыпался жёсткий диск);
  4. СУБД требует от пользователя постоянно обновлять навыки, которые, возможно, больше ни для чего не нужны;
  5. СУБД хранит информацию пользователя в неочевидном для него виде; этим грешат не только СУБД, конечно, но СУБД мало того что хранят всё в бинарных файлах, которые без самой СУБД даже думать нечего разобрать, они ещё и вводят дополнительный слой хаотизации в виде схемы БД, провоцируя разработчиков софта на внедрение «решений», единственное «описание» которых остаётся в голове у автора;
  6. СУБД требует изрядных вычислительных мощностей и крадёт (а вовсе не повышает, как почему-то многие уверены) производительность.

Я, заметим, не рискну утверждать, что СУБД как сущность вообще никогда не может ни для чего применяться. Тут вопрос в том, кто на ком стоял: если главной целью является база данных как таковая, то есть вот имеется какой-то значительный объём разнородной, но при этом взаимосвязанной информации и стоит задача обеспечить его хранение и в нём поиск, причём никто заранее не знает, какие именно задачи будут решаться на этом массиве информации, какие именно поисковые запросы будут делаться и вот это вот всё, то да, СУБД вполне может оказаться адекватным решением, и даже для работы с ней могут создаваться вспомогательные программки. Это, конечно, не оправдывает существования языка SQL, который в любых его проявлениях представляет собой надругательство над здравым смыслом, но в целом СУБД как вид софта существовать, наверное, всё-таки может — но лишь в случаях, когда либо вообще нет никаких программ кроме неё самой, либо программы делаются для неё, а не она сама поддерживается для работы какой-то программы.

Всё это можно выразить и короче: СУБД, по-видимому, вполне имеет право на существование в ситуации, когда основным способом работы с ней будет непосредственное вбивание запросов на её языке запросов живым человеком. То есть когда именно вот это — основное, а всё остальное вспомогательное. В подавляющем большинстве случаев мы видим прямо противоположное: с СУБД как-то там общается некая программа (намного реже — больше одной программы, и это уже пограничный случай), а живой человек делает запросы либо только в рамках обслуживания всей системы, либо вообще никогда.

Когда же пишется некая программа, предполагающая применение для конкретных задач (а программы иначе, собственно, и не пишутся), и данные возникают исходя из этих задач, а не наоборот, то за саму идею задействования внешней СУБД нужно убивать на месте. Сугубо из санитарных соображений.

★★★★★

Всё это можно выразить и короче: СУБД, по-видимому, вполне имеет право на существование в ситуации, когда основным способом работы с ней будет непосредственное вбивание запросов на её языке запросов живым человеком.

Столяров - плотник.
Он больше рубанком …

anonymous
()

СУБД решает сразу несколько проблем, которые придётся решать самостоятельно при изобретении своего формата хранения данных. Не везде подходят текстовые файлы. Например, что ты будешь делать со своим текстовым файлом, если в него захотят писать два параллельных процесса? Блокировать, и пусть один ждёт? А если их не два, а тысяча (допустим, это веб)? Если всё это делать надо эффективно, по сути тебе просто придётся изобрести что-то вроде своей уникальной СУБД. Так не проще ли взять готовую тогда?

Добавлю, что важно, что СУБД вовсе не означает SQL. Есть какой-нибудь Valkey, скажем, и во многих задачах он будет эффективнее чем то, что ты наколхозишь (по крайней мере не потратив многие месяцы на допиливание именно вот этой самой работы с данными).

Ну а так да, бывает, что СУБД суют туда, где она совершенно избыточна, и можно было обойтись простыми текстовыми, yaml/json/xml, или dsv файлами.

CrX ★★★★★
()
Ответ на: комментарий от CrX

СУБД решает сразу несколько проблем, которые придётся решать самостоятельно при изобретении своего формата хранения данных. Не везде подходят текстовые файлы. Например, что ты будешь делать со своим текстовым файлом, если в него захотят писать два параллельных процесса? Блокировать, и пусть один ждёт? А если их не два, а тысяча (допустим, это веб)? Если всё это делать надо эффективно, по сути тебе просто придётся изобрести что-то вроде своей уникальной СУБД. Так не проще ли взять готовую тогда?

Мне это понятно, но не уверен, что ему. А ссылки на веб для него часто вообще как красная тряпка на быка =) Ту же талассу он сделал просто на файлах.

praseodim ★★★★★
() автор топика
Ответ на: комментарий от praseodim

Но работа с БД относится.

Ну это уже следующий уровень. Это как утверждать, что работа со спрингом и его бинами на том же уровне, что в целом понимание указателей и памяти. Всё-таки, это немного разные уровни, БД выше уже идёт, как бы после того, как научился кодить.

Zhbert ★★★★★
()
Ответ на: комментарий от DarkAmateur

Чего возмущаться тогда?

Ну так идеология сильна у человека. В целом я согласен с ним, что везде это дерьмо пихать не нужно, и сам пользую noscript.

Zhbert ★★★★★
()

Его крокейшество о вредности СУБД, если архитектурно она для программ, а не живого человека

Простим ему.
Все великие обычно чудоковатые.

anonymous
()
Ответ на: комментарий от anonymous

Гм., тогда и любые библиотеки излишни.

Или о чём он?

Ну он перечислил 6 пунктов. Внешние зависимости он тоже очень не любит. В принципе позиция понятная, я тоже их не люблю =) Но не все можно таскать с собой, даже если лицензии совместимы.

praseodim ★★★★★
() автор топика

Всё это можно выразить и короче: СУБД, по-видимому, вполне имеет право на существование в ситуации, когда основным способом работы с ней будет непосредственное вбивание запросов на её языке запросов живым человеком.

Странный вывод.

Не знаю, может я их как-то не так использую, но лично мне удобно «собирать» бд (сами данные) программно + иметь возможность сделать какие-то стандартные представления для повседневной рутинной работы + иметь возможность раз в случайный промежуток времени слепить супер-нестандартный мудрёный запрос.

По мне так надо от данных плясать - какие они сами по себе и какая работа с ними предполагается. Если данные хорошо ложатся в концепцию реляционных бд то не использовать СУБД а долбиться с текстофайловым велосипедом представляется лично мне излишним мазохизом)

frunobulax ★★★
()

По теме: в целом я со Столяровым не согласен. Но идея, что возможность вбивания произвольных запросов живым человеко – одно из ценнейших достоинств СУБД, вполне здравая. Особенно если это не корпоративное применение, где от живого человека такую возможность как раз прячут :) а личный проект.

hobbit ★★★★★
()
Ответ на: комментарий от praseodim

Внешние зависимости он тоже очень не любит.

Проблемы, как правило, в радикальности. Есть те, кто против любых внешних зависимостей, а есть те, кто против написания хоть одной строчки кода, если она уже где-то реализована. В первом случае получается ад и израиль в голове и тонны велосипедостроения на костылях (либо как в случае с сабжевым персонажем — много слов, преподавательство, но толком никакого практического кодинга — сплошное теоретизирование или учебные штуки). Во втором случае получается npm со всеми вытекающими — тоже абсурд.

Золотая середина нужна, умеренность. Если что-то уже реализовано, реализовано хорошо, и это объём кода чуть ли не больше всей твоей остальное программы, наверное, стоит таки использовать эту внешнюю зависимость. Ну или задуматься о реализации аналога, если та конкретная не устраивает, но именно хорошенько задуматься, головой, а не бросаться на амбразуру с воплем «потому что внешние зависимости не нужны!!!!111». Если же это несколько строчек кода, или даже одна-две функции, ради которых тащится огромная либа, в которой эти функции может даже и не самые основные — то наверное не стоит почём зря тащить.

В общем, как и во всём, гибкость нужна, «индивидуальный подход» и голова на плечах, а не готовое решение, основанное на очень простой для понимания, но радикальной и приводящей к полному абсурду, Идее.

CrX ★★★★★
()

вполне имеет право на существование в ситуации, когда основным способом работы с ней будет непосредственное вбивание запросов на её языке запросов живым человеком

Угу, сделал ошибку в DELETE/UPDATE и полетела по одному месту куча данных.

не оправдывает существования языка SQL, который в любых его проявлениях представляет собой надругательство над здравым смыслом

Он себе протеворечит, сначала говорит что «SQL не нужен», а потом утверждает что с БД можно взаимодействовать только напрямую из sql консоли.

Kolins ★★★★★
()

В целом я не то что бы не согласен. В фирме где я работаю долгое время использовали самописный индексер на си, который в пакетном режиме лопатил кучу текстовых файлов, выдавал на выходе несколько файлов в своём формате, эти файлы копировались на веб-серверы, и показывались через перловые/питоновые биндинги к этому индексеру.

Но потом и пакетная обработка стала занимать не 2 часа, а 10 (клиентам стало некомфортно что изменения так долго доходят до сайта), и в сишный код для добавления фич кроме чем мне оказалось смотреть особо некому, начальство решило что надо переписать на «нормальную БД» (postgresql).

За год-полтора еле-еле добились схожих рантайм-показателей производительности. Набив по пути кучу шишек в плане переноса фич (но это уже другая история). Для БД пришлось целиком выделить 4 мощных сервера с SSD, когда старая система сносно работала на виртуалках с обычными хардами.

Но зато теперь вместо людей со знанием си, которых, как известно, не существует, нам нужны люди, способные отлаживать и оптимизировать sql-запросы длиной в пару экранов кода.

PolarFox ★★★★★
()
Ответ на: комментарий от CrX

Золотая середина нужна, умеренность. Если что-то уже реализовано, реализовано хорошо, и это объём кода чуть ли не больше всей твоей остальное программы, наверное, стоит таки использовать эту внешнюю зависимость.

Это да, но он хочет, чтобы эту внешнюю зависимость, если уж без нее никак, можно было положить в каталог рядом с его проектом и компилировать заодно с ним. В принципе в своей талассе соблюдает этот подход.

praseodim ★★★★★
() автор топика
Ответ на: комментарий от Kolins

а потом утверждает что с БД можно взаимодействовать только напрямую из sql консоли.

Он говорит про прямое взаимодействие, не уточняя, что речь о консоли sql. Как я понимаю, ему для этого и GUI с формой для ввода тоже нормально было бы.

praseodim ★★★★★
() автор топика
Ответ на: комментарий от PolarFox

Для БД пришлось целиком выделить 4 мощных сервера с SSD, когда старая система сносно работала на виртуалках с обычными хардами.

Может еще быть важна масштабируемость. Если для расширения БД-системы достаточно купить еще несколько серверов и использовать стандартные механизмы, то для бизнеса это может быть намного привлекательнее

praseodim ★★★★★
() автор топика
Ответ на: комментарий от praseodim

Всё это можно выразить и короче: СУБД, по-видимому, вполне имеет право на существование в ситуации, когда основным способом работы с ней будет непосредственное вбивание запросов на её языке запросов живым человеком.

вбивание запросов на её языке запросов

Да вроде как он напрямую говорит что надо на SQL (Языке СУБД) запросы писать

Kolins ★★★★★
()
Последнее исправление: Kolins (всего исправлений: 1)
Ответ на: комментарий от praseodim

важна масштабируемость

Еще важно, если с командой которая разрабатывает/обслуживает продукт что-то случиться, то новая команда могда как можно оперативнее вникнуть и приступить к работе. В случае с готовыми инструментами (СУБД) вполне понятно какие требования предъявлять к соискателями, а в случае с самописными велосипедами на C, ну искать бородатых дедов, которые несколько месяцев будут копаться в коде чтобы понять «как оно работает».

Kolins ★★★★★
()

Его крокейшество о вредности СУБД, если архитектурно она для программ, а не живого человека

То что Столяров предлагает, больше похоже на нубовское решение проблемы.
Проще говоря - флуд.

anonymous
()

Он просто ниасилил. Поэтому, он просто рационализирует своё неосиляторство разумными и неочень аргументами.

СУБД способна упасть…апач

Я что-то пропустил? Что за СУБД Апач?

anonymous
()
Ответ на: комментарий от PolarFox

За год-полтора еле-еле добились схожих рантайм-показателей производительности. Набив по пути кучу шишек в плане переноса фич (но это уже другая история). Для БД пришлось целиком выделить 4 мощных сервера с SSD, когда старая система сносно работала на виртуалках с обычными хардами.

Это основной путь современного программирования! И нельзя сказать, чтобы в этом не было смысла, чтобы это было плохо.

Собственно, уход в сторону языков со сборщиком мусора и есть пример такого же подхода

anonymous
()
Ответ на: комментарий от praseodim

Та система тоже горизонтально масштабировалась на раздачу данных — создаёшь ещё один сервер, устанавливаешь на него питончик с нужными пакетами, и вписываешь сервер в список хостов на копирование Большого Файла с Данными.

PolarFox ★★★★★
()
Ответ на: комментарий от PolarFox

нам нужны люди, способные отлаживать и оптимизировать sql-запросы

Только запросы?

Я дежурно напоминаю, что по умолчанию PostgreSQL поставляется в конфигурации, способной запуститься на любом утюге и вести БД уровня записной книжки. Если же нужна ещё и производительность – надо менять настройки СУБД.

hobbit ★★★★★
()
Последнее исправление: hobbit (всего исправлений: 1)
Ответ на: комментарий от futurama

Сайт — типичный каталог товаров, с поиском (полнотекстовый, и по разрезам в духе категория/бренд/цвет/диагональ экрана итд). Позиций порядка 50-100млн.

СУБД должна была решить проблему, что для того, чтобы поправить весьма ситуативные вещи, с которыми бизнес хотел поэкспериментировать, вроде вариантов сортировки товаров, нужно было лезть в старинный сишный код. Ну и вышеупомянутая многочасовая загрузка, хотели чтобы товар после добавления было видно на сайте побыстрее.

Проблему пакетной загрузки не решили, но сделали чуть более удобоваримой (часть данных БД приходится наполнять из других систем в порядке односторонней синхронизации), теперь оно занимает 2-3 часа в самом неудачном случае, но ближе к десяткам минут в обычном.

Питонщики SQL боятся меньше чем си, так что тут наверное тоже какой никакой цели достигли, у отдела разработки теперь нет отмазки «мы не знаем как, там легаси».

PolarFox ★★★★★
()
Ответ на: комментарий от PolarFox

Конфиги перетюнили вдоль и поперёк, да.

max_connections = 6400, max_worker_processes = 1

тюнинг одного коммерческого продукта.

Эдак тюнить PostgreSQL - лучше уж и правда без PostgreSQL.

Toxo2 ★★★★
()

Когда же пишется некая программа, предполагающая применение для конкретных задач (а программы иначе, собственно, и не пишутся), и данные возникают исходя из этих задач, а не наоборот, то за саму идею задействования внешней СУБД нужно убивать на месте. Сугубо из санитарных соображений.

ИМХО, тут нужно обсуждать не уместность или неуместность применения СУБД, а степень ненормальности автора данного высказывания (в медицинском смысле).

А это чудо правда учило студентов в МГУ?

eao197 ★★★★★
()

никогда не используйте софт:

1. софт - это внешнаяя зависимость. вам придётся покупать комп и прочее железо.

2. софт требует трудозатрат на установку, настройку и дальнейшее администрирование.

3. софт способен упасть. и падает намного чаще, чем, например, стол или стул.

4. софт требует от пользователя навыков, которые больше ни для чего не нужны.

5. софт хранит информацию в неочевидных для пользователя бинарных даннных, имеет слои хаотизации типа ФС, чтобы запутать юзера и нанести ему психологический вред.

6. софт требует изрядных вычислительных мощностей, на счётах он нифига не работает.

поэтому сушите грибы и ягоды, которые вы собрали в лесу. это надёжный способ, которым пользовались наши деды и прадеды. и вы ни в чём не будете нуждаться.

Iron_Bug ★★★★★
()