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