slo_nik, много где такой подход вполне может окончится предложением расстаться по-хорошему. увы, далеко не везде все и всегда происходит правильно.
и чем дольше живет система, тем больше неправильных решений в ней накапливается, а бизнесу проще купить еще сервер и нанять более сговорчивого программиста, чем переписать все с нуля правильно.
тем более, прошлые программисты тоже говорили, что будет правильно и хорошо вечно...
slo_nik, а потом к вам приходят и рассказывают, что уже стопицот лет снимают вот тут галочку - и оно работает как надо... а снять галочку - как раз приводит к тому, что parent_id=null... и в коде до фига мест с такими проверками. и тестов нет.
profesor08, это картинка с камеры, ее нельзя обрезать, потому как камер чуть меньше, чем до фига, а для каждой незначимые области никто отмечать не собирается..
Александр Синицын,
/images/07D2FCF3-46AB-54FC-8895-09C8ED18FD19/1920x1080.jpg
/images/07D2FCF3-46AB-54FC-8895-09C8ED18FD19/1024x576.jpg
/images/07D2FCF3-46AB-54FC-8895-09C8ED18FD19/512x288.png
slo_nik, к сожалению, такую связь не всегда можно создать. может, есть свои причины использовать myISAM. или база сама по себе содержит кучу записей, у которых предок был удален, а чистить ее никто не собирается...
stul5tul, да какая разница, есть там запись или нет там записи?
Вот есть у Вас 20 микросервисов на эту таблицу лотов. Один пишет, 19 читают.
Приходит бизнес и говорит - а дай нам еще галку, чтобы ее поставил - и лот отовсюду исчез, ее снял - все появилось обратно. Независимо от того десятка критериев, что определяют активность лота уже.
Если у Вас 19 читателей обращаются к одному АПИ - Вы измените одно место.
Если все 19 читают из таблицы - Вы в 19 местах измените, покроете тестами и так далее.
stul5tul, только прямые обращения препятствуют изменениям в данных.
Например, в микросервисе лотов добавили флаг "блок_до_снятия", он стал его учитывать в своём апи.
Если остальные лезут в базу - у них тоже надо делать эти изменения...