Приведу некоторые примеры из своего опыта
1. Долго думал, как настроить связь между двумя приложениями, написанными на разных языках, сделал адовый пиздец через Linux Pipe файлы, лол. Потом узнал, что существуют MQ сервисы, но потом просто взял и переписал всё, используя Redis и pub/sub
Вообще редис это такая ультра годнота, не представляю как можно писать проект без него.
2. Очень долго разрабатывал в стиле "написал код, открыл приложение, нажал на кнопку, проверил, посмотрел ошибки, пофиксил, снова нажал кнопку".
Не хотел использовать тесты, потому что лень их писать.
Теперь пишу простой тест, который вызывает функцию при нажатии на кнопку, и проверяет что она не выдала никаких ошибок, и вместо нажатия кнопки запускаю тест из консоли. ЭТО ОХУЕННО, АНОН! Практически без затрат усилий я резко повысил стабильность приложения.
А потом тесты остаются, и их всегда можно запустить, без необходимости кликать 100 кнопок в интерфейсе.
3. Не знал, что можно использовать json поля в postgres и для каждого юзера создавал отдельные таблицы типа settings. Теперь всё это храню по возможности в одном json/jsonb поле.
Бывает наоборот. Трудную задачу решаешь старательно и ОЧЕНЬ долго. Результат довольно сложный, но хороший. Смотришь, ну так на всякий случай, что уже сделано по этой теме: "Неужели никто не сделал это лучше и продуманней?". И видишь такой трэшь, что кровь из глаз брызжет. Теряешь веру в человечество. А веры в грёбанное ИТ никогда и не было
Было много подобных случаев, но конкретно вспомнить почти ничего не могу.
Запомнился один, как в универе нужно было написать курсач-сайт, и я решил его делать на питоне, который начал тогда недавно учить. На тот момент из вебни знал только немного голого пхп без фреймворков (в основном дрочил плюсы), и решил, что на питоне на голом cgi с дикой связкой с плюсами тоже так можно. Я с нуля изобрёл роутинг и шаблонизаторы, всё было очень лохматым и было кое-как связано, а правки вносить было очень больно, ну и MVC там не пахло. А затем я наткнулся на Flask и чуть не обкончался от того, несколько простой бывает жизнь.
>можно использовать json поля в postgres и для каждого юзера создавал отдельные таблицы типа settings
Зачем? Почему не создать 1 таблицу user_settings и по айдишникам не хранить там настройки для каждого пользователя? И зачем их в жсон паковать?
Что за приложения?
>Теперь пишу простой тест, который вызывает функцию при нажатии на кнопку, и проверяет что она не выдала никаких ошибок, и вместо нажатия кнопки запускаю тест из консоли.
Потом хуяришь в продакшен и получаешь по ебалу, так как юзер жмёт кнопку и нихуя не происходит, а потом оказывается, что кнопка не к тому методу приколоченв или ещё что. И ты такой, но...я же тестировал...тесты, ряяя
Я писал графическую библиотеку для иксов года 23 тому назад. Затем увидел Gnome и Qt и... бросил. Но тогда я был пацаном с небольшим опытом и не очень понимал как правильно обрабатывать очередь сообщений от X-сервера. Сейчас бы я конечно нагнул и Qt и тем более Gnome. Но интерес и задор угасли с тех пор. Есть и более интересные задачи.
Я писал графическую библиотеку 25 лет назад для работы в паскале в 256-ти цветном режиме и соответствующий ей графический редактор, потому что интернета не было и я даже не знал что
в этот момент драйвер bgi уже существовал.
У меня хотя бы оправдание есть. А у вас?
>оправдываться на ссаче в 2k21 году
Дядь, плиз. Тогда время другое было. Был ты, твой БК 'Байт' и мануал по бейсику, который шел с ним в комплете. Всё. Кто-то штудировал этот мануал, потел и развивался, а кто-то, как я, ходил в подвал к местному барыге записывать игоры на кассеты. В результате ты 25 лет назад писал либу, а я в 2k21 питаюсь вкатиться в хуйти.
в 2000х постоянно изобретал очереди: в БД, отдельно в программе, как отдельный сервис
Потом открыл для себя то, что это типовая проблема и она уже решена.
Ещё в сосничестве пилил свой транслятор ассемблера. Потратил с полгода времени вникуда.
>3. Не знал, что можно использовать json поля в postgres и для каждого юзера создавал отдельные таблицы типа settings. Теперь всё это храню по возможности в одном json/jsonb поле.
Неправильный подход. Лучше храни таблицу типа (username, setting_name, value)
Я когда-то сделал прогрессбар для краулера в виде сервера и хтмл страницы с аяксом. Потом когда в пыху таки завезли консольку знатно ахуел сколько ж я глупой ненужной работы сделал.
>Не быстр на каких операциях?
На любых. JSONB это простая текстовая строка + маркеры оффсетов для ускорения доступа, по типу как в полях protobuf.
Всё это всё равно медленнее чем простое поле таблицы.
>>1794443
>У каждого пользователя свои уникальные настройки.
Смотря что ты называешь настройками.
Если тебе надо цвет форума юзеру рисовать то можно его и напрямую из json брать, да.
Но если там лежит, например, имя человеческое, и тебе потом его захочется показывать на этом самом форуме, то гораздо лучше иметь честное поле, чем лазать за ним в json.
Всё равно респект тебе за то что не скатываешься в полный mongo-дебилизм.
> медленнее чем простое поле таблицы
Почти всегда ну по крайней мере я так делал тебе нужно достать этот жсон полностью как он есть в базе. Редактировать? Ну может быть, но опять же, смотря в каком случае. Если у тебя каталог товаров, где у каждого товара десятки атрибутов, и эти атрибуты бывают уникальными для отдельных товаров, то жсон заборет любое EAV, даже по скорости.
> чем лазать за ним в json
А, ну вот, главное условие для применимости жсона — это его чтение целиком в большинстве случаев. Постоянно ковырять оттуда части то ещё удовольствие.
ОП хранение в json подаёт как годноту, а не как костыль.
>вы писали код сами, а потом обнаруживали какую-то супер годноту, которая делает всё тоже самое, но лучше?
Вот я и спрашиваю - нах так делать, если можно потратить неделю и изучить работу с базами данных и как их правильно проектировать, а не писать то, за что потом по рукам надают более старшие коллеги?
> >3. Не знал, что можно использовать json поля в postgres и для каждого юзера создавал отдельные таблицы типа settings. Теперь всё это храню по возможности в одном json/jsonb поле.
> Неправильный подход. Лучше храни таблицу типа (username, setting_name, value)
И добавить один лишний запрос на каждое обращение к настройкам?
Это только увеличит оверхед
>Ещё в сосничестве пилил свой транслятор ассемблера. Потратил с полгода времени вникуда.
Тю, я за жизнь два транслятора ассемблера написал. Первый в детстве 8080 для компьютера, который загружался с кассеты. Отличался от родного траслятора эпической скоростью - я как раз тогда о хэш-функции узнал и разреженных массивах. Было это ещё летом 1990 года. Мой транслятор ассемблера был написан на ассемблере.
И не так давно, лет пять назад, написал ещё один транслятор ассемблера. Для очень экзотической архитектуры. Писал его на С+. Это не опчатка, это жуткий диалект где-то посередине между Си и С++.
Ты явно не понимаешь ни посыл моего поста, ни реляционную модель как таковую. Мой пост был о том, что менять формат хранения это рутина, и этого не нужно бояться: довольно легко как выкатиться из жсона, так и обратно вкатиться. Реляционные БД хранят данные в виде кортежей, там тоже есть определённый оверхед на поиск значения внутри кортежа. Индекс можно проставить даже по полю внутри жсона, как и по любому другому экспрешену, можешь там хоть площадь треугольника проиндексировать имея в колонках только размеры сторон. Сортировать ты всё равно будешь по индексу, не заглядывая в кортежи. Вообще "обрабатывать" это очень мутное слово, то ли ты про INSERT/UPDATE/DELETE, то ли про сложные агрегации.
> узнать сколько на сайте у тебя Олегов и выводить это в реальном времени
В данном случае агрегация. Агрегации почти всегда очень медленные и нужны в основном для аналитики вручную. Для того чтобы показывать в реальном времени сколько у тебя Олегов лучше всего сделать денормализацию и вынести счётчики имён в отдельную таблицу. И тут для перформанса вообще похуй, что там было изначально, жсон или отдельная колонка с именем. Отдельная колонка может быть чуть проще чтобы писать запрос и чуть быстрее при извлечении этого имени отдельно от жсона.
>>1796931
> заполненной у десяти тысяч строк из десяти миллионов
Кстати это тоже абсолютно похуй. Нуллы в нормальных БД не хранятся внутри кортежа. Именно поэтому ALTER TABLE ADD COLUMN DEFAULT NULL безопасен для продакшена, так как не переписывает всю таблицу.
> обоссаный миллион транзакций в секунду
Нет. Потому что durability, всё пишется на диск. Там бай дизайн не будет миллионов транзакций, если у тебя только сторадж не сверхскоростной. Хотя с партицированием или полной изоляцией инстансов почему бы и нет.
А для чего тебе миллион транзакций в секунду, позволь поинтересоваться?
И да, уточни, транзакции на чтение и таки на запись? На чтение наверное можно потюнить и читать из кэша. Там любая репликация позволит эластично масштабироваться, если почти все транзакции это чтение. Ещё неясно, какова сложность транзакций. Если вытащить одну запись по праймари ключу, то это хуйня. Если джойны с агрегациями, то будет похуже. Короче тут вопросов очень уж дохуя, и о реляционности/нереляционности где-то в конце списка будут.
Специально. Чтобы ты пришёл и написал этот пост. Пост-магнит для душнил.