LINUX.ORG.RU

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

 ,


0

5

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

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

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

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

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

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

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

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

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

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

★★★★★
Ответ на: комментарий от eao197

Протокол здесь где?

Номер системного вызова и его параметры, по которому программы пишут и читают данные с устройств.

Надо же, я вам на это прозначно намекал, и вы даже это заметили.

В определение СУБД есть сетевой доступ? SQLite не СУБД?

И насколько удобно на NFS нескольким клиентам конкурентно работать в одним и тем же фрагментом файла?

Отлично работается. seek + read + write работают параллельно.

Расскажите мне как на open/close/seek/read/write обеспечить конкурентную работу с куском файла для нескольких клиентов.

По требованиям приложения. Если надо именно редактировать один и тот же кусок, то обычно байт блокировки блока добавляют.

А как по HTTP обеспечить конкурентную работу с куском файла для нескольких клиентов?

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

А зачем здесь был SQL? Исходя из объёма обновления весь объём исходящих сообщений с запасом помещался в оперативную память.

Все это дело можно было бы попробовать хранить полностью в ОП (собственно, с этого и начиналось), но тогда остро встают вопросы надежности.

Так писать состояние на диск, а весь поиск только в памяти. В случае падения, поднимать состояние с диска.

несколько рабочих серверов могут разбирать разные их наборы для доставки, а если какой-то из рабочих серверов затыкается или выходит из строя

А если сервер СУБД выходит из строя? Проще через файлы репликацию на каждый рабочий делать.

В общем, выглядит также странно, как https://classmech.ru/pages/databases/gamelife_sql/

Но согласен, не «СУБД всегда работает с редко изменяющимся контентом», а «по моему мнению, СУБД имеет смысл использовать только для работы с редко изменяющимся контентом».

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

С позиции Столярова — должны. Ведь почти все его пункты тогда становятся неактуальны.

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

Номер системного вызова и его параметры, по которому программы пишут и читают данные с устройств.

И это протокол? o_O

В определение СУБД есть сетевой доступ?

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

СУБД такой доступ могут предоставлять. Касательно файлов – большие вопросы.

SQLite не СУБД?

Как по мне – это встраиваемая БД. Т.е. в категории СУБД она одна из самых слабых по критерию «система».

Отлично работается. seek + read + write работают параллельно.

И как они обеспечивают целостность блока, который одновременно читается/пишется разными клиентами?

Если надо именно редактировать один и тот же кусок, то обычно байт блокировки блока добавляют.

И какой алгоритм захвата этого байта? Да еще когда работа ведется через сеть с ее непредсказуемостью и возможностью потерять соединение с одним из клиентов?

А как по HTTP обеспечить конкурентную работу с куском файла для нескольких клиентов?

Через сериализацию запросов к этому куску внутри HTTP-сервера.

Кстати, напомню, это ваш пример с HTTP-сервером. Если вам кажется, что здесь начинает попахивать маразмом, так это только потому, что я вашего примера придерживаюсь.

А зачем здесь был SQL?

Да хз, конечно же. Мозгов у нас на большее не хватило, да и NoSQL тогда были в детском возрасте. Как смогли, так и наговнякали.

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

Я правильно понимаю

да, всё так.

Вы переписали проект для Сбера или для таможни?

для Сбера

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

Внезапно выпавшее отделение это не КАТАСТРОФА, это ежедневная рутина.

а внезапно выпавший ЦОД - это остановка платежей в отдельно взятом городе.

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

К эластику делали подход наши предшественники, тоже не пролезло по производительности. + свои словари/токенайзеры прикручивать. Правда к постгре их тоже пришлось прикручивать, но это уже другой вопрос.

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

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

И это протокол? o_O

А чем это принципиально отличается от команд, при помощи которых программы пишут и читают с HTTP сервера?

И, в частности, доступ к данным разных клиентов,

Это у любой файловой системы есть.

которые работают на разных машинах.

Тогда все встраиваемые СУБД у вас не должны считаться СУБД.

И как они обеспечивают целостность блока, который одновременно читается/пишется разными клиентами?

Блочной записью на устройство.

И какой алгоритм захвата этого байта?

Любой желаемый разработчиком.

Да еще когда работа ведется через сеть с ее непредсказуемостью и возможностью потерять соединение с одним из клиентов?

dBaseIII+ и более поздние успешно работали с файлами при доступе по сети.

Кстати, напомню, это ваш пример с HTTP-сервером.

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

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

А чем это принципиально отличается от команд, при помощи которых программы пишут и читают с HTTP сервера?

Подумайте. Вряд ли у вас получится, но шанс есть.

Но вы этот сервер назвали СУБД.

Я сказал, что как только вы прячете непосредственную работу с файлами данных за каким-то фасадом, так этот фасад и становится для клиента «СУБД».

Для меня это был как раз пример программы, которая отлично обрабатывает данные без СУБД.

Только вот она данные не обрабатывает.

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

Я сказал, что как только вы прячете непосредственную работу с файлами данных за каким-то фасадом, так этот фасад и становится для клиента «СУБД».

Почему с файлами, а не с байтами блочного устройства? Чем фасад в виде файловой системы отличается от любого другого?

Только вот она данные не обрабатывает.

В чём разница между обработкой через HTTP GET/PUT и SQL SELECT/UPDATE? Или что вы понимаете под обработкой данных?

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

Зачем вообще что-то выравнивать, это задача рисовальщика.

Для работы с grep и diff. Эти инструменты производят сравнение построчно. Когда у вас строки по 70-80 символов, тогда поиск вхождений получается читабельным.

Вот поиск в строках больше 80 символов.

$ diff python_text.txt python_text.bk.txt
19c19
< Указатель это всего лишь адрес, а адрес в свою очередь это индекс массива. Вопрос переходит уже не в кодирование, а в Архитектуру ОС. Ведь ОС по сути каждому процессу в системе предоставляет свой собственный массив байт - виртуальное адресное пространство.
---
> Указатель это всего лишь адрес, а адрес в свою очередь это индекс массива. Вопрос переходит уже не в кодирование, а в Архитектуру ОС. Ведь ОС по сути каждому процессу в системе предоставляет свой собственный массив битов - виртуальное адресное пространство.

Теперь длинна строки стала 70 символов:

$ diff python70.txt python70.bk.txt
33c33
< собственный массив байт - виртуальное адресное пространство.
---
> собственный массив битов - виртуальное адресное пространство.

Гораздо читабельней.

В vim можно задать форматированние :set textwidth=70, gg перейти в начало файла, V режим выделения (Visual Mode), G перейти в конец файла, gq форматирование выделенного фрагмента.

Вот теперь ширина строки 75 символов

diff python75.txt python75.bk.txt
31c31
< каждому процессу в системе предоставляет свой собственный массив байт -
---
> каждому процессу в системе предоставляет свой собственный массив битов -
lbvf50txt
()
Последнее исправление: lbvf50txt (всего исправлений: 2)
Ответ на: комментарий от lbvf50txt

я не баню анонимусов. они часто тупые, но попадаются и вполне забавные. а тут недавно даже Эдди пробегал под анонимусом. этого персонажа я уважаю. жаль, что на ЛОРе его больше нет.

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

Скажите, а вам когда-нибудь приходилось делать свою СУБД? Пусть даже встроенную, пусть даже однопользовательскую?

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

Я написал не «клеветали», а «клевали», это сильно разные понятия. :) Проводили какие-то семинары, обсуждения (и осуждения), даже некий сайт «Антифоменко» был, некоторые пытались его достать по административной части (что уже, имхо, явный перебор, так можно и в лысенковщину скатиться, безотносительно к тому, чья теория верная, а чья ошибочная).

А вот Старикова как-то историки особо не комментируют. К сожалению.

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

Скажите, а вам когда-нибудь приходилось делать свою СУБД?

Смотря что именно под этим словом понимать. Если парсер SQL, то нет, если хранилище добавляемых и редактируемых данных с многопользовательским доступом через Интернет, то да.

Пусть даже встроенную, пусть даже однопользовательскую?

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

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

Смотря что именно под этим словом понимать.

СУБД – систему управления базами данных.

Если парсер SQL, то нет

Нет, даже если мы говорим об РСУБД, то парсер SQL – это только часть СУБД.

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

Судя по описанию вы делали информационную систему, полагаю заточенную под конкретную задачу. Но не СУБД.

Так вы же выше писали, что СУБД обязательно сетевая и многопользовательская, иначе это не СУБД.

А давайте цитату, где бы я говорил именно это.

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

Вопрос звучал таким образом:

Зачем вообще что-то выравнивать, это задача рисовальщика.

Под выравниванием я подразумеваю ручное выравнивание или через /bin/fmt. То есть разбивка длинных строк на короткие.

Рисовальщик не может это делать по той же причине, по которой он не может сам форматировать код. Тот факт, что код является некой привилегированной субстанцией, ничего не меняет. Если редактор будет непредсказуемым образом форматировать обычный текст, проблемы тоже возникнут, незаметным для пользователя образом. Он может вставить тот же код в обычный текст и через день обнаружить, что он у коллеги отрисовался по-другому.

Непредсказуемость иногда можно простить (например, в GUI). Но игра со стейтом всегда дороже.

Рисовальщик должен делать word-wrap. Но в случае простого текста (исключая языки разметки, ручной markdown или автоматический html) это не замена форматирвоанию.

Для читателей треда:

Внимание! Вы отвечаете на комментарий, автор которого [@anonymous] не может создавать новые комментарии в этом топике.
kaldeon
()
Ответ на: комментарий от lbvf50txt

Здесь можно ответить: но ведь есть же colordiff. Есть. Что не отменяет того, что он хоть и решает задачу, но делает это в два этапа: сперва пользователь обнаруживает, что не может найти различие простым взглядом, затем ищет разницу в цвете. Тогда как в случае с нормальным форматированием это всегда задача в один простой, предсказуемый (!) этап без пауз.

Хорошие форматирование и типографика упрощают любую задачу.

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

Под выравниванием я подразумеваю ручное выравнивание или через /bin/fmt. То есть разбивка длинных строк на короткие.

До чего мощная UNIX культура, каждый раз получается, что какие-то новые инструменты это уже давно известные утилиты: rake в Ruby это make, go fmt это просто fmt.

И когда заходишь снаружи все кажется таким сложным и непонятным. А когда идешь от Kernel и вдоль истории и культуры UNIX все современные инструменты продолжение давно известных.

Так как я от части захожу снаружи, то для меня обнаружение /bin/fmt после постоянного использования go fmt - сюрприз.

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

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

Это когда он успел стать покойным?

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

Упс.

Я почему-то был твёрдо в этом уверен… Приношу свои извинения.

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

Судя по описанию вы делали информационную систему, полагаю заточенную под конкретную задачу. Но не СУБД.

Любая информационная система заточена под конкретную задачу. SQL под работу с реляционными таблицами, например. Моя «СУБД» была заточена на получение последних записей с заданным отбором за заданное количество дней, начиная с произвольной даты и поиск по регулярным выражениям. В SQL нет ни того ни другого.

А давайте цитату, где бы я говорил именно это.

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

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

Любая информационная система заточена под конкретную задачу.

Только вот СУБД – это не «информационная система». Это инструмент, который может использоваться для создания информационных систем.

SQL под работу с реляционными таблицами, например.

SQL – это язык запросов. Это даже не СУБД.

Вы бы хоть определение СУБД в Wiki изучили.

«такой критерий необходимости использования СУБД как параллельный доступ к данным. И, в частности, доступ к данным разных клиентов, которые работают на разных машинах»

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

Из этого критерия не следует то, что вы пытаетесь мне приписать:

Так вы же выше писали, что СУБД обязательно сетевая и многопользовательская, иначе это не СУБД

Такого я не писал.

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

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

Логика, живущая в многостраничных запросах к DB не ведет к производительности. Чудес не бывает. У вас проблема со структурами данных, а не с sql-ом.

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

Только вот СУБД – это не «информационная система».

Вы бы хоть определение СУБД в Wiki изучили.

И по вашей ссылке:

define database management system (DBMS) as a «software system that enables users …»

определим СУБД как «информационную систему, которая позволяет пользователям …»

SQL – это язык запросов. Это даже не СУБД.

SQL это также наименование класса СУБД (бывают ещё объектные, ключ-значение, документные, …).

Т.е. если вам в вашей информационной системе нужен параллельный доступ к данным, в частности доступ разных клиентов с разных машин, то выбор СУБД может быть оправдан.

Из этого разве не следует, что СУБД должна предоставлять «доступ разных клиентов с разных машин»?

Такого я не писал.

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

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

Логика, живущая в многостраничных запросах к DB не ведет к производительности. Чудес не бывает.

Если данные хранятся в СУБД, то их надо максимально обрабатывать внутри этой СУБД, так как копирование в другую программу не бесплатное. Поэтому в пределе вообще вся логика переписывается на PL/SQL в хранимые процедуры.

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

И по вашей ссылке:

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

SQL это также наименование класса СУБД

Вообще-то наименованием класса СУБД, в которых применяется SQL, является «реляционные СУБД».

Из этого разве не следует, что СУБД должна предоставлять «доступ разных клиентов с разных машин»?

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

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

но если вы кроме неумения думать, еще и не умеете читать

Так это же вы не умеете читать: даёте ссылку и утверждение, которое противоречит тексту по ссылке.

Вообще-то наименованием класса СУБД, в которых применяется SQL, является «реляционные СУБД».

Реляционные СУБД шире. Clipper реляционная, но язык не SQL.

Но не всякую, а которая такой доступ поддерживает.

Вот теперь уточнили, тогда можно считать, что система, которую я писал, является СУБД. А ещё писал интерфейс для работы с DBF файлами, тоже, наверное, можно считать СУБД.

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

Если данные хранятся в СУБД, то их надо максимально обрабатывать внутри этой СУБД, так как копирование в другую программу не бесплатное. Поэтому в пределе вообще вся логика переписывается на PL/SQL в хранимые процедуры.

Premature optimization is the root of all evil – Donald Knuth

Осторожно! Мы подошли к границам догматизма. Скорость выполнения это всего лишь один критерий из множества. PL/SQL явно не самый читабельный и удобный для поддержки код. Сначала измерить, прикинуть, потом уже, если потребуется, оптимизировать «бутылочное горлышко».

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

Так это же вы не умеете читать: даёте ссылку и утверждение, которое противоречит тексту по ссылке.

Если вы забыли, то в нашем разговоре было две точки противоречия:

  1. Считать ли прямую работу с файлами (в частности через POSIX-интерфейс) в качестве СУБД.
  2. Уветверждал ли я, что только та СУБД, в которой есть поддержка параллельных подключений, может считаться СУБД.

Так вот ссылку на определение СУБД я вам дал касательно первой точки противоречия. Можете почитать что дает пользователям СУБД, чтобы понять, что ручная и прямая работа с файлами данных – это далеко не СУБД.

Реляционные СУБД шире. Clipper реляционная, но язык не SQL.

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

можно считать, что система, которую я писал, является СУБД.

Вы можете считать что угодно.

Только вот отличие СУБД от конкретной информационной системы в том, что СУБД позволяет делать разные информационные системы, заточенные под разные задачи, и схемы данных в разных системах будут разными. Для ведения счетов клиентов банка – своя, для Интернет-магазина – своя, для аптечного склада – своя. При этом СУБД во всех случаях может быть одна и та же (Oracle, PostgreSQL, MySQL, MSSQL, DB2 и т.д.)

Т.е. одна из ключевых особенностей СУБД является универсальность и отвязанность от конкретной прикладой задачи.

Из вашего описания, а именно:

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

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

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

Если данные хранятся в СУБД, то их надо максимально обрабатывать внутри этой СУБД

Всё так. Я и не предлагал обрабатывать все данные в самой программе. Я о том, что если для выборки нужны многостраничные sql-запросы, то скорее всего неправильно продуманы сами таблицы (и view’хи, если их вообще там используют)

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

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

Я не против реляционных. Я против втискивания в прокрустово ложе SQL.

Т.е. одна из ключевых особенностей СУБД является универсальность и отвязанность от конкретной прикладой задачи.

Тогда не делал. И в отношении таких СУБД поддерживаю Столярова. Чтобы использовать эту «универсальную» приходится сначала заметно обрезать прикладную задачу под семантику выбранной СУБД. Логичнее свой модуль для работы с БД написать.

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

Вы передергиваете. Одно дело SELECT с использованием JOIN + HAVING, и совершенно другое «вся логика переписывается на PL/SQL в хранимые процедуры».

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

Тогда не делал. И в отношении таких СУБД поддерживаю Столярова.

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

Что Столяров, что вы навязываете прикладным программистам подходы системного программирования.

Логичнее свой модуль для работы с БД написать.

На Ассемблере.

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

Теперь вы передергиваете.

В большинстве программ структура данных проста и вариантов запросов немного. Написание своего модуля БД занимает на порядок меньше времени, чем всего остального кода. Например, для хранения описания музыки: https://gigamonkeys.com/book/practical-an-mp3-database.

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

Я предлагаю (и, так понимаю, Столяров тоже) не использовать внешнюю библиотеку, если из неё нужно всего пара функций, которые можно написать не больше, чем за день.

На Ассемблере.

На языке, на котором написана остальная программа. Когда работа с данными на SQL, с логикой на питоне, а с интерфейсом на JS, то данные приходится урезать до общего знаменателя.

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

В большинстве программ структура данных проста и вариантов запросов немного

Просто интересно: откуда вы берете статистику о «большинстве программ»?

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

Потому что задач в стиле «имеется какой-то значительный объём разнородной, но при этом взаимосвязанной информации и стоит задача обеспечить его хранение и в нём поиск, причём никто заранее не знает, какие именно задачи будут решаться на этом массиве информации, какие именно поисковые запросы будут делаться» достаточно мало.

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

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

Потому что задач в стиле «имеется какой-то значительный объём разнородной, но при этом взаимосвязанной информации и стоит задача обеспечить его хранение и в нём поиск, причём никто заранее не знает, какие именно задачи будут решаться на этом массиве информации, какие именно поисковые запросы будут делаться» достаточно мало.

OK. Стало понятно о чем вы говорите.

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

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

// На минувшие выходные писал софт, предварительно поужинав грибами, собранными в лесу. Хорошее сочетание.

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

Но используют SQLite или вообще внешнюю СУБД. Потому что так привыкли.

Я предлагаю (и, так понимаю, Столяров тоже) не использовать внешнюю библиотеку, если из неё нужно всего пара функций, которые можно написать не больше, чем за день.

SQL используют потому что он сильно облегчает рефакторинг в прикладном программировании и убирает N+1 problem при освоении конструкции JOIN.

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

// На минувшие выходные писал софт, предварительно поужинав грибами, собранными в лесу. Хорошее сочетание.

Где ты грибы нашёл? Мы вчера сходили, нашли один подосиновик молоденький и всё…

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

Потому что задач в стиле «имеется какой-то значительный объём разнородной, но при этом взаимосвязанной информации и стоит задача обеспечить его хранение и в нём поиск, причём никто заранее не знает, какие именно задачи будут решаться на этом массиве информации, какие именно поисковые запросы будут делаться» достаточно мало.

Это типичная задача прикладного программирования: написать CRUD приложение учета чего либо. Когда заказчик хочет автоматизировать какой-то ручной труд и постепенно в процессе автоматизации выясняются нюансы. «Рррррааааазз и в дамки» не получается, приходится переделывать вот тут SQL и помогает.

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

lbvf50txt
()
Последнее исправление: lbvf50txt (всего исправлений: 3)
Ответ на: комментарий от Zhbert

Грибы были собраны несколько раньше :)

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

SQL используют потому что он сильно облегчает рефакторинг в прикладном программировании и убирает N+1 problem при освоении конструкции JOIN.

N+1 problem и вообще конструкция JOIN появляется только там, где используют SQL (с надстройкой поверх него в виде ORM).

А я предлагаю для хранения вообще не использовать SQL, а использовать структуры языка программирования (массивы, деревья, хеши). Для Си можно вообще через mmap записывать и при выгрузке/загрузке получать указатели на объекты.

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

А я предлагаю для хранения вообще не использовать SQL, а использовать структуры языка программирования (массивы, деревья, хеши). Для Си можно вообще через mmap записывать и при выгрузке/загрузке получать указатели на объекты.

Это понятно, вы предлагаете подход «системного программирования» в «прикладном программировании». Который коротко звучит так: все можно написать на С.

Там где хватит одной строчки на SQL, вы предлагаете написать собственную структуру данных, к этой структуре данных написать обертку для сохранения ее на диск, потом вы предлагаете загружать все данные в RAM… тра-та-та-тата-а-атата. Вместо решения вопросов стоящих перед бизнесом.

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

N+1 problem и вообще конструкция JOIN появляется только там, где используют SQL (с надстройкой поверх него в виде ORM).

Вы путаете ДЕКЛАРАТИВНОЕ программирование с ИМПЕРАТИВНЫМ программированием. N+1 - это проблема ИМПЕРАТИВНОГО программирования, когда разработчик указывает системе КАК надо выполнять действия: сначала получаем список, потом по каждому элементу этого списка смотрим. И тут на разработчике лежат детали оптимизации: где, как, в каком формате, какая структура данных.

ДЕКЛАРАТИВНОЕ программирование - это когда разработчик пишет что ему надо, а система сама уже выполняет запрос. SQL это декларативное программирование, где оптимизация лежит на системе, и разработчик вообще не думает как выполнять запросы. Тут разработчик пишет: дайка мне выборку из двух табличек. В этой ситуации все вопросы: где, как, в каком формате, какая структура данных - лежат на DBMS. Разработчик лишь отправляет запросы.

На практике N+1 это проблема принесения ИМПЕРАТИВНЫХ практик в ДЕКЛАРАТИВНЫЙ инструмент. По причине слабой подготовки. А именно не разобрались с JOIN. Но точно также N+1 может быть и вне SQL, когда без кеширования выполняют повторяющиеся запросы.

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

Вместо решения вопросов стоящих перед бизнесом.

Вот тут собака порылась. Часто мне кажется, что адепты «правильности», включая Croco, немного не хотят понимать разницу в подходе «делаем по фану круто и хорошо пока делается» и «надо ещё вчера, ибо бабки». В целом, первый подход вполне себе неплох, когда есть время и желание. Но не работает, когда делается что-то в реалиях рынка.

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

«надо ещё вчера, ибо бабки».

Абсолютно точно. «Надо было вчера» - это типичное состояние прикладного программирования.

  • + требуется предоставлять готовые прототипы
  • + требуется перестраивать программу под изменившиеся требования

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

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

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

Это понятно, вы предлагаете подход «системного программирования» в «прикладном программировании». Который коротко звучит так: все можно написать на С.

В прикладном программировании предлагаю использовать хранилище 1С для 1С (которое как SQL, но с объектами и типами-объединениями), AllegroCache для Common Lisp, Mnesia для Erlang, …

Си был просто примером.

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

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

Вместо решения вопросов стоящих перед бизнесом.

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

monk ★★★★★
()
Закрыто добавление комментариев для недавно зарегистрированных пользователей (со score < 50)