Программирование[10]

[moonfangtopich]

Just.Doit said 1 hour ago:

MedVed_na_lesapede said 3 hours ago:

Знатоки внимание вопрос: что делать ?

не использовать реляционки и не использовать реляционки так топорно

Уебище

[Kant]

MedVed_na_lesapede написал 29 минут назад:

Kant написал 1 час назад:

констреинты в базе должны выполнять функцию чисто страховки от совсем бреда

здесь же чистая бизнеслогика, её всё равно ведь надо проверять на уровне кода, чтобы юзеру ругнуться правильно, дубль в базе нахуй не всрался.

Не нужно ничего проверять - можно же сделать мидлвару, например глобал ExceptionFilter, постгрес кинет PostgresException, можно создать дикшенари с ключом - наименование констрейнта - значение - понятное человеку описание ошибки, у PostgresException есть филда ConstraintName - https://www.npgsql.org/doc/api/Npgsql.PostgresException.html
собстна по ней чекаем словарь и берем понятное описание ошибки и собстно формируем ответ в мидлваре с нужным нам кодом ошибки и этим ответом. И не надо никакими запросами долбить базу на проверки - тем более они ничего не гарантируют, если вдруг возникнет такая ситуация что у тебя в один момент времени 2 реквеста пошли на пост таких вот конфликтных данных оба могут сесть в бд, если не будет констрейнтов(первая транзакция чекнет - и в базе все будет ок а вторая чекнет когда первая еще не зафиксировала данные и у нее тоже все будет ок).

ты всё равно будешь эти данные доставать, какая разница, запрос сделает база или ты

только со своей стороны ты еще и можешь ограничить запрос каким-то разумным пределом или кэшем или еще бог знает чем, база же всё сделать не сможет

 

ну и 2 реквеста и прочее - это решается просто колонкой на точке синхронизации, которая кинет optimistic concurrency exception если кто-то попытался сделать что-то параллельно. И это много проще, чем расставление миллионов констреинтов на каждую зависимую таблицу, особенно учитывая, что орм делает это за тебя

 

 

ну и самое главное

сегодня у тебя этот констреинт подходит, а завтра уже нет, скажут, что такие дубли разрешены, придется констреинт убрать

послезавтра приходят, и говорят, что нужен новый констреинт, но вот беда, старые данные ему не удовлетворяют, и ты не можешь его создать без выноса всего неподходящего в архив

а оно тебе нахуй не надо, ведь всем поебать в реальности на такую сложную логику, а архивная таблица уничтожает всё удобство скана в прошлое

[Just.Doit]

MedVed_na_lesapede написал 43 минуты назад:

реквеста пошли на пост таких вот конфликтных данных оба могут сесть в бд, если не будет констрейнтов(первая транзакция чекнет - и в базе все будет ок а вторая чекнет когда первая еще не зафиксировала данные и у нее тоже все будет ок).

ну "решать на уровне аппы" это и значит сделать так чтобы такие реквесты не прошли

moonfangtopich написал 42 минуты назад:

Just.Doit написал 2 часа назад:

MedVed_na_lesapede написал 3 часа назад:

Знатоки внимание вопрос: что делать ?

не использовать реляционки и не использовать реляционки так топорно

Уебище

ты щас договоришься и я тебя зарежу

[MedVed_na_lesapede]

Kant написал 38 минут назад:

MedVed_na_lesapede написал 1 час назад:

Kant написал 1 час назад:

констреинты в базе должны выполнять функцию чисто страховки от совсем бреда

здесь же чистая бизнеслогика, её всё равно ведь надо проверять на уровне кода, чтобы юзеру ругнуться правильно, дубль в базе нахуй не всрался.

Не нужно ничего проверять - можно же сделать мидлвару, например глобал ExceptionFilter, постгрес кинет PostgresException, можно создать дикшенари с ключом - наименование констрейнта - значение - понятное человеку описание ошибки, у PostgresException есть филда ConstraintName - https://www.npgsql.org/doc/api/Npgsql.PostgresException.html
собстна по ней чекаем словарь и берем понятное описание ошибки и собстно формируем ответ в мидлваре с нужным нам кодом ошибки и этим ответом. И не надо никакими запросами долбить базу на проверки - тем более они ничего не гарантируют, если вдруг возникнет такая ситуация что у тебя в один момент времени 2 реквеста пошли на пост таких вот конфликтных данных оба могут сесть в бд, если не будет констрейнтов(первая транзакция чекнет - и в базе все будет ок а вторая чекнет когда первая еще не зафиксировала данные и у нее тоже все будет ок).

ты всё равно будешь эти данные доставать, какая разница, запрос сделает база или ты

только со своей стороны ты еще и можешь ограничить запрос каким-то разумным пределом или кэшем или еще бог знает чем, база же всё сделать не сможет

 

ну и 2 реквеста и прочее - это решается просто колонкой на точке синхронизации, которая кинет optimistic concurrency exception если кто-то попытался сделать что-то параллельно. И это много проще, чем расставление миллионов констреинтов на каждую зависимую таблицу, особенно учитывая, что орм делает это за тебя

 

 

ну и самое главное

сегодня у тебя этот констреинт подходит, а завтра уже нет, скажут, что такие дубли разрешены, придется констреинт убрать

послезавтра приходят, и говорят, что нужен новый констреинт, но вот беда, старые данные ему не удовлетворяют, и ты не можешь его создать без выноса всего неподходящего в архив

а оно тебе нахуй не надо, ведь всем поебать в реальности на такую сложную логику, а архивная таблица уничтожает всё удобство скана в прошлое

ну ты прав конечно но не я придумал это все ) Я просто пытаюсь с этим жить, к сожалению без таких вот констрейнтов не обойтись еще хотя бы потому что к базе имеют доступы отморозки на bi-самокатах, которые могут етлем какое-нибудь гавно туда попытаться залить, а так да ты прав - IsConcurrencyToken/Timestamp в обычных условиях решили бы эту проблему. По поводу нового констрейнта и невалидных старых данных - можно сделать секционирование по дате окончания версии, и на партиции с архивами вообще никакие констрейнты не нужны т.к это чисто ридонли записи, а новый констрейнт вешается только на действующие.

Изменено 23 октября 2021 пользователем MedVed_na_lesapede

[GoldRobot]

Kant написал 1 час назад:

да это и есть самое правильное решение

констреинты в базе должны выполнять функцию чисто страховки от совсем бреда

Так они у них и выполняют. Да и у ребят не большая в общем то нагрузка похоже что бы заниматься таким дрочем с шансом отстрелить себе ногу.

Просто ребята совместили мусорную историю (сотня лямов записей без сегментирования? С ними реально кто-то работает?).

 

Отделите этот мусор исторический от полезных данных. Заведите отдельную таблицу под историю, и отдельную под актуальные данные. Констрейны на истории не нужны будут. На историческую сегментирование (пазман досихпор удобнее родных постгресовских будут имхо), если ими пользоваться охото.

Вангую, что даже с тригером на апдейт который автоматом в историю вставляет, будет быстрее чем текущая система.

 

[MedVed_na_lesapede]

GoldRobot написал 14 минут назад:

Kant написал 2 часа назад:

да это и есть самое правильное решение

констреинты в базе должны выполнять функцию чисто страховки от совсем бреда

Так они у них и выполняют. Да и у ребят не большая в общем то нагрузка похоже что бы заниматься таким дрочем с шансом отстрелить себе ногу.

Просто ребята совместили мусорную историю (сотня лямов записей без сегментирования? С ними реально кто-то работает?).

 

Отделите этот мусор исторический от полезных данных. Заведите отдельную таблицу под историю, и отдельную под актуальные данные. Констрейны на истории не нужны будут. На историческую сегментирование (пазман досихпор удобнее родных постгресовских будут имхо), если ими пользоваться охото.

Вангую, что даже с тригером на апдейт который автоматом в историю вставляет, будет быстрее чем текущая система.

 

тригер на чек, вместо констрейнта а не на вставку. Ты имеешь ввиду скорее всего секционирование через наследование таблиц - но это старое гавно, которое к тому же еще не дружит с ормами, потому что там как раз надо тригерами обрабатывать в какую таблицу вставлять данные и поскольку данные вставляются не в эталонную таблицу, на которую замаплена энтити ормом,  а в ее партицию, про которую орм ниче не знает, там из тригера нельзя возвращать New. А если орму(не знаю как за остальные, говорю щас про ef core конкретно) при вставке/апдейте не вернуть new - он упадет с ошибкой что тип он попытался создать но паходу не создалось и я не могу трэкнуть запись =)))
В постгресе с 10 версии завезли новый способ секционирования -декларативный, там не нужны никакие тригеры, он сам понимает в какую партицию по партицируемому полю/полям надо вставить и с ормками все норм.

Изменено 23 октября 2021 пользователем MedVed_na_lesapede

[GoldRobot]

Я без понятия как ты читая черный текст на белом фоне смог так сильно исказить в нем написанное. Но аплодирую, талант.

[MedVed_na_lesapede]

GoldRobot написал 1 минуту назад:

Я без понятия как ты читая черный текст на белом фоне смог так сильно исказить в нем написанное. Но аплодирую, талант.

что ты имеешь ввиду под "Вангую, что даже с тригером на апдейт который автоматом в историю вставляет, будет быстрее чем текущая система."
это же описание секционирования через наследование таблиц....

[GoldRobot]

Позволь я просто поквочу свой первый пост

GoldRobot написал 22 минуты назад:

Заведите отдельную таблицу под историю, и отдельную под актуальные данные

 

GoldRobot написал 24 минуты назад:

тригером на апдейт который автоматом в историю вставляет

 

[keltim]

Отвлеку от темы хотел уточнить 2 вопросика 

1) сейчас на курсах учу язык путь будет долгий , не суть, заметил последнее время как—то много вакансий  и интереса к фронтендерам на js , хотя ранее думал что людей наоборот переизбыток  и предложений меньше

так ли это ? Или наоборот js  щас везде нужен людей не хватает и предложений достаточно на рынке 

2) есть ли смысл к концу обучения (как будущему трэйнии/джуну) начать учить второй язык? (тот же js)  или лучше сконцентрироваться на том что учу , найти работенку и закрепить знания ,а потом уже лезть в другие дебри и языки ?

мне для понимания бытия 

 

[Drakonian]

а что ты блять учишь?

[GoldRobot]

keltim написал 30 минут назад:

тот же js

Ну тут как в еде и тачках.

Попробовав хорошее, ты уже не сможешь пользоваться плохим, хотя раньше не замечал проблем. Начав с великолепного, ты уже не сможешь пользоваться просто хорошим.

Поэтому если хочется жс, то лучше сразу с него и его экосистемы начинать, потому что потом в рот не полезет.

Главное не повторяй ошибку многих людей, не начинай с плюсов, после него все как прогнившый запорожец деда ощущается.

 

[keltim]

Я питон щас но ещё до выбора питона поглядывал в сторону js

[Drakonian]

Я бы не хотел заниматься js например, дело вкуса. А по поводу кучи вакансий - ну так и конкуренция заебешься, слишком много вкатывальщиков в фронтенд прутся 

[Just.Doit]

если у вас 10ки лямов записей, речь идет заоптимизацию констрейнтов, партиционирование и все остальное

какие нахуй ормы, ребята

[UglyBastard]

[Just.Doit]

keltim написал 2 часа назад:

Отвлеку от темы хотел уточнить 2 вопросика 

1) сейчас на курсах учу язык путь будет долгий , не суть, заметил последнее время как—то много вакансий  и интереса к фронтендерам на js , хотя ранее думал что людей наоборот переизбыток  и предложений меньше

так ли это ? Или наоборот js  щас везде нужен людей не хватает и предложений достаточно на рынке 

2) есть ли смысл к концу обучения (как будущему трэйнии/джуну) начать учить второй язык? (тот же js)  или лучше сконцентрироваться на том что учу , найти работенку и закрепить знания ,а потом уже лезть в другие дебри и языки ?

мне для понимания бытия 

 

1) кмк все мейнстрим языки +/- одинаковые в этом плане. скорее стоит думать какая сфера интереснее (программирование это не сфера. дата процессинг, фронтенд разработка, бекенд, и тд) и выбирать язык наиболее распространенный в этой сфере. если сейчас этим не заморачиваться - то что жс что питон одинаков. я бы сказал питон получше тк ненастолько ебанутый как жс, для неокрепшего ума жс может быть разрушителен, хехе

2) да похуй. если интересно - пробуй, любопытство лучше чем предубеждения и опасения попробовать. лишним точно не будет. 

 

[GoldRobot]

keltim написал 9 часов назад:

Я питон щас но ещё до выбора питона поглядывал в сторону js

Там и оставайся до конца обучения.

Если тебе сильно хочется, подрочи sql лучше.

Если ты супер крутой парень, и ты освоился хорошо с sql и питоном уже, то пиздуй совмещать с работой, и там уже задумаешься о следующем языке, в зависимости от проектов и задач, либо от направления в которое ты решил двигаться.

[kez]

Открыл резюме на хх, скрыв его от работодателя. Чувствую себя крысой/10. 

[Admiral Retard]

Бтв, кто недавно устраивался на новое место на удаленку, как вы решали вопрос с отправкой сканов\фоток документов на галеру? А то меня тут недавно просили отправить, я в итоге отморозился и договорился самостоятельно подвезти все документы.