k-2 в том, что вы используете реляционную модель не по назначению. EAV "разворачивает" вашу схему перпендикулярно, и вместо того, чтобы было по одному столбцу на каждое свойство товара (что невозможно в вашем случае по причине изменчивости свойств), у вас будет по одной ЗАПИСИ на каждое свойство каждого товара. Т.е. по сути это борьба с реляционной моделью, попытка получить от неё полу-структурированные, для чего не предназначена.
Это решение приемлемо для небольших объемов данных, или если поддерживать другую СУБД значительно сложнее, чем поддерживать EAV в реляционной.
Daniel Newman
Так а что конкретно вам мешает сделать эту таблицу логов одну на всех? Ну залейте ОДНУ её копию в отдельную базу (чтобы продакшен не трогать) и поставьте права только на чтение (SELECT), и пусть девелоперы ковыряются. Если read-only не годится - ну тогда сделайте тестовые выборки небольшие, процентов 5-10 допустим, и используйте их. Я поэтому и спрашивал про структуру этих логов, т.к. непонятно, для чего они, и какой процент от этих логов можно использовать в качестве полноценных тестовых данных. Т.к. если это логи событий - то событий можно взять последние 100/1000 штук, а не все миллион, а если это какие-то логи синхронизации, то тут уже надо внимательнее.
landergate кстати спрашивает у вас то же самое - что это за дампы, зачем они нужны, зачем дампить базу с логами, почему надо дампить всю базу, а не только схему? Такое ощущение, что нужно просто завести на проекте нормальные тестовые данные и тестовую базу скромного (но достаточного) размера. Что ж это за проект, где всем девелоперам нужны шестигиговые логи? Расчёт процесса слияния черных дыр? ;)
beginer123 Не надо "срочно залазить в FTP", если не хотите себе неприятностей. Сделайте бранч, если изменение временное, если постоянное - то по обычному сценарию. Забывайте о практике изменения кода прямо на продакшене.
Непонятно, о каких уведомлениях идёт речь. Уведомления - это человекочитаемый текст (по эл. почте?) или это сообщения для автоматического сервиса/агента?
Александр Гришин первый фрагмент кода работает, потому что как уже сказал Александр Марченко в ответе, необязательным является именно параметр конструктора, но не создаваемое свойство.
AcidBat есть немало почтовых серверов помимо штатного в виндовом сервере (это наверное последнее, чем бы я попытался воспользоваться). Вам собственно SMTP или IMAP тоже?
Понимаете, вы можете работать с ИНН двумя способами.
Первый способ называется "не заморачиваться". Это значит, что вы не пытаетесь как-либо интерпретировать строку ИНН. Раз вы не пытаетесь её интерпретировать, то вам и хранить её надо целиком и как есть. Если хранить её целиком и как есть - это именно строка, а не номер, т.к. ведущий ноль нужно сохранять. Если вы будете использовать числовой тип данных без особой осторожности, вы рано или поздно этот ноль потеряете (при распечатке документов например).
Второй способы называется" заморочиться и распарсить ИНН". Тогда уж вообще стоит разбить ИНН на составляющие и хранить их в отдельных полях, а контрольные цифры не хранить вообще, т.к. они по сути избыточны. Но тогда вам придётся разбирать/собирать ИНН при работе с БД. Нужно это вам или нет - зависит от задачи. Возможно, налоговая у себя так и делает, чтобы построить индексы для быстрого поиска по отдельным регионам и отделениям, и собирает ИНН на лету при отображении пользователю.
Эти способы альтернативны друг другу. Не стоит их бездумно совмещать. Вы поняли разницу между ними?
