1. когда вообще в базе надо создавать отдельного пользователя? Есть практики что что почитать?Когда человек регистрируется в системе, вроде очевидно.
2. есть ли какие паттерны проектирования баз под такое. Идея-то интересная.Есть конечно. Только подход с пользователями бд обычно тупая идея, так как смена роли/группы/доступа будет нуждаться в прямом вмешательстве в систему бд, что не есть гуд. Обычно RBAC не реализуется на уровне пользователей бд, а использует код, который ориентируется на данные из бд.
3. Какие слова вообще гуглить?RBAC <ваш фреймворк> library
Есть ли смысл начать с устаревшего материала?4-5 лет не сказать что сильно устаревшие. ИМХО спокойно можно учиться, основы будут одинаковы для любой версии языка, изменения в новых версиях большей частью касаются ООП составляющей, до которой еще дойти нужно. В целом и ООП код более старых версий совместим с последними версиями, во всяком случае с 5+, в обратную сторону конечно же работать не будет. Ну а новые фишки по типу тайпхинтинга и анонимных объектов можно доучить и самостоятельно.
разработчики все время советуют перейти на новые технологии а если точнее на Laravel и с MySQL на PostgreSQL чтоб сайт не только стал современным но и работал шустрее.Переход с самописа на лару - хороший шаг, переход на постгрес нужен только если нужны конкретные задачи, решаемые постгресом лучше чем мускулем. Например, если у вас есть большой массив json данных, хранимых в соответствующих полях и требующий каких-либо выборок на основании этих полей, то есть по сути - если у вас база хранит ненормализованные сортируемые данные. В остальном выгода от перехода с мускуля на постгрес будет не видна без микроскопа.
Пытаюсь сделать обязательными поля: country и birthdayДля этого существуtт атрибут required. Естественно это не отменяет проверки полей на бэкенде, но это немного другой вопрос.
где даже submit находится за формой (внесение его внутрь не помогает).Как вообще идея вынести из формы кнопку субмита пришла в голову? А главное - зачем?
Перепробовал все способы которые нарыл. Ничего не помогает.Плохо рыли. Это вообще дефолтное поведение формы, не требующее никаких скриптов. Форма не отправиться пока не будут заполнены указанные как required поля. Если нужны какие-либо еще манипуляции с формой на js, то делается по другому. Форма не трогается, а в кнопку никакие онклики не лепятся. На объект формы вешается событие онсубмит, после чего ПРОВАЛИДИРОВАННАЯ форма вызовет это событие, и дальше уже можно работать с данными формы, в том числе и отправить ее аяксом на бэкенд если необходимо.
Решением было только поменять кодировку таблицы базы данных MySQL, но в моем случае она была utf8mb4, которая должна поддерживать эмодзи.Так как utf8mb4 "обратно совместима" с utf8, все кроме 4байтных символов будет нормально отображаться. Соответственно при указании настроек соединения стоить исправить чарсет на utf8mb4, который по умолчанию у вас скорее всего utf8.
5) Какие главные минусы против чтобы временную метку хранить просто как число unixtimestamp? То что выборки , когда нужны всякие DATE специфичные функции, потребуют преобразования в тип дату в каждой строке? (это преобразование может не сложное?, ведь datetime и так хранится как число)Как минимум то что у вас дата не хранится как дата. Про то что не будут работать стандартные функции работы с датами типа разницы в год, месяц, неделю и прочие весьма неочевидные преобразования я вообще молчу, чего стоит банальное вычисление количества дней до, например, конца месяца, с учетом того что каждый месяц имеет разную длину, не говоря уже про високосные года, ну и всякие расписания, где работа с минутами/часами без готовых функций тоже так себе удовольствие. Кроме того, таймстамп имеет свои ограничения, например в нем нельзя хранить даты раньше чем 1970 год, то есть пользователи старше 55 лет дату рождения сохранить не смогут. Ну и горизонт планирования до 2038 года, дальше все. Алсо, вы теряете защиту от кривых данных на уровне типа поля, что тоже +1 в копилку встроенных типов.
Можете посоветовать как к этому подойти? Может есть какие-то источники, которые я не смогла найти, где говорится, как это делать? Мне кажется, что это возможно, потому что Авито был до того как появился реакт, как-то же это сделалиПочти любой современный сайт состоит из 2 основных частей: Фронтэнда и бэкэнда. Фронт - то что отображается в окне браузера, бэк - серверная часть, отвечающая за чтение, изменение и сохранение данных, которые можно вывести для клиента в любой удобной форме. По этому для реализации вашего проекта понадобятся знания не только верстки и js, нужно будет и разобраться с серверной частью, которая обычно состоит из движка на каком-то языке, подходящем для веб разработки (PHP, Pyton, Java, JS...) и базы данных, где будут храниться собственно данные о пользователях, объявлениях, просмотрах и т.д.
Может есть какие-то источники, которые я не смогла найти, где говорится, как это делать?А искали?
Проблема в основном в том что нейронка ошибается,.так как если механик станет напротив номера она напишет дубль этого автомобиля.Я так понимаю проблема в том что проходящий механик заставляет нейронку еще раз считывать номер машины и заново считать интервал простоя авто в боксе?
Какие способы есть быстро и эффективно проштрудировать .php файлы на наличии в нем кириллицы и задать блокам-родителям уникальные идентификаторы(к примеру data-translate="a += 1")Думаю что вариант с маркировкой блоков заведомо кривой, я бы искал регуляркой по русским символам и в местах текста менял бы на что-то типа
<?=_t('найденный текст');?>, ну и 'найденный текст' использовал бы в качестве ключа к переводу фразы в структуре переводов. И с бэкенда уже все приходило бы в нужном языке (что позволяет вообще практически не менять фронт). Это исходя из того что сайт самописный, на какой-нибудь ларе есть куча готовых мультиязычных решений.
Сможет ли, будет ли индексировать один и тот же урл в разных версиях?Самостоятельно - нет, через сайтмап - да, но криво.
Несколько лет писал его под Windows (C# в MS Visual Studio) ... На что посоветуете перейти? Надежд на перенос кодовой базы не питаю, смирился с тем, что придется писать с нуля.а в чем проблема?
Но тут возникает проблема в формировании prepared statements в PHP (PDO).А в чем проблема?
$sql = 'SELECT *
FROM articles
WHERE name LIKE ?
AND name LIKE ?';
$prep = $dbh->prepare($sql);
$ret = $prep->execute(['%' . 'опух' . '%', '%' . 'поч' . '%']);