beginer123 Не надо "срочно залазить в FTP", если не хотите себе неприятностей. Сделайте бранч, если изменение временное, если постоянное - то по обычному сценарию. Забывайте о практике изменения кода прямо на продакшене.
Непонятно, о каких уведомлениях идёт речь. Уведомления - это человекочитаемый текст (по эл. почте?) или это сообщения для автоматического сервиса/агента?
Александр Гришин первый фрагмент кода работает, потому что как уже сказал Александр Марченко в ответе, необязательным является именно параметр конструктора, но не создаваемое свойство.
AcidBat есть немало почтовых серверов помимо штатного в виндовом сервере (это наверное последнее, чем бы я попытался воспользоваться). Вам собственно SMTP или IMAP тоже?
Понимаете, вы можете работать с ИНН двумя способами.
Первый способ называется "не заморачиваться". Это значит, что вы не пытаетесь как-либо интерпретировать строку ИНН. Раз вы не пытаетесь её интерпретировать, то вам и хранить её надо целиком и как есть. Если хранить её целиком и как есть - это именно строка, а не номер, т.к. ведущий ноль нужно сохранять. Если вы будете использовать числовой тип данных без особой осторожности, вы рано или поздно этот ноль потеряете (при распечатке документов например).
Второй способы называется" заморочиться и распарсить ИНН". Тогда уж вообще стоит разбить ИНН на составляющие и хранить их в отдельных полях, а контрольные цифры не хранить вообще, т.к. они по сути избыточны. Но тогда вам придётся разбирать/собирать ИНН при работе с БД. Нужно это вам или нет - зависит от задачи. Возможно, налоговая у себя так и делает, чтобы построить индексы для быстрого поиска по отдельным регионам и отделениям, и собирает ИНН на лету при отображении пользователю.
Эти способы альтернативны друг другу. Не стоит их бездумно совмещать. Вы поняли разницу между ними?
Arris ваш ответ я прочёл полностью, включая решение с decimal. Не вижу в нём особого смысла по ряду причин.
> Как ЛИЧНО МНЕ кажется, искать (даже с индексом) по числовому полю лучше, чем по строковому.
Тут такой момент, что строковое поле ПОСТОЯННОЙ длины не так уж медленнее при индексации и LIKE 'AAA%s' поиске. Хотя, дать конкретные советы и рекомендации лучше на конкретной СУБД.
Что значит - БД под каждого разработчика? Совершенно непонятна структура вашего проекта, и почему с каждым разработчиком вы теряете по 6Гб. У вас тестовые данные на продовом сервере?
И если вы едва знакомы с базой, почему вы этим занимаетесь-то? Очевидно, нужно понять, что это за system_logs. Как вы собираетесь куда-то её вынести и сделать её общей (не знаю правда, что вы под этим подразумеваете), если вам неивзестно, что там хранится?
> Пишу программу для перевода jpg файла в массив.
Вы понимаете, что большинство читающих остановятся после этого предложения и перейдут на другой вопрос?
Как вам можно помочь, если вы так описываете вашу задачу?
