с переездом то чем помогают?

ну мы в России программировать то не умеем. Вот казахи умеют. вот их и хантят. ты это хочешь услышать?

Нет совсем не это.

))

местные денег много хотят ;) недоджуниор, а уже 150 давай плати ;)

и этот фактор кстати тоже учитывается

думаю он много на что влияет

То что вы очень хорошо кодите это известный факт. Зря ты так...

я не делю людей на национальности :)

и никому не советую. так проще жить

угу, "и матом не ругаюсь" ;)

ругаюсь

вот как думаете... есть юзера редакторы и статьи лобают... что ставить во внешнем, restrict или set null ? :)

На статьи или на юзеров?

ну вряд ли у юзера есть поле article_id :)

я вообще не понял о чем вопрос

Сейчас я придерживаюсь мнения что надо ставить restrict

А юзеров удалять нельзя

Ну в крайнем случае блокировать или что-то типа soft deletable

ну да... в общем где-то того же мнения

хотя сейчас все же решил set null... типа, могу нарушить правило ;)

теперь дошло. ясное дело юзеров не удаляют :)

ну, прям категорично не удаляют? ;)

Вроде в постгресе том же есть прекрасный оператор DELETE CASCADE который в случае нужды удалит и юзера и его посты.

удаляют.. в 20 веке...

Или как-то там можно извернуться.

дада. логика удаления юзера в каскадах...

а что изменилось в 21-м веке, что юзеров стало нельзя удалять? ;)

хотя сейчас все же решил set null... типа, могу нарушить правило ;)

Это глубоко философский вопрос, на который мы натолкнулись когда делали онлайн курсы. Принадлежит ли статья автору, то есть является ли его неотъемлемой частью.

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

это не филосовский, а вполне бизнелогиковый ;)

ну вот опять хайлоады ;)

да чот.. немного поработаешь и мозги уже по-другому варят. удалять дорого очень.

При попытке напрячь извилины мы приходим к парадоксу корабля Тесея и наступает splitbrain

Это глубоко философский вопрос, на который мы натолкнулись когда делали онлайн курсы. Принадлежит ли статья автору, то есть является ли его неотъемлемой частью.

бизнеслогиковый, ибо.... ну блог пользователя без пользователя абсурден. А вот описание продукта на сайте компании без редактора, который ее первый раз вбил - вполне себе живет.

Ну вот как бы статья - она не принадлежит редактору на самом деле.

Если редактор уволится, то статью ведь не удаляют.

И опять же новая головоломка - принадлежит ли редактору его аккаунт в базе данных.

редактору не принадлежит ничего ;) ТК РФ ;)

Ну вот, а курс в вузе принадлежит преподавателю? =)

Тот который он сам писал в двух тетрадках и преподает 15 лет.

т.е. если редактор нахулиганит наспоследок. его удалят. а потом по логам нельзя будет вычислить что он сделал? что он там напортил? какие статьи и т.д.

если писал в рабочее время сидя в университете на зарплате - то нет, не принадлежит ;)

Наконец то мы плавно подошли к теме которую я хотел обсудить - event sourcing

в котоом юзера не удаляют :)

ну были бы логи действий, то, наверное, было бы restrict...

хорошо. а если он кучу статей завел нпоследок. и там полно всякой ерунды. как их найти теперь?

список по дате добавления ;)

и смотреть все статьи

хорошо. а если он кучу статей завел нпоследок. и там полно всякой ерунды. как их найти теперь?

Вот как раз set null подход очень плохо срабатывает в случае каких-то нештатных ситуаций, вредительских действий и флуд атак.

именно так

это абсолютно нелогичное поведение

как и удаление юзера

если он чтото делал в системе - что останется после него мы должны знать что это он

Например зарегался спамер, насоздавал 100000 постов, его модератор удалил. В результате все статьи стали анонимными.

Нет - надо с удалением статей.. спамер не редактор же..

Это бизнес-логика, на самом деле

Но и с другой стороны - restrict подход не очень хорошо работает в честной системе. Когда надо например удалить пользователя, а его статьи оставить. Тогда неудобно все как-то становится.

Она шире, чем логика внешнего ключа.. те же форумы предлагают оба варианта

Просто аккаун должен быть архивирован к примеру..

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

Запись юзера недолжна удаляться - deleted=true

Но и с другой стороны - restrict подход не очень хорошо работает в честной системе. Когда надо например удалить пользователя, а его статьи оставить. Тогда неудобно все как-то становится.

и я опять повторяю свою мысль - юзеров не удаляют уже давно :)

ага, ибо хайлоад и все такое, я понял ;)

Ну я бы не удалял хотя бы потому, что непонятно зачем это делать.

Можно просто скрыть или блокировать.

Я давно расстался с мыслю, что разработчик всегда выше обычного пользователя и умеет смотреть на проблему глобоко и разносторонне ;)

ERROR: S client not available

ага, ибо хайлоад и все такое, я понял ;)

мы тут тебе нашли кучу аргументов. нехайлоадных

Ну, потому-что в этом круде есть иконка "удалить" ;)

мы тут тебе нашли кучу аргументов. нехайлоадных

фигня, логи действий вообще пишутся в файл с именами и дифами, внешних ключей нет ;)

Удалить с точки зрения пользователя - это значит сделать так чтобы элемент исчез и пользователь не мог его нигде найти и пощупать.

фигня, логи действий вообще пишутся в файл с именами и дифами, внешних ключей нет ;)

я умываю руки :)

больше аргументов не было ;)

но в общем я согласен, мдя... просто если сделать restrict - тупой админ тупрой компании получит SQL error при нажатии на иконку удалить и будет *** мозг

Самый сильный аргумент - это нарушение консистентности данных

нет никакого нарушения консистентности, нарушение консистентности - это когда нет внешнего ключа

но в общем я согласен, мдя... просто если сделать restrict - тупой админ тупрой компании получит SQL error при нажатии на иконку удалить и будет *** мозг

Так в yii2 надо повесить на beforeDelete удаление всех статей. Либо вывести ошибку что удалить юзера нельзя т.к. у него есть статьи.

а это какой-то готовый модуль

а наследовать и править готовые модули хрен знает как написанные - это нафиг, проще set null :)

нет никакого нарушения консистентности, нарушение консистентности - это когда нет внешнего ключа

Ну вот представь что ты пишешь некую агрегатную статистику - "за 5 лет наши редакторы написали 100500 статей, вот топ 5 самых плодовитых редакторов за прошлый год". А потом удаляешь одного из этих редакторов, он выпадает из топ-5, вся статистика тоже сбивается. Сложно-непонятно.

Получается ты взял и переписал прошлое в своей системе.

Ну да, если я уволил человека из компании, то из рейтинга его тоже нужно убрать ;)

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

ну да, те, кто был ниже рейтингом только спасибо скажут ;)

Ну да, если я уволил человека из компании, то из рейтинга его тоже нужно убрать ;)

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

Кто сказал? Ты, а хто ты такой в этой компании? Разработчик? Вот и разрабатывай, а генеральному виднее ;)

Я к тому, что на самом деле удалять или нет - это, как ни странно, бизнес...

Да бизнес дурак

Он ничего не понимает в правильной разработке.

Не, смотри... бизнес дает задачу "удалить". В понимании бизнеса "удалить" - это скрыть с глаз долой. Как разработчик ты можешь или удалить или ввести флаг. Только флаг - он много сложнее, и не потерять нигде его. А потеряешь в каком-то рейтинге - бизнес даст проблему ;) Бритва О́ккама

Ну так из рейтинга он пропадет по любому, а бизнес потом спрашивает: а чего это у нас вся бухгалтерия за прошлый год съехала, и новый чувак требует от нас денег?

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

это проблема бизнеса ведь, так? ;)

битрикс тоже удаляет ;)

Проблема у бизнеса, но все подумают что разработчики идиоты и все испортили как всегда.

это проблема бизнеса ведь, так? ;)

Хороший разработчик обьяснит всю суть бизнесу. А не будет тыкать чья это проблема.

но хорошие разработчики в галерах.. надолго не задерживаются

Хороший разработчик обьяснит всю суть бизнесу. А не будет тыкать чья это проблема.

если у вас разработчик объясняет бухгалтерии, что у них может что-то съехать, это значит только одно - он не на своем месте ;)

ибо это вообще-то работа аналитиков ;)