То, что эта логика написана руками, всего лишь следствие того, что в этом инструменте просто нет нужных механизмов и их приходится писать руками.Не приходится, их пишут в приложении и формируют запросы в бд согласно требуемым данным для БЛ. По вашей же логике в бд не хватает фреймворка на все случаи жизни, а-ля рубирельсы или ларавель. Вопрос - а почему же его нет, если он так нужен? Ответ, думаю, очевиден...
Если пофантазировать и представить, что каскадного удаления или блокировок в БД бы не было, то можно легко дойти до того, что их придётся писать руками. Чем этот кейс отличается?Ничем, просто писали бы эту логику в приложении. Кстати, иногда так и делают, когда консистентность не критична, а приоритет отдается скорости записи/чтения, экономят на внешних ключах при частых вставках и редких удалениях.
Я исследую вопрос в контексте контраргументов, и пока не нашёл, чего то конкретного, чтоб можно было сказать - "смотри если так сделаем, то нам капец, по таким то причинам". Всё говорит о том, что нам может быть когда-то капец, а может и нет.Стабильность и предсказуемость - наше всё ))
Хороший вариант с зоопарком сервисов получения данных (микросервисы, шины, эластик, БД), но этого пока мало, хотя сейчас в проекте только эластика нет.Мало для чего, в чем затык?
С редисом не всё однозначно, есть подозрения, что pg сам себя кэширует лучше.Тут вопрос не в операционном кэше, а в управлении кэшированием на уровне приложения. Через редис/мемкэш можно настраивать конкретное время жизни для конкретных данных. На стороне бд это во первых сложнее, а во вторых - кэш системы позволяет не дергать систему хранения вовсе.
Короче самые лучшие коменты для меня это конкретные юскейсы: типа смотри мы вот сделали и огребли такие-то проблемы, потом переделали вот так и эти проблемы ушли, но появились новые такие-то.В 2005 мы писали что-то типа внебрачного сына ютуба и фейсбука. Наш ДБА во первых уговорил нас на SQL Server, а во вторых, в творческом порыве понастругал хранимок, в которых, надо сказать, очень неплохо разбирался (и разбирается). Так вот, скрестить линукс с SQL S на тот момент не удалось, а сервер от мс с нужным софтом стоил просто запредельных денег. Пока все было на бесплатной тестовой версии можно было терпеть некоторые косяки (по типу своей версии UTF кодировок, типа UCS, не совпадающей в 10 символах с UTF-8 например), вытекающие из такого зоопарка, но когда посчитали что за софт будет выходить сумма сопоставимая с покупкой еще 2 серверов, быстро переползли на мускуль, похерили все хранимки, так как ДБА уже было лень все переносить руками, и написали нормальную логику. В итоге ДБА ушел с проекта чуть позже, так что в любом случае хранимками заниматься было бы некому, нам просто повезло что это произошло само собой, а не внезапно по уходу спеца. Вот такой кейс был...
Между тем, адепты не писать логику в БД почему-то тихо "игнорируют" такие вещи, как внешние ключи и такие вещи как ON DELETE CASCADE с удовольствием используют, а не пишут цикл перебора с методом delete для каждой из связанных сущностей.Не надо путать встроенные механизмы инструмента, призванные сохранять консистентность данных, с логикой манипуляций данными в хранилище, писаной руками. В остальном согласен что пример со сменой системы хранения - хреновый пример абстракции. Он должен быть абстрактным, исходя из общей парадигмы ООП, но это не потому что что-то будет меняться и это пипец как часто нужно и тп, а по тому что все должно быть написано в одном ключе, так тупо проще разбирать код.
главная причина - это дурацкая привычка задавать вопросы (и у меня и у заказчика).Вопросы всегда надо задавать парами. Например - можно ли так делать?, и в пару - а почему так не делают примерно никто? Ну или "а что мы выигрываем при таком подходе?".
соврменная это же не значит автоматически, правильная или лучшая.Согласен. Готовы стать пионером в изобретении новой меты? Много крови, пота, гемора и потраченных денег, зато в итоге - лавры победителя (или нет). Вопрос не в невозможности, это тупо не выгодно на сегодняшнем этапе развития технологий.
Как профессионально и с доказательствами:)я чуть подробнее расписал почему, рано нажал отправить, пришлось исправлять.
А если язык содержит абстракций, то бОльшая часть вашего кода будет наследованием через наследование наследованием погонять, где плотность кода стремится к нулю, а подавляющее большинство абстракций будет создано в ожидании своего часа, но так никогда и не выстрелят, оставшись болтаться без дела.Фишка в том что все эти "тонны" абстракций уже есть, написаны и работают, вам надо только создать экземпляр конкретного класса, настроить связи и ВСЕ! Ничего из так пугающего вас "лишнего" кода никогда даже не загрузится. Для разработчика весь код будет "плотным", так как так нелюбимые вами абстракции над абстракциями уже дают вам на 90% готовый код, вы пишете именно ЛОГИКУ, которой на самом деле не так много.
и требованием заказчика в реализации бл в sql и выбора субд.Если речь идет про осознанный выбор кактуса вместо пшена, то о чем вообще речь? Чисто физически БЛ пишется хоть в экселе. То есть физических преград нет, есть вопросы удобства и скорости разработки, поддержки и прочих нужных вещей, если на них забить изходя из принципа "хочу так", то задача выполнимая, хотя и в разы более сложная, нежели создание всего того же, но средствами ЯП.
Всё ваши минусы сводятся конкретно, к сложности поддержки, в связи с отсутствием/дороговизной специалистов?Это одна из многих проблем. Не по тому что "все привыкли по другому", а по тому что сейчас делают иначе практически все, и если бы с текущей архитектурой наблюдались бы серьезные проблемы, уже выкатили бы стопитьсот фреймворков для разработки БЛ в БД. А их нет, вообще. Значит и всего что сегодня делает разработку удобной, быстрой и недорой (инструменты, специалисты нужной квалификации, тестирование, версионирование, разбиение на объекты и еще миллион мелочей) у вас не будет. Если ваш заказчик хочет - дерзайте, но сразу примите как факт - гемора будет много.
Спасибо за коммент, согласен, что это важно, но конкретно в данном вопросе, конкретно сейчас меня больше интересует архитектурные аспектыАрхитектура будет стремной и непривычной, однозначно. Языки бд обычно не содержат абстракций, и бОльшая часть вашего кода будет махровой процедурщиной. Еще раз: если для себя - ок и норм, если для клиента - не срите себе в карму, икать, при упоминании вас добрым тихим словом, будете часто.
Плюсы: очень просто вносить изменения - затрагивается только один слой - база данных, и минимальные или вообще никаких изменений на фронте.Заменяем слова "база данных" на "бэкенд ЯП" и (о чудо!) ничего не меняется!
мне надо взять первое id (оно свое)Если у всех строк id равен 1, то кто из них первое?
На самом деле я хотел узнать, какие инструменты (программное обеспечение, утилита, плагин, пакет программ и средства...) нужны программисту,Определитесь со стеком, далее гуглите "IDE для язык_программирования". Все ИДЕ заточены под 1-2 языка, исключая некоторые комбайны типа Визуал студио. В каждом стеке инструменты будут разные.
что они из себя представляют, какую функцию они выполняют и т.д.Заходите на любой ролик в ютбе, пишете "основы языка такого-то", скорее всего в ролике вам покажут и саму ИДЕ и как примерно она выглядит и работает.
А ведь инженерное дело на то и инженерное что нет одного единственного правильного решения.Во первых, инженер должен обладать знаниями об инженерии, и правильные решения могут лежать в некотором диапазоне здравого смысла. Я не пошлю лесом человека, если он правильно решил задачу, но использовал не те методы которые использовал бы я. Но если он, условно, "инженерит" дом где санузел совмещен с кухней из соображений экономии кирпичей, то нам не по пути.
Могу только пожелать удачи в дальнейших поисках единоверцев.А, теперь многое становится понятным... Только вы это, крестик снимите, или оденьтесь, а то у вас то буржуи стадами эксплуатируют несчастных инженеров, выкидывая пачками на помойку, то гениальные инженеры работу найти не могут, чтобы их заэксплуатировали и выкинули. Как я уже написал выше - идите во фриланс, вот там заказчик наверняка оценит ваш креатив и полет мысли.
Спасибо, тогда комментарии можно было и не оставлять про то как тут всё просто и в 2 клика.Пожалуйста, но вы же не пробовали, правда?
просто надо заголовки нужные послать, что делается в 2 клика, открыл нетворк, кликнул запрос, посмотрел заголовки.Написал в комменты так как такие действия достаточно просты и рутинны для ответа, но задачу свою решают.
Ну как получилось в 2 клика?Нет, и я даже не пробовал. Опыт в создании парсеров позволяет мне заявлять вещи, которые не требуют проверки на конкретном примере.
Мой код уже парсит.поздравляю, хотя не понимаю почему вы решили поделиться этой радостью со мной...
Вы просто не умеете их искать... Спецов много, но все они пролетают мимо.ого, сильно... А как предлагаете искать? Облавы на логово сеньоров? Нанимать частных детективов на поиски мидов?
Кругом один только колхоз "разместим вакансию, устроим на собесе допрос и лайвкодинг".Я никогда не устраиваю лайвкодинг, и никогда не спрашиваю о вещах которые относятся к общей фигне а-ля "что такое соилд и как вы его использовали в паттернах?". Чаще всего спрашиваю общие вещи, по типу - вот есть такая сущность и такая задача, что примерно будешь делать, какие поля нужны, что по связям создашь, как это с фронтом взаимодействует, какой контроллер это будет... Смотрю на 2 вещи - делал ли раньше подобное и что получил, и как примерно мыслит в плане понимания откуда ноги растут. 90% несут просто лютую ахинею, и чаще всего напирают на "производительность" и "оптимизацию", например пихая все подряд в 1 таблицу. Хотя про солид наверняка расскажут мне в лицах и со слайдами... Вот такие "упущенные спецы" как-то не находят работу и почему-то ходят ноют что нет вакансий и рынок переполнен...
Выбор ВУЗа и профессии ограничит вас в выборе другой профессии и сфере деятельности в будущем. Проработав годы в %profession% вы просто ничего другого не будете уметь делать и придётся в прямом смысле слова %work% до 60.
Планку можно поднимать бесконечно. И до уровня чтобы обязательно никого не хватало. Это все стремящиеся в айти должны в первую очередь понимать и стоит ли вообще нынче овчинка выделки.По факту берут все равно сильно не дотягивающих до требований, по тому как вкатывающихся овердо**я, а что-то реально делающих - ни**я. И таков закон рынка - каждый хочет из сделки извлечь максимум, работадатель меньше заплатить и больше нагрузить, работник меньше работать и больше получать. Где-то посередине лежит зарплата.
Не лучше ли тогда фрезеровщиком пойти? Те же деньги, зато вкатиться можно с полоборота.Лучше. Особенно если душа лежит больше к работе лопатой и ломом, нежели головой.
Есть ещё такой ньюанс что всю прибавочную стоимость забирает себе дядя.Ну, а кто должен? Партия? Или на заводе за деталь тебе платит заказчик? Идите во фриланс, там социализм - средства производства в руках пролетариата.