LINUX.ORG.RU

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

 ,


0

4

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

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

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

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

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

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

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

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

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

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

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

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

Не поверите… Но, слава богу, мои не на Госзнаке печатают, да и нал здесь уже практически не в ходу лет N-дцать как.

LTE у местного провайдера

LTE как технология - не отечественная разработка. Подозреваю что речь о билинге.

много лет весь Сбербанк по всей стране работал на сетевом софте, который писала и дорабатывала я.

Так вот откуда столько гонора! Угу, всё потихоньку становится на свои места. Заявка сильная конечно, но не козырная. Не хотел, но спрошу: и давно вы свой первый миллион (не фантиков конечно) заработали? И, как там - «а почему ты такой бедный если такой умный»?

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

А вот это - пять! Вы настолько сильно уверены в своей недостижимой элитарности что это вызывает только сочувственную улыбку. Это пройдёт, может быть…

а если вы не можете освоить многопоточность

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

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

Какие ещё могут быть аргументы если вы отрицаете столь очевидную вещь что писать многопоток сложнЕЕ чем однопоток? Это настолько же очевидно как «управлять самолётом сложнее чем велосипедом».

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

Приятно, что ты еще отсюда не убежала.

Серьёзно? Мадам тут потихонькурезво травит ядами, да ищет как бы человечинки пожрать.

Адептов С не так много осталось, к сожалению

Может быть, но она-то тут при чём? Не знает она Cи, одни понты бесконечные.

anonymous
()

вообще говоря СУБД как сущность (библиотеки/сервисы/серверы/облака) она от убогости технологических средств и их «невыразительности».

В недостижимом предельном идеале, приклад должен работать со всеми возможными данными как со своими родными локальными. И в максимально ясном виде.

Идеал не достигнут, потому RDBMS, гиперкубы, map-reduce. Каждый из них неплох и офигенен, но неидеален.

Все живём к конкретном мире, потому про идеал можно потрепаться, но сермяжно писать «SELECT FROM...» и не это не напрягает

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

Все живём к конкретном мире, потому про идеал можно потрепаться, но сермяжно писать «SELECT FROM…» и не это не напрягает

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

anonymous
()

и про SQL-ы с табличными СУБД: они конечно продвинули идеи реляционной модели данных в практичный мир, но они-же их и закопали.

давным-давно, при зелёной траве, была довольно зверская и обоснованная критика SQL и реляционных СУБД, именно от идеологов RDB.

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

Она говорит про C, она ни разу ни в одном предметном разговоре не смогла выдать ничего конкретного на C. Так что ее компетенции пока что существуют только в ее голове.

anonymous
()

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

Проверки практикой нет до такой степени, что Leetcode контест по сравнению с их деятельностью - это максимально утилитарный и прикладной проект с тестированием, отладкой и сроками выполнения. А «сферически литкодер в вакууме» - готовый и натасканный к реальной работе специалист. Между типичным преподом и реальностью простирается бездна. Даже если эта реальность решение синтетических задач на время. Не говоря уже о проектировании приложений для конечного пользователя. Таких приложений которые готовы покупать заказчики.

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

У них нет сроков. У них нет реальных проектов. Они вообще (!) не в курсе современных реалий разработки. Для них до сих пор системы контроля версий - новинка. От этого умозрительного теоретизирования и бездны свободного времени начинается борьба с Python и SQL.

Ведь торопиться не надо, писать что-то тоже, надо с умным видом рисовать что-то на доске и талыдыдчить в это нечто указкой. И умозрительно заключать: «Надо быстро - значит надо чтоб компилировалось. Python не компилируется - значит медленно. Python не надо.» Критерии цены разработки, легкости тестирования и отладки в расчёт не берутся. Эти сущности вне их мира.

Работающие приложение никто и никогда не спросит. Спросят бумагу «научную» и точное посещение лекций.

P.S.

@liksys, @rtxtxtrx, в наших спорах я как-то был за «академическое» образование, пока не пообщался 3 минуты с преподавателем с многолетним стажем.

Это мрак. Полное отсутствие какой бы то ни было осведомленности о реальном положении дел. Типичное презрение к Python (а зачем он нужен?) и подростковых фольклор образца ранних 2000ых о «архитекторах» которые не пишут код.

Полное ощущение «машины времени». То, о чем говорил @liksys - пыльные «лабораторные» под Windows 2000 с точно таким же представлением о процессе создания программного обеспечения.

P.P.S.

После такого «образования» надо где-то брать резервы времени на годы самостоятельного до-обучения. Потому как практически и теоретических навыков они дать не могут, так как сами не знают. Максимум - писать простейшие классы на C++.

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

Грязный балаган за деньги родителей.

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

Какие ещё могут быть аргументы если вы отрицаете столь очевидную вещь что писать многопоток сложнЕЕ чем однопоток?

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

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

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

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

Такие преподаватели тоже есть.

Также я высоко ценю качественную теорию. Как книги Таненбаума и Сенди Метц - которые теорию превращают в практический инструмент.

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

Как ни странно, «современная школа» - это полный треш! Когда студенту проще под микроконтроллер в «калокубе» сгенерировать код под ртос, вместо того, чтобы написать код руками. Вменяемый. На конечных автоматах.

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

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

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

anonymous
()

Причина отказа от СУБД ровно одна: отсутствие заказчика который вносит коррективы в процесс разработки.

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

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

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

Большинство преподов существует в кривом зазеркалье безвременья

У них нет реальных проектов. Они вообще (!) не в курсе современных реалий разработки.

Больше пафоса, больше!

А можно поинтересоваться, кто ты собственно такой, чтоб твоё напыщенное (само)мнение было хоть кому-нибудь интересно?

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

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

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

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

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

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

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

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

Но, слава богу, мои не на Госзнаке печатают, да и нал здесь уже практически не в ходу лет N-дцать как.

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

LTE как технология - не отечественная разработка. Подозреваю что речь о билинге.

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

Так вот откуда столько гонора! Угу, всё потихоньку становится на свои места. Заявка сильная конечно, но не козырная. Не хотел, но спрошу: и давно вы свой первый миллион (не фантиков конечно) заработали? И, как там - «а почему ты такой бедный если такой умный»?

какого гонора? я тебя, дурака, пытаюсь вразумить. какой уж тут «гонор»... но, видимо, бесполезно. не в коня овёс.

я не собиралась «зарабатывать миллион», но на квартиру в еботеку мне моей зарплаты хватило. хотя к проекту работы Сбера это не имело никакого отношения, там как раз платили мало. тогда у Сбера не было своей разработки и её вели сторонние коммерческие компании, в одной из которых я и работала. но проект был важный, федеральный, софт стоял в каждом отделении Сбера, от крупных ЦОДов до маленьких посёлков, где есть представительство Сбера. и их было дофига. и если бы этот софт упал, то встала бы раком вся страна, буквально: все платежи, все переводы и прочее. и это была бы катастрофа. поэтому косячить было никак нельзя. там был огромный жирный софт, написанный на плюсах, который писали много лет, и его надо было поддерживать, развивать и рефакторить, по возможности. причём в одну каску. кроме меня в нём никто не шарил. причём мне пришлось это разгребать практически без документов, потому что предыдушие разработчики уволились и остался только код, который на мощном билд-сервере собирался минут 40. а Сберу периодически нужны были новые фичи, поддержка новых версий маздая (а там поддерживалась вся линейка маздаев, от NT4 до 2003 сервера, на тот момент довольно свежего), добавление новых протоколов и всяких приблуд. но Сбер тоже работал стабильно. и спасибо тем админам ЦОДов, которые мне помогали это всё отлаживать. без них это было бы невозможно, хотя формально они нарушали регламент и устанавливали неофициальные версии софта, для тестирования. но по-другому было просто никак. кстати, второй такой же федеральный проект был Таможня. аналогичный во многом софт, но для пунктов таможни. тоже я его поддерживала, но там было меньше изменений и плюшек. однако, если он вдруг вставал раком, то на таможне образовывались многокилометровые очереди из фур буквально за несколько часов. поэтому тоже нужно было бдить, чтобы всё работало идеально. но там был неприятный контингент в плане сотрудничества - специфика казарменной военщины. в Сбере люди были адекватнее.

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

Какие ещё могут быть аргументы если вы отрицаете столь очевидную вещь что писать многопоток сложнЕЕ чем однопоток? Это настолько же очевидно как «управлять самолётом сложнее чем велосипедом».

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

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

Iron_Bug ★★★★★
()
Последнее исправление: Iron_Bug (всего исправлений: 4)