SQL Express абсолютно бесплатный и даёт достаточно щедрые лимиты из коробки. Основное преимущество его в том, что, если вы вошли в зоопарк решений от Microsoft примерно вначале нулевых, когда это было ещё популярно, то вам уже, скорее всего уже не выбраться.
В то время MsSQL был действительно чем-то прорывным и очень удобным. Настолько, что на нём даже писали полноценный Тьюринг-код.
Томик "SQL Server 2000" на 500+ страниц был долго моей настольной школьной книгой. Такого трепета и уважения к базам данных я не испытывал ни до, ни после.
Жаль, что книга оказалась намного лучше самого продукта... Но это уже другая история :)
Согласен с тем, что в Python (желательно было упомянуть это в заголовке статьи) работа с датами из коробки выполнена не очень элегантно. Лучше, чем во многих других языках, но всё ещё недостаточно.
Однако, в плюсах описано удобства для веб приложений и API, которые не очень понятны. Веб приложениям как раз выгоднее получать и отдавать время в UTC+0 для того, чтобы клиентский модуль мог провести локальные вычисления под зону пользователя.
С русификацией разницы времени приятно видеть. Однако, почему в примере ниже вывод "красивой даты" уже не русифицирован?
В целом, полезное исследование. Желаю автору более предметно проработать применимость и, кто знает, может и найдёт своего ценителя. Из весьма логичного продолжения, предложил бы подать commit на рассмотрение в ядро Python. Маленьким радостям там тоже бывают рады.
У меня возврат на "домашний экран" чаще возвращает на боковой экран, с которого я запускал последнее приложение, так что приходится экран смахивать раза 2, а иногда 3, если я запускал из полного списка приложений
Большой блямбой можно, конечно, сделать, но это уже не самый очевидный трюк. Понадобится особый лаунчер.
На кнопочном не надо "выцеливать" кнопки - они вот, под рукой :) Цифра = буква. Например, найти "мама" = 52... Найти "андрей" = 253...
Забыл добавить, что во время поиска контакта любит вылетать какое-нибудь "супер-пупер" важное уведомление, которое эту строку поиска скрывает напрочь. Приходится отмахиваться, как от мухи. А потом судорожно вспоминать: "а что же там такое было"?
на тех телефонах, которые для звонков
Фраза сделала мой день :)))
Я не фанат кнопочных телефонов. Скорее, хочу передать ощущения эргономики, которые были действительно удобны, и которые давно забыты. А кнопки... может и действительно поспешили убирать все сразу.
Посыпаю голову пеплом. Не поленился, нашёл у себя несколько старых фото на этот телефон. Даже скрипт написал по поиску по EXIF. Что сказать... Действительно, сочные, живые... однако, размытость и зернистость совсем уже не вызывает тех самых эмоций. Интересно, получается, устроен мозг - он больше помнит эмоции, чем реальные факты :) Когда мы пересматривали эти фото в 2008-2010, эмоций было гораздо больше... Даже, больше, чем вызывают современные аппараты. Спасибо, собственно, что вернули на землю. Но в остальном, телефон был действительно удобный. Я так не радовался ни до, ни после.
По поводу современных моделей: вопрос даже не в оборудовании, и ни в умной обработке - есть какой-то тонкий ускользающий смысл... Что мы действильно сохраняем и для чего?
Самое ценное в разделе "А как надо?". Остальное как-то сильно размыто красноязычным разумом 🙂
От себя добавлю, что бизнесу, использующему ИИ также важно донести риски отказов этого самого ИИ. То есть, работа не должна быть парализована, если какой-то облачный сервис отвалится. А люди должны быть обучены, как жить по старинке)
Больше претензии не к опен сорсу. Тут всё понятно, ребята стараются, как могут. Больше претензия к коммерческому. Тот же Андроид - сколько ему лет - жутко неудобный. Адресная книга и звонилка - будто сделано школьником за один вечер. Пока кого-то наберёшь - весь экран облапаешь. И так во всём. Ощущение, что это не телефон, а какая-то экспериментальная консоль с прилепленым изолентой телефоном. До сих пор скучаю по кнопочному sony ericsson k810i... Любой контакт находился и вызывался на 3 физических нажатия кнопки. Перезвонить - два нажатия. Камера запускалась и фоткала одной кнопкой. А качество снимков на 3M пикселя с ксеноном, которые она делала, я уже почти 20 лет жду на флагманах... Всё как-то усложняется, добавляются свистелки и перделки, картиночки, декорации, безопасность, персонализированность, ИИ, прости б-же... А удобство целевого использования - зачем? Я на нём читал книги и новости, слушал музыку. Был даже Opera Mini и онлайн мессенджер. Вместо громозких банковских приложений - компании наоборот делали облегчённые версии сайтов, которые грузились секунды даже через GRPS. Ничего лишнего - всё строго по делу. В общем, я могу продолжать долго ))
Все эти разговоры про неравенство и несправедливость, как правило, упираются в нежелание больше платить. Логично же предположить, что если корпорации продают вам дешёвый аппарат, то, скорее всего, товаром являетесь вы.
На самом деле, я и сам техногик. Люблю прошивать и дорабатывать. Но у меня больше претензии не к слежке, а к качеству софта. Я бы даже сказал к сложившейся культуре: делать быстрые негодные продукты без уважения к пользователю, и откровенно врать. Но это совсем другая история...
Очень жизненно, прямо каждую боль на себе прочувствовал, пока читал.
Крайне недооценённая тема, полезная даже для тех, кто только начинает свой стартап. Грамотное проектирование роста с самого начала помогает избежать потребности в дорогих решениях и дюжинах инженеров в будущем.
От себя бы ещё добавил несколько. Боли много не бывает.
Определиться, какие таблицы нуждаются в шардировании. Действительно ли у нас выросла таблица пользователей, или всё-таки их данные (заказы, транзакции, статьи, сообщения)? Возможно, пользователей можно отделить, а данные уже шардировать.
Посмотреть, можем ли мы провести партиционирование исторических данных. Это умеют СУБД, и это не сложно.
Можем ли мы часть данных убрать в холодный архив и вырезать из горячей базы? Радикально? Зато надёжно.
Можем ли мы ввести лимиты по доступу к данным на уровне тарификации клиентов? Ограничить количество обращений одним, и снять ограничения другим. Баланс нагрузки под контролем.
На какие дополнительные риски мы попадаем, если у нас персональные данные, прости г-ди, разлетаются по шардам?
А оно вам точно надо? Этот вопрос повторяю за автором. Можно даже сказать горизонтально шардирую ) Если вы не владелец проекта, то убедитесь сначала, что ваши старания и ответственность будут хорошо приняты и вознаграждены. И что боли действительно доходят до начальства. Иначе, бегите...
Спасибо ещё раз за статью. Автору и всем желаю хорошего терпения, выдержки и поменьше болей в этой нелегкой жизни 😊
практичный язык с кучей библиотек и проблем, которые проявляются на больших проектах
это можно сказать про любые языки и библиотеки без исключения, разве нет? особенно, если учитывать, что 90% того, что вы используете, написано энтузиастами в свободное время
На всякий случай, добавлю от себя для размышлений, если когда-нибудь вернётесь в этой проблеме на Python. Сам многократно сталкивался с ограничениями существующих фреймворков, поэтому, для себя отважился написать свой.
Ваш запрос решается примерно так:
class User(DBTable):
name: str
class Order(DBTable):
user: User
status: str
...
q1 = (
User.query('users_with_completed_orders'). # name is just for SQL decoration
select('pk').
filter(lambda x: x.orders.status == 'completed')
)
q2 = User.query()
sub = q2.with_query(q1)
(
q2.select_objects(). # trick to select '*'
select(new_orders_count=lambda x: x.orders.pk.count).
filter(lambda x: (x << sub) & (x.orders.status == 'new')).
sort_by('name')
)
for x in q2:
print(x)
это генерирует немного другой запрос, но с аналогичной логикой
WITH
users_with_completed_orders AS (
SELECT
"user".id AS "id"
FROM "public"."user" AS "user"
LEFT JOIN "public"."order" AS "user__orders"
ON "user".id = "user__orders".user
WHERE
"user__orders".status='completed'
)
SELECT
"user".name AS "name",
"user".id AS "id",
count("user__orders".id) AS "new_orders_count"
FROM "public"."user" AS "user"
LEFT JOIN "public"."order" AS "user__orders"
ON "user".id = "user__orders".user
WHERE
"user".id IN (SELECT * FROM users_with_completed_orders) AND "user__orders".status='new'
GROUP BY
1,
2
ORDER BY
"user".name
то есть, сначала материализуется выбор всех клиентов с законченными заявками, а потом, по нему выбирается список с новыми. Результат примерно такой:
Либо, можно сделать немного менее производительный запрос, зато более короткий:
q3 = (
User.query().
select_objects().
select(new_orders_count=lambda x: x.orders('new').pk.count_distinct).
filter(lambda x: x.orders('new').status == 'new').
filter(lambda x: x.orders('completed').status == 'completed')
)
for x in q3:
print(x)
Здесь соединение с таблицей заявок дважды, но фильтр отбрасывает те записи, по которым не было законченных заявок. То есть, результат тот же.
SELECT
"user".name AS "name",
"user".id AS "id",
count(DISTINCT "user__orders_new".id) AS "new_orders_count"
FROM "public"."user" AS "user"
LEFT JOIN "public"."order" AS "user__orders_new"
ON "user".id = "user__orders_new".user
LEFT JOIN "public"."order" AS "user__orders_completed"
ON "user".id = "user__orders_completed".user
WHERE
"user__orders_new".status='new'
AND "user__orders_completed".status='completed'
GROUP BY
1,
2
Можно оформить ещё через `SUM(CASE ...)`, но получится более громоздко...
По сути, ваша задача появилась из достаточно нестандартных требований. То есть, вы в одном запросе должны и получать статус клиента, и делать по нему аналитику. В идеале, конечно, статус клиента лучше рассчитывать где-то ещё и сохранять. Тогда любая ORM легко справится.
Тем не менее, если фреймворк вам понравится, буду рад челленджам на любые нестандартные запросы ;)
Хорошее, полезное напоминание. Приятно было прочитать, если не брать во внимание достаточно вырожденные примеры.
Я бы ещё добавил:
Не забывать type hints там, где нет очевидной логики на уровне линтеров.
Не забывать про NamedTuples, dataclass для группировки предметных данных.
Обратить внимание на логику разделения модулей. Там есть нетривиальные ходы.
Про list comprehension ничего не сказано, а стоило бы.
На самом деле, все трюки и не перечислить в одной статье. Python даёт очень много мощных инструментов, преимущество которых не всегда лежит на поверхности.
Во первых, у Python есть свои Дзен постулаты (import this). С виду шутка, но по сути, установки очень сильные, которые повлияли на развитие языка на всём протяжении времени.
Во вторых, язык пропитан принципом DRY. Это придаёт некоторую однозначность в решении тех или иных задач, набор отличных хорошо известных и поддерживаемых модулей.
Как бы не было много критики про принудительные отступы, как часть синтаксиса, но, это действительно приучает форматировать свой код.
Всё это создаёт некоторый вайб надёжности, практичности и уважения. Я бы далее сказал, заботы.
Конечно, простота языка относительна. Она заканчивается примерно там, где приходится углубляться в мета классы, перегрузку операторов, декораторы, множественное наследование и функциональное программирование. Можно очень изящно написать абстрактный эффективный код, который вы сами уже через два дня не поймёте 😊 Отдельное недоразумение - перекраска функций в async.
Вопрос не в том, насколько страшен GUI, а в том, насколько они нужен. Во времена быстрого интернета и облачных вычислений десктопные приложения вымирают, как класс. С другой стороны, ваше предложение сделать Markdown редактор - это хорошо. Но он же уже есть во всех IDE. А, если честно, сколько GUI приложений вы именно устанавливали на свой ПК за последние 5 лет? Ну, кроме браузера и IDE?
Последний раз делал на заказ оконные приложения лет 6 назад. NET Forms - неплохо, конечно, но C# - это на любителя. Для Python зашло PyQT. Великолепный редактор форм, простой бутстрап на Python и поддержка PyInstaller из коробки. Да, бинарник жирный на выходе, и лицензия не простая. Но для тех редких случаев вполне хватало.
К тому же, проблема в том, что Python очень плохо портируется. Где-то за версию ОС цепляется, где-то библиотеки не те, где-то антивирус не пропускает. Поверьте мне, вам это не нужно.
Такое чувство, что я попал на олимпиаду "кто быстрее и дальше запустит в автора какаху". Немного грустно за русское комьюнити...
По сути, автор задал весьма полезный и безобидный вопрос "а что если?". Именно с такого вопроса и начинаются большие открытия.
Понятно, если мягко подытожить весь флейм, то ребята не рекомендуют отключать валидацию ценных связей. Есть несофтовые операции и форсмажоры, а также операции обслуживания БД, которым это крайне нужно.
Однако, вполне можно допустить целесообразность мягких связей в БД. Например, ключевые поля внутри JSONB структуры. Хотите, например некие properties или мета атрибуты таблицы, которые вы не хотите явно вносить в схему из-за динамической природы? Делайте JSONB поле и управляйте софтовым способом в своё удовольствие. Ни один ранимый эксперт не пострадает :)
Позволяет элегантно сериализовать хоть чёрта на куличках и без танцев с бубном.
Проект далеко не новый, и проверен временем. Портирован на Python и Js.
Protobuf тоже хорош, но плохо подходит для нетипизированных языков с динамическими структурами. Придётся постоянно согласовывать и пересобирать сериализатор, и потом ловить ошибки в реал-тайме, когда что-то забыл.
Вот пример скрипта, который мне понадобился однажды. Микросервис с логированием, мониторингом, защитой от ДОСа, упаковкой в докер и даже дашбордом. Суммарно более 300 полезных строк за час общения. Это пример из разряда "я всё и так знаю, зачем самому писать?" :) https://chatgpt.com/share/68ef4c12-aa98-8003-9c3b-d447d1ebbf5c
На тему известных декларативных языков ещё добавлю XPath и RegExp, хоть к классу самостоятельных ЯП и не относятся.
Эх, Пролог - удивительный язык... Совсем не сложный. По сути вся программа состоит из предикатов, то есть, определения фактов и их связей между собой. Сложно - это мозг перестроить с поиска итерационных алгоритмов на поиск эффективных эвристик.
А тестирование и отладка программы на прологе - как отдельный вид искусства...
SQL Express абсолютно бесплатный и даёт достаточно щедрые лимиты из коробки. Основное преимущество его в том, что, если вы вошли в зоопарк решений от Microsoft примерно вначале нулевых, когда это было ещё популярно, то вам уже, скорее всего уже не выбраться.
В то время MsSQL был действительно чем-то прорывным и очень удобным. Настолько, что на нём даже писали полноценный Тьюринг-код.
Томик "SQL Server 2000" на 500+ страниц был долго моей настольной школьной книгой. Такого трепета и уважения к базам данных я не испытывал ни до, ни после.
Жаль, что книга оказалась намного лучше самого продукта... Но это уже другая история :)
Согласен с тем, что в Python (желательно было упомянуть это в заголовке статьи) работа с датами из коробки выполнена не очень элегантно. Лучше, чем во многих других языках, но всё ещё недостаточно.
Однако, в плюсах описано удобства для веб приложений и API, которые не очень понятны. Веб приложениям как раз выгоднее получать и отдавать время в UTC+0 для того, чтобы клиентский модуль мог провести локальные вычисления под зону пользователя.
С русификацией разницы времени приятно видеть. Однако, почему в примере ниже вывод "красивой даты" уже не русифицирован?
В целом, полезное исследование. Желаю автору более предметно проработать применимость и, кто знает, может и найдёт своего ценителя. Из весьма логичного продолжения, предложил бы подать commit на рассмотрение в ядро Python. Маленьким радостям там тоже бывают рады.
У меня возврат на "домашний экран" чаще возвращает на боковой экран, с которого я запускал последнее приложение, так что приходится экран смахивать раза 2, а иногда 3, если я запускал из полного списка приложений
Большой блямбой можно, конечно, сделать, но это уже не самый очевидный трюк. Понадобится особый лаунчер.
На кнопочном не надо "выцеливать" кнопки - они вот, под рукой :) Цифра = буква. Например, найти "мама" = 52... Найти "андрей" = 253...
Забыл добавить, что во время поиска контакта любит вылетать какое-нибудь "супер-пупер" важное уведомление, которое эту строку поиска скрывает напрочь. Приходится отмахиваться, как от мухи. А потом судорожно вспоминать: "а что же там такое было"?
Фраза сделала мой день :)))
Я не фанат кнопочных телефонов. Скорее, хочу передать ощущения эргономики, которые были действительно удобны, и которые давно забыты. А кнопки... может и действительно поспешили убирать все сразу.
Ну, у меня как-то сложнее получается:
Разблокировать телефон.
Выйти из приложения, которое запущено.
Перейти на главный экран с бокового экрана, который был открыт ранее.
Аккуратно найти и нажать на экране звонилку.
Аккуратно выбрать контакт из последних или натыкать первые буквы.
Откроется контакт со списком номеров - выбрать определённый и нажать.
Выбрать сим карту для вызова или мессенджер (про мессенджеры можно и другим маршрутом).
Звоню :)
Как было на кнопочном:
Джойстик влево.
Джойстик вниз. Возможно, повторить.
Возможно, нажать пару цифр для поиска по T9.
Вызвать.
Понимаете разницу? Я мог набрать вызов хоть на ходу, хоть в кармане, хоть с закрытыми глазами. И всё за 1-2 секунды. Вот об этом я и скучаю )
Посыпаю голову пеплом. Не поленился, нашёл у себя несколько старых фото на этот телефон. Даже скрипт написал по поиску по EXIF. Что сказать... Действительно, сочные, живые... однако, размытость и зернистость совсем уже не вызывает тех самых эмоций. Интересно, получается, устроен мозг - он больше помнит эмоции, чем реальные факты :) Когда мы пересматривали эти фото в 2008-2010, эмоций было гораздо больше... Даже, больше, чем вызывают современные аппараты. Спасибо, собственно, что вернули на землю.
Но в остальном, телефон был действительно удобный. Я так не радовался ни до, ни после.
По поводу современных моделей: вопрос даже не в оборудовании, и ни в умной обработке - есть какой-то тонкий ускользающий смысл... Что мы действильно сохраняем и для чего?
Самое ценное в разделе "А как надо?". Остальное как-то сильно размыто красноязычным разумом 🙂
От себя добавлю, что бизнесу, использующему ИИ также важно донести риски отказов этого самого ИИ. То есть, работа не должна быть парализована, если какой-то облачный сервис отвалится. А люди должны быть обучены, как жить по старинке)
Больше претензии не к опен сорсу. Тут всё понятно, ребята стараются, как могут. Больше претензия к коммерческому.
Тот же Андроид - сколько ему лет - жутко неудобный. Адресная книга и звонилка - будто сделано школьником за один вечер. Пока кого-то наберёшь - весь экран облапаешь. И так во всём. Ощущение, что это не телефон, а какая-то экспериментальная консоль с прилепленым изолентой телефоном.
До сих пор скучаю по кнопочному sony ericsson k810i... Любой контакт находился и вызывался на 3 физических нажатия кнопки. Перезвонить - два нажатия. Камера запускалась и фоткала одной кнопкой. А качество снимков на 3M пикселя с ксеноном, которые она делала, я уже почти 20 лет жду на флагманах...
Всё как-то усложняется, добавляются свистелки и перделки, картиночки, декорации, безопасность, персонализированность, ИИ, прости б-же... А удобство целевого использования - зачем? Я на нём читал книги и новости, слушал музыку. Был даже Opera Mini и онлайн мессенджер. Вместо громозких банковских приложений - компании наоборот делали облегчённые версии сайтов, которые грузились секунды даже через GRPS. Ничего лишнего - всё строго по делу.
В общем, я могу продолжать долго ))
Есть же вполне освоенный рынок защищённых кнопочных (и не только) телефонов для богатых.
Даже хорошая статья на Хабре 10 лет назад была.
Все эти разговоры про неравенство и несправедливость, как правило, упираются в нежелание больше платить. Логично же предположить, что если корпорации продают вам дешёвый аппарат, то, скорее всего, товаром являетесь вы.
На самом деле, я и сам техногик. Люблю прошивать и дорабатывать. Но у меня больше претензии не к слежке, а к качеству софта. Я бы даже сказал к сложившейся культуре: делать быстрые негодные продукты без уважения к пользователю, и откровенно врать. Но это совсем другая история...
Очень жизненно, прямо каждую боль на себе прочувствовал, пока читал.
Крайне недооценённая тема, полезная даже для тех, кто только начинает свой стартап. Грамотное проектирование роста с самого начала помогает избежать потребности в дорогих решениях и дюжинах инженеров в будущем.
От себя бы ещё добавил несколько. Боли много не бывает.
Определиться, какие таблицы нуждаются в шардировании. Действительно ли у нас выросла таблица пользователей, или всё-таки их данные (заказы, транзакции, статьи, сообщения)? Возможно, пользователей можно отделить, а данные уже шардировать.
Посмотреть, можем ли мы провести партиционирование исторических данных. Это умеют СУБД, и это не сложно.
Можем ли мы часть данных убрать в холодный архив и вырезать из горячей базы? Радикально? Зато надёжно.
Можем ли мы ввести лимиты по доступу к данным на уровне тарификации клиентов? Ограничить количество обращений одним, и снять ограничения другим. Баланс нагрузки под контролем.
На какие дополнительные риски мы попадаем, если у нас персональные данные, прости г-ди, разлетаются по шардам?
А оно вам точно надо? Этот вопрос повторяю за автором. Можно даже сказать горизонтально шардирую ) Если вы не владелец проекта, то убедитесь сначала, что ваши старания и ответственность будут хорошо приняты и вознаграждены. И что боли действительно доходят до начальства. Иначе, бегите...
Спасибо ещё раз за статью. Автору и всем желаю хорошего терпения, выдержки и поменьше болей в этой нелегкой жизни 😊
Тогда почему по-вашему, Python столь популярен?
это можно сказать про любые языки и библиотеки без исключения, разве нет?
особенно, если учитывать, что 90% того, что вы используете, написано энтузиастами в свободное время
На всякий случай, добавлю от себя для размышлений, если когда-нибудь вернётесь в этой проблеме на Python. Сам многократно сталкивался с ограничениями существующих фреймворков, поэтому, для себя отважился написать свой.
Ваш запрос решается примерно так:
это генерирует немного другой запрос, но с аналогичной логикой
то есть, сначала материализуется выбор всех клиентов с законченными заявками, а потом, по нему выбирается список с новыми. Результат примерно такой:
Либо, можно сделать немного менее производительный запрос, зато более короткий:
Здесь соединение с таблицей заявок дважды, но фильтр отбрасывает те записи, по которым не было законченных заявок. То есть, результат тот же.
Можно оформить ещё через `SUM(CASE ...)`, но получится более громоздко...
По сути, ваша задача появилась из достаточно нестандартных требований. То есть, вы в одном запросе должны и получать статус клиента, и делать по нему аналитику. В идеале, конечно, статус клиента лучше рассчитывать где-то ещё и сохранять. Тогда любая ORM легко справится.
Тем не менее, если фреймворк вам понравится, буду рад челленджам на любые нестандартные запросы ;)
Хорошее, полезное напоминание. Приятно было прочитать, если не брать во внимание достаточно вырожденные примеры.
Я бы ещё добавил:
Не забывать type hints там, где нет очевидной логики на уровне линтеров.
Не забывать про NamedTuples, dataclass для группировки предметных данных.
Обратить внимание на логику разделения модулей. Там есть нетривиальные ходы.
Про list comprehension ничего не сказано, а стоило бы.
На самом деле, все трюки и не перечислить в одной статье. Python даёт очень много мощных инструментов, преимущество которых не всегда лежит на поверхности.
На копейках расти дадут, на объемах будут скидывать. Слишком очевидная и сладкая ликвидность.
return x in l and l.index(x)Возвращает индекс или False.
Это самый короткий способ. Можно чуть длиннее через тернарный оператор.
Python популярен, потому что мудро спроектирован.
Во первых, у Python есть свои Дзен постулаты (import this). С виду шутка, но по сути, установки очень сильные, которые повлияли на развитие языка на всём протяжении времени.
Во вторых, язык пропитан принципом DRY. Это придаёт некоторую однозначность в решении тех или иных задач, набор отличных хорошо известных и поддерживаемых модулей.
Как бы не было много критики про принудительные отступы, как часть синтаксиса, но, это действительно приучает форматировать свой код.
Всё это создаёт некоторый вайб надёжности, практичности и уважения. Я бы далее сказал, заботы.
Конечно, простота языка относительна. Она заканчивается примерно там, где приходится углубляться в мета классы, перегрузку операторов, декораторы, множественное наследование и функциональное программирование. Можно очень изящно написать абстрактный эффективный код, который вы сами уже через два дня не поймёте 😊 Отдельное недоразумение - перекраска функций в async.
Вопрос не в том, насколько страшен GUI, а в том, насколько они нужен. Во времена быстрого интернета и облачных вычислений десктопные приложения вымирают, как класс. С другой стороны, ваше предложение сделать Markdown редактор - это хорошо. Но он же уже есть во всех IDE. А, если честно, сколько GUI приложений вы именно устанавливали на свой ПК за последние 5 лет? Ну, кроме браузера и IDE?
Последний раз делал на заказ оконные приложения лет 6 назад. NET Forms - неплохо, конечно, но C# - это на любителя. Для Python зашло PyQT. Великолепный редактор форм, простой бутстрап на Python и поддержка PyInstaller из коробки. Да, бинарник жирный на выходе, и лицензия не простая. Но для тех редких случаев вполне хватало.
К тому же, проблема в том, что Python очень плохо портируется. Где-то за версию ОС цепляется, где-то библиотеки не те, где-то антивирус не пропускает. Поверьте мне, вам это не нужно.
Такое чувство, что я попал на олимпиаду "кто быстрее и дальше запустит в автора какаху". Немного грустно за русское комьюнити...
По сути, автор задал весьма полезный и безобидный вопрос "а что если?". Именно с такого вопроса и начинаются большие открытия.
Понятно, если мягко подытожить весь флейм, то ребята не рекомендуют отключать валидацию ценных связей. Есть несофтовые операции и форсмажоры, а также операции обслуживания БД, которым это крайне нужно.
Однако, вполне можно допустить целесообразность мягких связей в БД. Например, ключевые поля внутри JSONB структуры. Хотите, например некие properties или мета атрибуты таблицы, которые вы не хотите явно вносить в схему из-за динамической природы? Делайте JSONB поле и управляйте софтовым способом в своё удовольствие. Ни один ранимый эксперт не пострадает :)
Для себя подобную проблему решал с помощью bsdf.
https://bsdf.readthedocs.io/
Позволяет элегантно сериализовать хоть чёрта на куличках и без танцев с бубном.
Проект далеко не новый, и проверен временем. Портирован на Python и Js.
Protobuf тоже хорош, но плохо подходит для нетипизированных языков с динамическими структурами. Придётся постоянно согласовывать и пересобирать сериализатор, и потом ловить ошибки в реал-тайме, когда что-то забыл.
Вот пример скрипта, который мне понадобился однажды. Микросервис с логированием, мониторингом, защитой от ДОСа, упаковкой в докер и даже дашбордом. Суммарно более 300 полезных строк за час общения. Это пример из разряда "я всё и так знаю, зачем самому писать?" :)
https://chatgpt.com/share/68ef4c12-aa98-8003-9c3b-d447d1ebbf5c
На тему известных декларативных языков ещё добавлю XPath и RegExp, хоть к классу самостоятельных ЯП и не относятся.
Эх, Пролог - удивительный язык... Совсем не сложный. По сути вся программа состоит из предикатов, то есть, определения фактов и их связей между собой. Сложно - это мозг перестроить с поиска итерационных алгоритмов на поиск эффективных эвристик.
А тестирование и отладка программы на прологе - как отдельный вид искусства...