LINUX.ORG.RU

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

 ,


0

4

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

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

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

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

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

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

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

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

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

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

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

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

Ну да - бухгалтерии типа ООО три ларька. А для крупных компаний приходится из топовых СУБД выжимать максимум и оптимизировать. И там даже в бреду никому в голову не придет фрикодить операции с БД.

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

@monk, просто привёл пример задачи

значит я не понял о чем речь. Однако такие задачи решаются именно с использование субд. Реляционная БД сильно упрощает разработку подобного ПО. Вся бизнес логика может быть реализовани в субд. Его утверждение не верно, предполагаю, что он не очень понимает данную предметную область, а именно бухгалтерию в данном случае.

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

не важно кем они считались. Но ежели сынишка хозяина в порыве страсти дефлорирует и придушит рабыньку - преступником он не станет. де-юро. ну или еслли твой папа их familia разорится - то тебя продадут в другую familia a там все на усмотрение патрона.

Qui-Gon ★★★★★
()
Ответ на: комментарий от ivama

Предметная область:

документы: накладные, платёжки, оприходования, списания, …

справочники аналитики: товары, склады, контрагенты, …

Проводка с полями:

  • документ: один из элементов документов
  • счет дебета
  • аналитика1 дебета : один из элементов справочников аналитики или документов
  • аналитика2 дебета
  • аналитика3 дебета
  • счет кредита
  • аналитика1 кредита
  • аналитика2 кредита
  • аналитика3 кредита
  • сумма

Как описать проводку на SQL (можно любой современный, хоть Oracle, неважно)?

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

Его Iron_bug забраковала: ООП плохо. И, объективно, у этого варианта есть проблема с контролем ссылочной целостности.

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

Вот! Прошу правильно спроектировать журнал проводок. Все поля приведены, что в них может быть - тоже. Пока все SQL варианты, что видел, масштабировались при увеличении количества видов документов и аналитик просто ужасно.

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

что ты читать-то собрался в Древнем Риме? вывески на тавернах? книг в широком доступе не было. и что писать? и главное, где и чем. вопрос «грамотности» куда сложнее, чем ты себе представляешь. для большинства людей письмо не было нужно от слова совсем.

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

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

Реляционная БД сильно упрощает разработку подобного ПО. Вся бизнес логика может быть реализовани в субд.

Продемонстрируй, пожалуйста, для этого примера:

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

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

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

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

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

И туда тоже предпочитают ставить 1С с PostgrePro, в котором уже всё написано, чем писать самостоятельно.

Дешевле удвоить число серверов, чем переписать даже базовую 1С: Бухгалтерию. Также, как ставят Linux, а не пишут сами ОС реального времени для своих задач. Слишком много писать и слишком долго тестировать.

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

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

Ну тогда точно от SQL лучше держаться подальше.

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

Его Iron_bug забраковала: ООП

Вообще не понимаю, зачем ты притягиваешь за уши ООП к субд. В данном случае это параллельные сущности. Твоя задача спроектировать субд. Ознакомься с языком sql, как работает твоя конкретная субд (могут быть нюансы) и ознакомься с тем как работает бухгалтерия, т. е. погрузись в предметную область..

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

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

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

СУБД для примера можешь выбрать любую.

ООП я привёл в пример, так как если считать, что у поля документ тип документ, а у поля аналитика, соответственно, тип аналитика, то через ООП можно реализовать, унаследовав документы и объекты аналитики от этих базовых классов (некоторые документы будут унаследованы от обоих). Но ООП в SQL нормально не работает. Ссылку на пример реализации я привёл.

Как, по-твоему, правильно реализовать журнал проводок на SQL?

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

что ты читать-то собрался в Древнем Риме? вывески на тавернах? книг в широком доступе не было. и что писать?

Хотя бы даже из сведений в статье на википедии Издательское дело в Древнем Риме следует, что книги в греко-римский период были таки в широком доступе, были массы библиотек и скрипториев, в которых профессиональные переписчики наловчились очень быстро переписывать книги. Тираж в 1000 экземпляров не был чем-то невероятным.

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

Поэт Марциал сохранил в своих произведениях упоминания о ценах на его книги. От 1 до 5 динариев. Доход рядового легионера ( Цены на продукты и зарплаты в Древнем Риме составлял примерно 120 динариев (1200 ассов) в год. Доход неквалифицированного рабочего 750 ассов, квалифицированного 2000 и более. То есть, вполне посильно было хотя бы изредка прикупить свиток даже для небогатых римлян.

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

Ну да - бухгалтерии типа ООО три ларька. А для крупных компаний приходится из топовых СУБД выжимать максимум и оптимизировать. И там даже в бреду никому в голову не придет фрикодить операции с БД.

эээ... мдя. сразу видно опытного мошенника специалиста по выжиманию!

мы в своё время на махоньком слабеньком сервере (сейчас у телефонов процессоры мощнее и памяти на порядки больше) написали бухгалтерию управления ЖД. со всей фигнёй, а там её было немало. в 1-С они просто не влезали со своими отдельными планами счетов и особыми требованиями. да и по объёмам это было слишком много для тогдашней ещё только начавшей набирать обороты 1-С.

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

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

Это просьба доказать заявление «Реляционная БД сильно упрощает разработку подобного ПО. Вся бизнес логика может быть реализовани в субд. Его утверждение не верно, предполагаю, что он не очень понимает данную предметную область, а именно бухгалтерию в данном случае».

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

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

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

А вы так и сидите во временах трех ларьков. Ну jedem das seine, как говорил добрый немецкий доктор.

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

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

Берём производство с партионным учётом. Даже простейшую столовую.

На каждое блюдо десяток полуфабрикатов, на каждый полуфабрикат несколько ингридиентов. Итого полсотни проводок. В столовую пришло двести человек, каждый взял три блюда. Итого 30000 проводок в день. В год 10 миллионов. А таких столовых в крупном предприятии сотня. Плюс куча производств с огромным ассортиментом болтов-гаек, которые также учитываются в бухгалтерии.

Один супермаркет легко миллион записей в год генерирует: вот у человека 50 тысяч проводок на рознице: https://axforum.info/forums/printthread.php?t=12861

Понятно, что если компьютер не вытягивает, то всё сводят к котловому учёту вплоть до выкидывания аналитики по товару.

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

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

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

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

какие полсотни проводок? ты что, каждому клиенту продаёшь полуфабрикаты по отдельности? очевидно, что нет.

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

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

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

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

По дефолту наследование в том же postgres не хранит ничего в таблице Document и добавляет все общие поля явно в дочерние таблицы. Это вариант если запросы, которые должны возвращать список документов из разных таблиц, сравнительно редки (иначе будет UNION ALL, который нужно будет сортировать, что может быть хуже, чем «все поля в одной таблице» и «все поля в одной таблице, но внутри json, опционально с generated column если приложению удобнее так»).

anonymous
()

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

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

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

Студент никак не может реагировать:

  1. Во-первых студент туп и сидит он только чтобы в армию не ходить да и просто недостаточно ещё шарит.
  2. Студент зависим от препода - будешь сильно пперечить - высушат
lesopilorama
()
Ответ на: комментарий от vbr

Я видел мнение, что в 100% случаев для хранения данных надо использовать sqlite. Т.к. он строго лучше любого другого формата. Даже для передачи данных надо передавать sqlite файл, а не XML/JSON/Protobuf

Очень закрытая и сложная БД для этого. Закрытая в плане приёма кода в репу, критики, доработок. Сложная в плане оверкилл для описанное задачи как на танке за хлебом.

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

На каждое блюдо десяток полуфабрикатов, на каждый полуфабрикат несколько ингридиентов. Итого полсотни проводок. В столовую пришло двести человек, каждый взял три блюда. Итого 30000 проводок в день

Это откуда такая наркомания, что под каждый ингредиент в отдельном реализованном блюде нужна отдельная проводка?

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

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

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

и никакой студент не «зависит» от препода

Жосткий упоротый бред. Тебе ставят неуд и ты валишь в армию или теряешь стипендию илиместо в общаге или красный диплом или ещё что.

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

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

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

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

нет. просто несёшь чушь. причём какую-то школотронскую чушь про «неуды». это у тебя по Фрейду, наверное. видимо, в школе тебе ставили неуды и ты до сих пор стрессуешь.

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

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

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

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

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

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

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

и никакие «неуды» в Универах студентам просто от нечего делать никто не ставит

А в армии служат патриоты родины и нет предателей, а птицы на небе поют от радости, а не потому что жрать и размножаться хотят!

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

Это откуда такая наркомания, что под каждый ингредиент в отдельном реализованном блюде нужна отдельная проводка?

Типовой партионный учёт. Например, в 1С:Общепит при учёте от фактической продажи.

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

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

в Универе работают и учатся уже взрослые люди

«эта пять», как говорится. Пешы исчо. А у нас считалось, что в преподы те, пошли кого на интересную работу в гугл не взяли, а психологичка наша на парах вещает (было в каком-то семестре не знаю зачем), потому что занялась психологией на почве починки собственной крыши. И из совчем недавнего помню: чел один у рас работал, СУБД разрабатывал. Оставил после себя лютый говнокодище, которое вместо работы за O(logN) где надо делает сильно больше операций на ровном месте и просто кривоватое. Уволился. Выяснили куда ушел - вернулся в универ, к работе программистов душа говорит не лежит, преподавать тянет! И что он пошел преподавать? Правильно - алгоритмов курс, бугага. Да ещё в одном из топовых столичных универов. Так-то!

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

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

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

у тебя всё равно будут остатки, которые испортятся и ты их выбросишь. или пустишь остатки на другие блюда на следующий день. и что тогда?

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

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

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

у тебя всё равно будут остатки, которые испортятся и ты их выбросишь.

Документ Списание при выбрасывании.

или пустишь остатки на другие блюда на следующий день. и что тогда?

Если в конце дня остались полуфабрикаты на них делается документ Производство.

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

Ну вот. Надо же посчитать себестоимость закупки всех компонентов, что попали в этот салат, с учётом того, что из 50 граммов майонеза 30 была с предыдущей поставки, а 20 уже с новой по повышенной цене.

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

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

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

Понятно, что если компьютер не вытягивает, то всё сводят к котловому учёту вплоть до выкидывания аналитики по товару.

Зря проводки затронул.
Проще было задать вопрос - «Как ээфективно в данном случае в SQL получить аналитику?».

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

Ну вот. Надо же посчитать себестоимость закупки всех компонентов, что попали в этот салат, с учётом того, что из 50 граммов майонеза 30 была с предыдущей поставки, а 20 уже с новой по повышенной цене.

Пошучу

Теперь понятно почему салаты такие дорогие …
@monk виноват!

anonymous
()