коенчно скажу - в бизнесе как и в жизни выживает не стабильный (сильнейший), а тот кто лучше приспасабливается (гибкий), адаптируется к изменениям.Стабильность в бизнесе это не продавать всегда одно и то же, а стабильно выдавать результат с предсказуемой точностью, очевидно. Это к вопросу о Всё говорит о том, что нам может быть когда-то капец, а может и нет.. А все словесные выкрутасы вокруг манипулятивных техник и прочего - ну поупражняйтесь, я конкретно написал почему это не выгодно. Вам кажется что это нюансы и надуманные проблемы - ваше дело. Да, я выступаю с позиции "умный дядя говорит", но это обоснованная практикой позиция, я видел как выбранная архитектура влияет на будущее проекта, как тупо не хватает спецов чтобы сдать проект в рамках сроков, как хреново бд ложится в гит/меркуриал/свн, и еще много веселого... Вы можете спокойно проигнорировать все что я говорю и сделать по своему. И вы обязательно в той или иной мере наступите на вышеописанные грабли, которые тут, на берегу, вам кажутся пальмами с финиками, ну или по крайней мере незначительной растительностью на пути к фантастическим перспективам (нет).
Аргументация про карму, или вида "неделай так, потому что так умный дядя говорит"Аргументация была в другом, но вам не понравилось именно то что я рекомендовал не делать фигни. Ну ок, вы раскусили мои хитрые манипуляции, теперь можете продолжить заниматься фигней...
Стабильность - очень так себе аргумент.Ага, владельцу бизнеса это скажите ) Это же не политика, в разработке важно знать что ты получишь на выходе, собственно куча фреймворков это как раз попытка максимально стабилизировать разработку. Если у вас цель - творческий эксперимент, а не продукт, то подход интересный, в ином случае я бы придерживался более классического подхода.
Всем нравоучениям улыбаюсь но не более.А при чем тут нравоучения? Есть, скажем так, здравый смысл, опыт и боль рефакторинга кучи проектов, спроектированных как раз по такому принципу "инновационного подхода", ничего кроме как попробовать отговорить вас от решений, принесущих кучу проблем и мизер профита вам здесь не писали. Ничего из того что можно было бы назвать "нравоучением", вам здесь не написали. Хотите делать по своему - да пожалуйста. Были ли попытки сделать что-то похожее? Да, были. Было ли это профитным - в известных мне случаях однозначно нет. Спор о логике в бд и тут уже несколько раз затрагивался, пока никто ничего толкового на этой идее не построил. По этому советы большинства присутствующих - не беритесь. Чисто из соображений гуманизма.
То, что эта логика написана руками, всего лишь следствие того, что в этом инструменте просто нет нужных механизмов и их приходится писать руками.Не приходится, их пишут в приложении и формируют запросы в бд согласно требуемым данным для БЛ. По вашей же логике в бд не хватает фреймворка на все случаи жизни, а-ля рубирельсы или ларавель. Вопрос - а почему же его нет, если он так нужен? Ответ, думаю, очевиден...
Если пофантазировать и представить, что каскадного удаления или блокировок в БД бы не было, то можно легко дойти до того, что их придётся писать руками. Чем этот кейс отличается?Ничем, просто писали бы эту логику в приложении. Кстати, иногда так и делают, когда консистентность не критична, а приоритет отдается скорости записи/чтения, экономят на внешних ключах при частых вставках и редких удалениях.
Я исследую вопрос в контексте контраргументов, и пока не нашёл, чего то конкретного, чтоб можно было сказать - "смотри если так сделаем, то нам капец, по таким то причинам". Всё говорит о том, что нам может быть когда-то капец, а может и нет.Стабильность и предсказуемость - наше всё ))
Хороший вариант с зоопарком сервисов получения данных (микросервисы, шины, эластик, БД), но этого пока мало, хотя сейчас в проекте только эластика нет.Мало для чего, в чем затык?
С редисом не всё однозначно, есть подозрения, что 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 клика?Нет, и я даже не пробовал. Опыт в создании парсеров позволяет мне заявлять вещи, которые не требуют проверки на конкретном примере.
Мой код уже парсит.поздравляю, хотя не понимаю почему вы решили поделиться этой радостью со мной...
Так я уже спрашивал - в чем затык? Технически препятствий нет, архитектура нестандартная, но кого и когда это останавливало, если есть желание попробовать острых ощущений? ) Как я уже писал - единственный ваш обозначенный плюс - , где заменив "база данных" на "язык бэкенда" вы получите то же самое, только в современной мете...