Не могу заставить код прописываться в строку, а не в столбик. Есть у кого-то предположение где я совершил ошибку и как это можно исправить?

хз, что за язык, но так точный ответ не нужен, а нужно "предположение", то, например, так:

days = [1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31]

print('Пн Вт Ср Чт Пт Сб Вс')

for day in days:
print(day,end=' ')
if day % 7 == 0:
print('')

хотя не факт что if попадет в for

Почему вдруг нагружается сервер и потом все сбрасывается?

rinaz22, к сожалению, современное ПО очень расточительно относится к памяти. Вы можете попробовать отключить apt check, но не факт, что не отвалится чтонибудь еще. Также нужно уменьшить максимальный размер кеша СУБД, чтобы было больше свободной памяти для задач ОС и все не сваливалось в недостаток памяти. Но уменьшение кеша вызовет больше операций чтения с диска, неизвестно насколько это будет критично.
С автоинкрементом можно поизучать, но вообще перезапуск СУБД это критическая ситуация, это тотальный сбой. Если не можете искоренить такие сбои, а разобраться с автоинкрементом не получится, попробуйте использовать sequence, т.е. когда счетчик id лежит отдельно. Если в вашей СУБД такой сущности нет, то посмотрите как это сделать самому. Или совсем костыльно, если возможно, не удаляйте все записи из таблицы, оставляйте хотя бы одну последнюю запись.

Можно ли стать бекэндером без фронтенда?

maksam07, хм, наверное, эту сторону не знаю.

Почему вдруг нагружается сервер и потом все сбрасывается?

rinaz22, скорее всего растет кеш СУБД, для него это нормально. Но проверьте, какой процесс увеличивает потребление памяти.
Вообще не должен автоинкремент сбрасываться, но если СУБД убивают, то это может быть последствия сбоя, нужно поэкспериментировать.
Что значит "временная"? Это обычная таблица, просто вы ее используете для временных данных?

Можно ли стать бекэндером без фронтенда?

maksam07, за последние лет 7 - 90%. Оставшиеся 10% были переписаны на использование api.
Но, конечно, это сильно зависит от компаний с которыми работаешь. Неужели ктото сейчас разрабатывает без api?

Можно ли стать бекэндером без фронтенда?

Katya54, maksam07, я вижу несколько иначе. Во взаимодействии фронта и бека, последнему не нужно ничего знать о первом, все их взаимодействие это api.
Но, нормальный разработчик должен контролировать вопросы безопасности, а значит необходимо знать все о фронте в плане аутентификации и различных атак, т.е. всего что затрагивает и фронт, и бек.
Ну и, так сложилось, что бек вполне могут попросить сделать задачку по фронту, в любой компании, и где 2, и где 200 разработчиков. Хотя, как бы и не обязан, можно и отказаться чаще всего.

Можно ли стать бекэндером без фронтенда?

StreetWanderer,

А можно стать фронтендом без бекенда?

Только так и становятся. К фронтендеру обычно не предъявляют таких требований. В редчайших случаях, фронт пишет сохранение своих объектов в СУБД. Фулстек обычно это бек, который стал много заниматься фронтом. И, конечно, различные человек-оркестры, которые умеют все, но по чуть-чуть.
Но, это лишь то, что видел я.

Есть ли преимущества от удаления поля id при создании таблицы?

Zerg89, не очень понимаю, что имеете ввиду, но речь не про общую сумму.
Речь про особенности партиционированных таблиц. И дело скорее не в полезности, а наоборот, в проблемах изза партиционирования.

Подключение класса внутри класса: Правильно ли я делаю?

Ипатьев, по-моему лучше так:
$pdo = new PDO(...);
$repo = new Repo(PDO $pdo);
$user = new User(...);
$repo->save($user);

Подключение класса внутри класса: Правильно ли я делаю?

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

Подключение класса внутри класса: Правильно ли я делаю?

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

Как запушить 2 ветки с изменением одного и того еже файла?

Т.е. создано 2 ветки от ветки develop, в каждой изменен один и тот же файл, так?
Если так, то в чем вопрос-проблема? Пушить эти ветки можно как и все остальные там нет никаких проблем.
Вопрос, наверное, в мерже этих веток в develop (хотя об этом не сказано)? Тогда: ветка смерженная первой не создаст проблем, ветка смерженная второй вызовет конфликт, который нужно будет решить.

Запись только в конец файла?

jcmvbkbc,

O_APPEND для open(), который гарантирует, что запись всегда происходит в конец файла

так и есть, никто не спорит.

Запись только в конец файла?

Но что будет, если после fopen, но до fwrite, другой процесс откроет и изменит файл? Вроде как, указатель в текущем процессе будет там же, где и был, не затрёт ли это запись другого процесса? Или ОС сама "разрулит" это положение?

Другой процесс это совсем другая история. Указатель существует в рамках открытого потока stream.

Как в mysql сделать regexp_replace?

Akina, может и так, может по-другому, но это не важно, если like находит, а replace не может заменить, то не важно какое оправдание, это некорректное поведение.

Как в mysql сделать regexp_replace?

Akina, есть и начало и конец, REGEXP_LIKE("", "$") выдает вполне себе честное 1.
Проблема именно в REGEXP_REPLACE().

Как сделать отображение эмодзи в PHP?

Проверьте кодировку в подключении драйвера MySQL. А чтобы не гадать - дебажте.

Как циклически пройтись по всем столбцам NEW?

Akina, без разницы как их называть, главное что права с повышенными привилегиями на такой машине присутствуют.
Безопасность подразумевает продумывание всех ситуаций, вопрос только в соразмерности используемой защиты. С физическим доступом проще, можно шифровать раздел. А здесь шифруем все данные, но по отдельности каждую ячейку, это сильное усложнение архитектуры, и такое должно быть оправдано. Если мы не подразумеваем получение рутового доступа взломщиком, зачем вообще шифрование? Не проще ли тогда разделять доступ правами или мандатными метками?
От какой ситуации все это нас защитит? Ктото получил креды на чтение из бд, но у него нет ключа? А такого скорее всего и не будет, потому что любая передача доступов всегда будет выполняться передачей этих 3х параметров вместо 2х, и если будет "утечка", то утечет все вместе.
Как по мне, кроме проблем в работе, снижении производительности и чувства ложной безопасности особо ничего не получим.

Как циклически пройтись по всем столбцам NEW?

Akina,

вообще пользователю право на DDL незачем

Если пользователь это машина деплоя, которая накатывает миграции, то нужно

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

Да, стандартная защита для ключа, это спасет если ключ дискредитирован. Но так как он по прежнему присутствует гдето в БД, то дискредитация СУБД приводит к доступу ко всем данным системы.
Т.е. привилегированный доступ к любой из 2х машин (СУБД или к клиенту) даст доступ ко всем данным, в отличие от системы где шифрование в сервисе клиенте СУБД, там доступ к СУБД ничего не даст.
Я просто не вижу ситуации когда следует предпочесть эту схему вместо схемы с шифрованием вне СУБД.

Как циклически пройтись по всем столбцам NEW?

Akina, поправьте, если я ошибаюсь. В текущей схеме, деплой машина (вернее ее роль) не сможет записать такой триггер (вернее ее процедуру), т.е. создание всех таких секретных объектов будет осуществляться суперпользователем вручную? Или нет?
Допустим, но все это надо ведь както расшифровывать. Значит клиент будет запрашивать расшифровку и передавать ключ? А если клиент знает ключ, значит то, что мы усиленно оберегали выше бессмысленно и ключ все равно будет лежать гдето на 3ей машине. А раз так, то шифрование на клиенте БД выгоднее, т.к. даже дискредитация данных суперпользователя БД не даст доступа к данным, нет проблем с деплоем любых изменений и шифрование будет проходить в приложении, которое скорее всего проще масштабировать.