Ответы пользователя по тегу MySQL
  • Как обойти проблему создания одинаковых кодов?

    @immelnikoff
    Изучаю БД
    промокод вида ААА-0001

    Если первые три символа статичны и меняется только числовая часть, то просто делаете новую таблицу:
    CREATE TABLE promocode(
    id MEDIUMINT UNSIGNED NOT NULL AUTO_INCREMENT,
    user_id INT NOT NULL,
    PRIMARY KEY (id),
    FOREIGN KEY (user_id) REFERENCES user (id)
    );

    Теперь при
    INSERT INTO promocode (user_id) value (1);
    в поле id будет автоматически генерироваться уникальное целое число, которое можно использовать в качестве промокода.
    ps. Думаю, что данную генерацию уникальных промокодов лучше реализовать именно на стороне БД, так как в этом случае вы точно гарантируете уникальность промокода для каждого юзера.
    Ответ написан
    Комментировать
  • Как объединить дубликаты с заменой в дочерних таблицах?

    @immelnikoff
    Изучаю БД
    1. В рамках одной таблицы city это никак не сделать, всё равно придется в дочерних таблицах переставлять значения в Foreign Key с дубликатов на правильный оставшийся город. Можно написать хранимую процедуру, которая будет принимать список дубликатов (а поиск дубликатов предварительно будет осуществляться, например, регуляркой), выбирать единственное верное значение (возможно (и лучше) с вашей подсказкой), во всех дочерних таблицах переставлять значения в Foreign Key на запись с этим значением, а затем удалит дубликаты из city.
    2. UUID нужен для распределенных систем, где нет возможности выполнить проверку уникальности первичного ключа в рамках всей системы или если у вас к базе идет большое кол-во запросов на запись, настолько большое, что СУБД просто не успевает выполнить проверку уникальности первичного ключа для каждой записи. Но, как я понимаю, это не ваш случай. В данном случае вместо 16-байтового UUID лучше использовать автоинкрементное, целочисленное, беззнаковое, 2-байтное поле (city_id SMALLINT UNSIGNED NOT NULL AUTO_INCREMENT PRIMARY KEY). Зачем использовать 16-байтный первичный ключ, когда достаточно 2-байтного? Быстрее будут исполняться JOIN'ы, меньше операций ввода/вывода с диска, меньше требуемого места для хранения на диске.
    Ответ написан
    Комментировать
  • Искажается хеш из MySQL при проверке пароля - как поправить?

    @immelnikoff
    Изучаю БД
    В базе хеши хранятся в поле VARCHAR - длинной 128, кодировка базы - utf8_general_ci

    Я, конечно, извиняюсь, но кто придумал хранить хэш-суммы в поле типа VARCHAR?
    Ответ написан
  • Как правильно сформулировать вопрос mysql?

    @immelnikoff
    Изучаю БД
    Может так:
    SELECT products.name FROM products WHERE LENGTH(products.name) =
    (SELECT max(LENGTH(products.name)) FROM products);
    Ответ написан
    6 комментариев
  • Как получить это значение?

    @immelnikoff
    Изучаю БД
    Если данная таблица M:N, то
    SELECT dialog_id FROM table_name WHERE user_id = 101 AND dialog_id IN
    (SELECT dialog_id FROM table_name WHERE user_id = 103);

    выдаст все dialog_id диалогов, в которых эти два юзера состоят одновременно.
    Ответ написан
    1 комментарий
  • Как создать такой SQL запрос?

    @immelnikoff
    Изучаю БД
    SELECT * FROM table_name WHERE
    year = (SELECT MAX(year) FROM table_name);
    Ответ написан
    Комментировать
  • Несколько вопросов по проектированию MySQL БД?

    @immelnikoff
    Изучаю БД
    1. NULL указывает, что поле может принимать значение NULL, а DEFAULT NULL указывает, что значением по умолчанию для данного поля является NULL. Если в описании поля отсутствует [NOT NULL | NULL], то по умолчанию принимается NULL. Если в описании поля отсутствует [DEFAULT default_value], то при NULL по умолчанию принимается DEFAULT NULL, в противном случае значение по умолчанию не определено.
    Например,
    5c7048fc61843823713050.png
    То есть, если поле NULL, то DEFAULT NULL можно не указывать.
    2. Если поле id является PRIMARY KEY, то независимо оттого, является оно автоинкрементным или нет, нельзя указать для него NULL (будет ошибка). При этом, если отсутствует NOT NULL, то оно подразумевается по умолчанию. Так, что для первичного ключа NOT NULL можно не писать.
    3. см. п.2
    4. Тип BINARY хранит двоичные (бинарные) строки. Для бинарных данных понятие кодировки не определено, так как понятие кодировки имеет смысл только для текстовых данных. Можно ли менять кодировку для поля BINARY или нет, я не знаю, но это просто бессмысленно.
    5. Как реализовано в MySQL я не знаю, но из чисто теоретических соображений, если текстовое поле не может содержать (исходя из модели данных) символов за пределами однобайтовой кодировки, то лучше установить для поля эту однобайтовую кодировку. Во-первых, это уменьшит занимаемое пространство (русские буквы в UTF-8 весят по 2 байта), а во-вторых, если у вас данное поле типа CHAR, то в однобайтовой кодировке оно будет иметь фиксированный размер в байтах, что должно положительно сказаться на производительности.
    Ответ написан
    2 комментария