Ох началось

удваиваю этого господина

По этому отдельная таблица и многие к одному отношение с таблицей пользователей

тоже так думал, но по идее паспорт же один действительный

Самый последний дергать по ид или дате добавления

ну я к тому, что устаревшие хранить нет смысла

вы не хотите сначала уточнить, нужно ли проекту держать историю паспортов?

уточняю - нет

Есть смысл хранить

началось²

Если не смысла хранить, то апдейтить поля в строчке юзера

но если даже появится нужда хранить, то вариант многие к одному в этому случае более гибкий

Но отдельная таблица имхо удобнек

Но отдельная таблица имхо удобнек

тоже так думаю

Значит так и нужно делать) пришли к общему консенсусу

Лучше много мелких таблиц, чем одна толстая

Лучше много мелких таблиц, чем одна толстая

куча джоинов детектед )

А чем это плохо?

Читаешь таблицу, когда есть необходимость

если там действительно куча всякого хлама кроме номера паспорта серии и даты выдачи, например, то лучше отдельную

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

materialized view своими руками

паспорта и юзеры не нужны

добрый вечер , есть кто помочь сможет

разобраться в чем ошибка

транслируй

транслируй

CREATE TABLE Users_tbl ( -> UserId INT NOT NULL AUTO_INCREMENT, -> DomainId INT NOT NULL, -> password VARCHAR(100) NOT NULL, -> Email VARCHAR(100) NOT NULL, -> PRIMARY KEY (UserId), -> UNIQUE KEY Email (Email), -> FOREIGN KEY (DomainId) REFERENCES Domains_tbl(DomainId) ON DELETE CASCADE -> ) ENGINE = InnoDB; ERROR 1215 (HY000): Cannot add foreign key constraint

с мускулом толком не знаком , разворачиваю по мануалу почтовый сервер

таблички обе пустые?

таблички обе пустые?

наверное

Domains_tbl создана?

таблички обе пустые?

понимаешь я сам не шарю , опираюсь полностью на мануал , с domains_tbl еще ниче не делал

ну ее создать нужно, как минимум, что бы вешать внешние ключи

ну ее создать нужно, как минимум, что бы вешать внешние ключи

CREATE TABLE domains_tbl; достаточно?

ну со структурой)

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

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

спасибо за подсказку , нашел чё не дописал , в мане есть всё

Обращайси)

Обращайси)

Data too long for column 'password' at row 1

в ошибке все написано)

слишком много запихать пытаешься в такое поле

в ошибке все написано)

ну пароль обычный ввожу

мб в синтаксисе что не так

какой тип поля

и покажи запрос

и покажи запрос

password VARCHAR(100) NOT NULL,

а какую строку туда воткнуть хочешь?

а какую строку туда воткнуть хочешь?

INSERT INTO Users_tbl (DomainId, password, Email) VALUES (1, ENCRYPT('73184',

бля тут помойму символ перевода строки затесался

она больше 100 символов получается?

INSERT INTO Users_tbl (DomainId, password, Email) VALUES (1,ENCRYPT('73184',

полностью энкрипт покажи

INSERT INTO Users_tbl (DomainId, password, Email) VALUES (1, ENCRYPT('73184',

это кусок запроса)

CONCAT('$6$', SUBSTRING(SHA(RAND()), -16))), 'aldsa@aut.com');

это кусок запроса)

вот

писал и вручную , и так и сяк , не в какую

215 символов

0x24362462633738333162323735386637393963246C776C77517569525151615A626552776F527970683350547842772F654744656755753271536B52432E4235734F2E496A666468444631436B63412F57324E3863766961435A5076486C4B4245486163346C58384131

вот такая вот питрушка получается

а у теюя ограничение - 100

вот такая вот питрушка получается

не подскажешь от чего?

по этому data too long

ну адово ты как-то пароли сохраняешь)

и шифровать их нельзя, если по правильно

правильно - хешировать

у хеша обратной функции нет, в этом и вся прелесть

если заморачиваться не хочешь, и на другую субд переезжать не планируешь, то юзай PASSWORD функцию мускуля

Если есит вариант переезда на другую субд, то лушче что-то общее использовать для хеширования, md5,sha, и тд

Если есит вариант переезда на другую субд, то лушче что-то общее использовать для хеширования, md5,sha, и тд

я делаю всё по ману , просто все строчки сtrl c ctrl v

значит ман кривой

Если есит вариант переезда на другую субд, то лушче что-то общее использовать для хеширования, md5,sha, и тд

и тут такая засада , что поменять надо?

значит ман кривой

в запросе создания юзверя

Нужно смотреть, как этот пароль доставаться будет

есть вариант сломать логику)

можешь просто поле сделать большим

Нужно смотреть, как этот пароль доставаться будет

то есть вместо ENCRYPT что то?

вместо 100 сделай 1024 например

вместо 100 сделай 1024 например

ну значение пароля не исказится?

вместо 100 сделай 1024 например

обратно норм расшифруется?

если поместится, нет)

если не поместится, будет ошибка

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

если поместится, нет)

просто получается в этом запросе я выбираю тип алгоритма в который он преобразует пароль прежде чем занести в бд?

да

в данном случае шифрует пароль, разбавленный солью

да

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

я парочку погенерил длиниющих паролей, всегда 215 символов

я парочку погенерил длиниющих паролей, всегда 215 символов

это по моему алгоритму?

да

да

думаешь ставить 215 длину?

select ENCRYPT('asdfgaskdgfkhagsdkhfgaksgdfkgaskdgfkagsdhfajksdghsdfkjagsdkfgasdhфыварфдыврадлфрывдарфдыврадрфывазйцугкз8й2г-кгйурайзца з 9йуц азйгва хцврап ыивадыва фывоарфдывпрдафрыва098йнк фрвыhjgzsfgksagdfkagskdfgkajsgdfkjgasdfadgfhgasjdgfkasgdfkjgasdfпf',CONCAT('$6$', SUBSTRING(SHA(RAND()), -16))) as enc

вот такую хрень сделал, все равно 215 символов)

я думаю, что длинее пароли делать не будут)

ставь 215

можешь 256 для рвного счета)

ставь 215

а как теперь изменить запись уже сделанную? я с мускулом сегодня первый день